Outlook Live « Steve Goodman's Tech Blog – The weblog of an IT pro specialising in Exchange, Exchange, VMware, Servers and Storage

29Aug/105

Set up Federated Free/Busy and Calendar Sharing between Exchange 2010 SP1 and Outlook Live

As organizations move to make use of cloud based services, like Exchange Online or Outlook Live, it’s pretty important to be able to integrate both the on-premise service and the cloud service so that end-users can continue to work as normal. That’s especially important with a service like Outlook Live, aimed at Education institutions, where typically staff, faculty and some students will continue to be hosted on-premise and the majority of students will be hosted in the cloud. A seamless experience makes life easier for users and thus easier for IT…

So, with Outlook Live and Exchange 2010 On-Premise there is a pretty good opportunity to get Exchange working seamlessly between both systems. I’ll be covering a unified login in a further article (once I’ve re-written the code we use in-house into a re-distributable form) and if there’s any interest I’m also happy to cover using a single autodiscover service as well. But for now, I’m focusing on the user experience with free/busy and calendar sharing.

One of the areas might expect to “just work” is free/busy and calendar sharing between on-premise and cloud. The options are there, it looks like it tries to do it.. But the end user ust gets unfriendly error messages and “permission denied” errors. To get this up and running in Exchange 2010 SP1 is actually now pretty simple. No expensive certificates required from a handful of providers – you can use a self-signed certificate and it’s easy enough to get up and running with in less than an hour. In this article, I’m going to show you how…

Pre-requisites

First things first, we need a few things in-place and working already before we can get going. The main pre-req is Autodiscover, but I won’t cover how to set this up, as it's is covered in detail elsewhere on the good old ‘net..

Autodiscover working for On-Premise for the domain you want to use (using DNS names, not a service records)
Autodiscover working for Outlook Live for the domain you want to use (again, using DNS names, not a service record)
Separate domains for on-premise and Outlook Live (I’m testing getting shared working – follow up article to come)
Exchange 2010 CAS Connectivity to *.outlook.com
Org admin rights on Exchange 2010 SP1 and Tenant Admin rights on Outlook Live, along with Powershell access to both.
Access to manage the DNS for both domains and add TXT records.

Once that’s all setup and available, you should be ready to go..

Setting it up

To keep things simple, we’re not going to do anything too complicated, we’re going to set things up so all users in both on-premise and Outlook Live can see each other’s free/busy and share calendars (and contacts). Also, for the purposes of this article it’s assumed no Sharing Policy is setup already.

On our test setup, we’ve got two domains:
On Premise: contoso.astonuniversity.net
Outlook Live: live.contoso.astonuniversity.net

Basically we need to create three things on-premise – A Federation Trust to authenticate us against the MS Federation Gateway, then an Organization Relationship to say Outlook Live can see in for Free busy, and finally a Sharing Policy to allow on-premise users to share their calendars with Outlook Live users. In Outlook Live the trust with MS’s Federation Gateway is there by default so we just need the Organization Relationship to allow On-premise to see in and the Sharing Policy to allow the Outlook Live users to share with On-premise users.

First, we’ll setup the on-premise config, then get the Outlook Live stuff done. Afterwards we’ll test everything works.

On Premise Config

Step One – Setup a New Federation Trust using a self – signed certificate

First you need to make a new certificate. Create one using the following command:

New-ExchangeCertificate -DomainName 'Federation' -FriendlyName 'Exchange Delegation Federation' -KeySize '2048' -Services 'Federation' -SubjectKeyIdentifier '67653b80cfcb4cd18f7ac952fed0e590' -PrivateKeyExportable $true

Note down the Thumbprint in the output, and then create the Federation Trust using that thumbprint value. Note that we’re manually setting the MetaDataURL. This is why we can’t do it in the Exchange Management Console – SP1 by default works against a new “Business” gateway. Outlook Live currently works against a legacy “Consumer” gateway and the URL below switches us to use that one.

New-FederationTrust -Name 'Microsoft Federation Gateway' -Thumbprint 'thumbprint' –metadataurl https://nexus.passport.com/FederationMetadata/2006-12/FederationMetadata.xml

Next, we need to setup a record in DNS that will be used to verify we own the domain and allocate us an ApplicationID for our domain.

Get-FederatedDomainProof -DomainName contoso.astonuniversity.net

Copy “Proof” entry that is output, and get ready to enter it into DNS (BTW the DnsRecord syntax will be wrong, just ignore it)

If you use Windows DNS, it goes a little something like this:

And if it’s Unix:

Once that’s in, reload/HUP your DNS and make sure you can resolve it, both from your Exchange servers and from the outside world. The following command should work:

nslookup -querytype=TXT contoso.astonuniversity.net

Now we’ve got the Federated Trust and DNS record sorted, we can get ourselves properly setup with the Federated Gateway. To do this, we use the Set-FederatedOrganizationIdentifier command:

Set-FederatedOrganizationIdentifier -DelegationFederationTrust 'Microsoft Federation Gateway' -AccountNamespace contoso.astonuniversity.net -Enabled:$true

Assuming that completes successfully, we can move onto the next step..

Step Two– Setup the On-Premise Organization Relationship

The next step is to allow our Outlook Live domain to see our On-premise Free/Busy info. You can do this via Powershell or the Exchange Management Console:

Via Powershell:

Test that you can get the federation info for your Outlook Live domain. If you get an error, run the command again with the -Verbose parameter for a detailed error and check your autodiscover setup for Outlook Live:

Get-FederationInformation live.contoso.astonuniversity.net

Next, configure the relationship. The LimitedDetails option below is the most open setting for the relationship, which means any user who has chosen to show that much detail will also make it available to the Outlook Live tenant.

Get-FederationInformation live.contoso.astonuniversity.net | New-OrganizationRelationship -Name "Outlook Live" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel:LimitedDetails

If you'd rather configure via Exchange Management Console:

Navigate to Organization Configuration, and select the Organization Relationships Tab. Right click in the whitespace and choose “New Organization Relationship”:

in the New Organization Relationship window, Give a the new relationship a friendly name (e.g. Outlook Live). Select the checkbok "Enable this organization relationship", then choose to enable free/busy access. Choose “Free/busy access with time, plus subject and location” to select the widest access. This means any user who has chosen to show that much detail (i.e. people can see that on-premise right now) will also share it to Outlook Live.

Next enter the Outlook Live domain in the Automatically discover configuration information text box, and press Next.

Check for any errors, and press Finish. If there are errors, and it isn't a typo, then it’s likely to be an Autodiscover issue - but you'll find out most detail on the possible cause if you use the Powershell instructions above.

The new relationship should now be listed underneath Organization Relationships:

Step 3 – Setup the Sharing Policy

To enable our on-premise users to share their information with Outlook Live users we need a sharing policy setup. While you can setup multiple sharing policies and assign them to different users, for this basic sharing we’re going to modify the default sharing policy

Via Powershell:

First, check your settings. Note down the existing Domains value.

Get-SharingPolicy 'Default Sharing Policy'

Replace the domains value on the Default Sharing Policy setting the original value (or remove it, if you want) and adding the Outlook Live domain. For the Outlook Live domain we're setting the maximum scope for sharing:

Set-SharingPolicy 'Default Sharing Policy' –Domains '*:CalendarSharingFreeBusySimple', 'live.contoso.astonuniversity.net:CalendarSharingFreeBusyReviewer, ContactsSharing'

If you'd prefer to configure the sharing policy via the Exchange Management Console:

Navigate to Organization Configuration > Mailbox > Sharing Policies, then right click the Default Sharing Policy, then choose Properties:

In the Default Sharing Policy Properties, choose “Add”, then specify the Outlook Live domain. To allow for the maxium level of detail to be shared by individual users, select the last option “Calendar sharing with free/busy information plus subject, location and body, Contacts sharing:

And that’s it for On-Premise. Next.. We need to get the hosted environment setup with with the corresponding parameters:

Outlook Live Setup

For the Outlook Live setup you have to use Powershell – Exchange Management Shell isn’t supported when managing your hosted tenant. If you’re not sure how to connect Powershell see the guide on the Outlook.com help site, but it basically looks a little like this:

Step 1: Setup the Outlook Live Organization Relationship

We get to miss out the first step that we had to do on-premise, setup of the federation trust, because as a tenant of the outlook.com Exchange environment this has already in place.. So we can skip to getting an organization relationship setup with our on-premise domain.

First, we check that we can indeed discover the correct settings by using the Get-FederationInformation command, specifying the on-premise domain:

Get-FederationInformation contoso.astonuniversity.net

The output from the command should show details matching the Organization Identifier and Application URI we setup earlier, along with the details of the on-premise Autodiscover environment.

If it returns a failure you may need to double check your Autodiscover settings for the on-premise environment, or in some cases you may need to give it a little while (if you just setup your Federation Trust on-premise) and try again. For example, in my production environment it took around an hour for my production Outlook Live tenant to be able to discover the Federation Information although my test domains could see the same information without any issues.

So.. After you’ve tested Outlook Live can discover the Federation Information, it’s onto actually creating the Organization Relationship. The command is exactly the same as on-premise,we are really just swapping the domain:

Get-FederationInformation contoso.astonuniversity.net | New-OrganizationRelationship -Name "On-Premise" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel:LimitedDetails

Step 2: Setup the sharing policy

Finally, it’s on to the final step – getting the sharing policy sorted. Check out what the Default Sharing Policy currently is before we go and add our on-premise domain:

Get-SharingPolicy

Then replace the Domains list for the Default Sharing Policy with a value that includes the on-premise domain. In the example below, I’m keeping the settings that were already there and adding the on-premise domain. For consistency, I'm also keeping the same sharing level as set on-premise:

Set-SharingPolicy 'Default Sharing Policy' -Domains '*:CalendarSharingFreeBusySimple', 'contoso.astonuniversity.net:CalendarSharingFreeBusyReviewer, ContactsSharing'

After that, it should all be done. Give it a little bit of time (say, 15 minutes) for everything to take effect and we should be ready to have a play..

Testing it out

For testing purposes on my two domains, on-premise “contoso.astonuniversity.net” and Outlook Live “live.contoso.astonuniversity.net”, I’ve created test accounts in each –“onpremise@contoso.astonuniversity.net” and “outlooklive@live.contoso.astonuniversity.net”. For the screenshots I’ve used OWA, but it works equally well in Outlook.

The first test is for Free/Busy. I’ve created a few test appointments in both calendars and you’ll see availability works just as if the user was on-premise:

In Outlook Live, scheduling a new meeting with the on-premise user as an attendee:

Next, via on-premise Exchange 2010 SP1, with our Outlook Live user as an attendee this time:

The second test is to check it is possible to share a calendar either way, and this is where it strays slightly away from the full range of options available to users within a single environment.

The limitations we’ve got mean that the user must share the calendar using OWA or Outlook 2010, and must use the “share this calendar” options rather than setting permissions directly. The recipient of the permission must add the calendar using the resulting email (they can’t just add it by name) and it’s read-only. this of course means the process can’t be easily automated, but it does allow users to use a common workflow to share folders, via the “share” options.

Sharing a calendar in Outlook Live:

On-premise user receives the sharing invitation and chooses “Add this calendar” to add it:

After adding the calendar, it’s shown in red (in OWA, anyway) while the server retrieves the calendar:

After a minute or so, the Outlook Live calendar shows up alongside the On-premise calendar:

Finally, let's test it from On-premise to Outlook Live:

Select the Calendar’s “Share” option to share the calendar (it's worth noting that the OWA UI has changed between RTM and SP1.. but I digress):

Over in Outlook Live, the Outlook Live user receives the invitation and again, chooses the “Add this calendar” link:

After choosing to add the calendar, the on-premise calendar shows (again after a minute or so to do the first sync) alongside the Outlook Live calendar:

Contacts sharing is again a similar process, although it must be shared using Outlook 2010. Simply right click a contacts folder and choose Share>Share Contacts:

And that’s it – hopefully this will work for you, but if you have any questions or any issues, just use the comments form below.

Tagged as: Calendar Sharing, ecp, Education, Exchange 2010, Exchange2010, Federation, Free/Busy, Live@EDU, outlook live, Powershell, Self-signed certificate 5 Comments

25Jul/103

Using Powershell to import contacts into Exchange and Outlook Live

When performing migrations between different systems, there’s always the case where the tools available don’t do the job out of the box – and although IMAP migration tools for Exchange and Outlook Live can be great for moving mail, there isn’t a decent free solution for importing contacts.

For a recent migration from a Unix system (Dovecot + SquirrelMail) to Outlook Live, I came across this very scenario. While Microsoft provide IMAP migration tools to move mail to Outlook Live (which I was lucky enough to beta test before it was widely available), no tools are provided to move other data such as contacts and calendars.

While this isn’t the actual code I used (I wrote my original code in C#), I’ve re-visited what I’ve done and listened to what others say they need. What I’ve heard is it would be useful to have some Powershell code that out-of-the box can import contacts into any Exchange mailbox. The reason that Powershell is the right language for code like this is that it’s fairly easy for the enterprising administrator to modify to their needs.

Getting started

Before you can run this script, there are a few things you need to set up first. Don’t worry though! It’s nothing too onerous – all is needed to get going is two things:

Setup of EWS impersonation, unless you only want to work with accounts you know the username/password for.
Installing the Managed API DLL onto your computer.

Setup of Exchange Web Services Impersonation
Exchange Web Services is the programmatic interface to each user’s Exchange mailbox. Most actions that can be performed in Outlook can be performed via EWS – so much so, in fact, that Apple’s Mail.app in Snow Leopard and the latest update for Entourage 2008 use EWS as the backend for the mail clients themselves.

If you’re planning on doing a mass-import of contacts, or don’t know the user’s password you’re importing, then setup of EWS impersonation is the step you need to take to allow a trusted account to switch to the user you want to import.

In Exchange 2010, setup of Exchange impersonation is managed via RBAC. Full details of how to setup impersonal are on the Microsoft site, but if you just want to get it setup for a single admin/service account, org-wide, use the following command substituing serviceaccount for your service account:

New-ManagementRoleAssignment -Name:impersonationAssignmentName -Role:ApplicationImpersonation -User:serviceaccount

On Exchange 2007, it’s very different, and is managed by AD permissions on individual Client Access Servers. Again – full details on the Microsoft site, but to add the permission to all CAS servers, the following code will suffice, again substituting serviceaccount for your Service account:

Get-ExchangeServer | where {$_.IsClientAccessServer -eq $TRUE} | ForEach-Object {Add-ADPermission -Identity $_.distinguishedname -User (Get-User -Identity serviceaccount| select-object).identity -extendedRight ms-Exch-EPI-Impersonation}

Installing the Exchange Web Services Managed API
Next, whatever environment you are in, you need a copy of the DLL file that provides the bits and pieces that make this all work. The easiest way to get up and running is to download the API (choosing the right version for your platform), and install it to it’s default location.

Download the EWS Managed API from the Microsoft site

Once downloaded and installed, you should be good to go with script.

Using the script Import-MailboxContacts.ps1

So, you’ve got impersonation setup if needed, got the EWS DLL on your machine. You should be good to go!

For each mailbox you want to import contacts from you need a separate CSV file. The format of the file is intentionally the same as Outlook will export in, mainly because a lot of apps already export in the format (Gmail does, for example) so you should find it easy to get test data, but if you haven’t I’ve included a sample file to get you started.

Along with the data, you also need, at a minimum, the mailbox email address to import to. This is used when impersonating, and for Autodiscover. If you’re not logged on as the user you want to use for the import, you can specify a username and password. Additionally, there’s a variety of options to specify the EWS Url manually, switching to the Exchange 2007 version of the API etc.

Examples

The first example is a straightforward import into the current logged-on user’s mailbox. We’re specifying the Email Address and the URL to EWS (to bypass Autodiscover):

.\Import-MailboxContacts.ps1 -CSVFileName .\Contacts.csv -EmailAddress steve@goodman.net -EwsUrl https://server/EWS/Exchange.asmx

As you can see in the above example – it’s all fairly straightforward. You’ll also see the output shows the contacts that have been created – you can use standard Powershell pipeling to export this data, pipe it to another command or filter it.

The second example is slightly more complicated, and reflects the main use case. We’re connecting to a remote exchange organisation, using Autodiscover to find the EWS address, enabling impersonation and providing credentials at the command line:

.\Import-MailboxContacts.ps1 -CSVFileName .\Contacts.csv –EmailAddress steve@contoso.com -Impersonate $true -Username serviceaccount -Password password -Domain contoso

In addition to the options above, you can also specify the parameters -Exchange2007 $true and use -EWSManagedApiDLLFilePath to specify a different path the the EWS DLL.

Powershell Code

Finally, you’ll need a copy of the code to do all this. At the bottom of the post you’ll find a ZIP file containing the Import-MailboxContacts.ps1 file and a sample CSV file, and below you’ll see the code itself. Happy importing!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290

param([string]$CSVFileName,[string]$EmailAddress,[string]$Username,[string]$Password,[string]$Domain,[bool]$Impersonate,[string]$EwsUrl,[string]$EWSManagedApiDLLFilePath,[bool]$Exchange2007);

#
# Import-MailboxContacts.ps1
#
# By Steve Goodman, Use at your own risk.
#
# Parameters
# Mandatory:
# -CSVFileName : Filename of the CSV file to import contacts for this user from. Same format as Outlook Export.
# -EmailAddress : Account SMTP email address. Required, but only used when impersonating or with Autodiscover - otherwise uses the user you login as
# Optional:
# -Impersonate : Set to $true to use impersonation.
# -Username : The username to use. If this isn't specified (along with Password), attempts to use the logged on user.
# -Password : Used with above
# -Domain : Used with above - optional.
# -EwsUrl : The URL for EWS if you don't want to use Autodiscover. Typically https://casserver/EWS/Exchange.asmx
# -EWSManagedApiDLLFilePath : (Optional) Overwrite the filename and path to the DLL for EWS Managed API. By default, uses the default install location.
# -Exchange2007 : Set to $true to use the Exchange 2007 SP1+ version of the Managed API.
#

# Contact Mapping - this maps the attributes in the CSV file (left) to the attributes EWS uses.
# NB: If you change these, please note "First Name" is specified at line 102 as a required attribute and
# "First Name" and "Last Name" are hard coded at lines 187-197 when constructing NickName and FileAs.
$ContactMapping=@{
"First Name" = "GivenName";
"Middle Name" = "MiddleName";
"Last Name" = "Surname";
"Company" = "CompanyName";
"Department" = "Department";
"Job Title" = "JobTitle";
"Business Street" = "Address:Business:Street";
"Business City" = "Address:Business:City";
"Business State" = "Address:Business:State";
"Business Postal Code" = "Address:Business:PostalCode";
"Business Country/Region" = "Address:Business:CountryOrRegion";
"Home Street" = "Address:Home:Street";
"Home City" = "Address:Home:City";
"Home State" = "Address:Home:State";
"Home Postal Code" = "Other:Home:PostalCode";
"Home Country/Region" = "Address:Home:CountryOrRegion";
"Other Street" = "Address:Other:Street";
"Other City" = "Address:Other:City";
"Other State" = "Address:Other:State";
"Other Postal Code" = "Address:Other:PostalCode";
"Other Country/Region" = "Address:Other:CountryOrRegion";
"Assistant's Phone" = "Phone:AssistantPhone";
"Business Fax" = "Phone:BusinessFax";
"Business Phone" = "Phone:BusinessPhone";
"Business Phone 2" = "Phone:BusinessPhone2";
"Callback" = "Phone:CallBack";
"Car Phone" = "Phone:CarPhone";
"Company Main Phone" = "Phone:CompanyMainPhone";
"Home Fax" = "Phone:HomeFax";
"Home Phone" = "Phone:HomePhone";
"Home Phone 2" = "Phone:HomePhone2";
"ISDN" = "Phone:ISDN";
"Mobile Phone" = "Phone:MobilePhone";
"Other Fax" = "Phone:OtherFax";
"Other Phone" = "Phone:OtherTelephone";
"Pager" = "Phone:Pager";
"Primary Phone" = "Phone:PrimaryPhone";
"Radio Phone" = "Phone:RadioPhone";
"TTY/TDD Phone" = "Phone:TtyTddPhone";
"Telex" = "Phone:Telex";
"Anniversary" = "WeddingAnniversary";
"Birthday" = "Birthday";
"E-mail Address" = "Email:EmailAddress1";
"E-mail 2 Address" = "Email:EmailAddress2";
"E-mail 3 Address" = "Email:EmailAddress3";
"Initials" = "Initials";
"Office Location" = "OfficeLocation";
"Manager's Name" = "Manager";
"Mileage" = "Mileage";
"Notes" = "Body";
"Profession" = "Profession";
"Spouse" = "SpouseName";
"Web Page" = "BusinessHomePage";
"Contact Picture File" = "Method:SetContactPicture"
}

# CSV File Checks
# Check filename is specified
if (!$CSVFileName)
{
throw "Parameter CSVFileName must be specified";
}

# Check file exists
if (!(Get-Item -Path $CSVFileName -ErrorAction SilentlyContinue))
{
throw "Please provide a valid filename for parameter CSVFileName";
}

# Check file has required fields and check if is a single row, or multiple rows
$SingleItem = $false;
$CSVFile = Import-Csv -Path $CSVFileName;
if ($CSVFile."First Name")
{
$SingleItem = $true;
} else {
if (!$CSVFile[0]."First Name")
{
throw "File $($CSVFileName) must specify at least the field 'First Name'";
}
}

# Check email address
if (!$EmailAddress)
{
throw "Parameter EmailAddress must be specified";
}
if (!$EmailAddress.Contains("@"))
{
throw "Parameter EmailAddress does not appear valid";
}

# Check EWS Managed API available
if (!$EWSManagedApiDLLFilePath)
{
$EWSManagedApiDLLFilePath = "C:\Program Files\Microsoft\Exchange\Web Services\1.0\Microsoft.Exchange.WebServices.dll"
}
if (!(Get-Item -Path $EWSManagedApiDLLFilePath -ErrorAction SilentlyContinue))
{
throw "EWS Managed API not found at $($EWSManagedApiDLLFilePath). Download from http://bit.ly/9O7gLo";
}

# Load EWS Managed API
[void][Reflection.Assembly]::LoadFile("C:\Program Files\Microsoft\Exchange\Web Services\1.0\Microsoft.Exchange.WebServices.dll");

# Create Service Object
if ($Exchange2007)
{
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)
} else {
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010)
}
# Set credentials if specified, or use logged on user.
if ($Username -and $Password)
{
if ($Domain)
{
$service.Credentials = New-Object Microsoft.Exchange.WebServices.Data.WebCredentials($Username,$Password,$Domain);
} else {
$service.Credentials = New-Object Microsoft.Exchange.WebServices.Data.WebCredentials($Username,$Password);
}

} else {
$service.UseDefaultCredentials = $true;
}

# Set EWS URL if specified, or use autodiscover if no URL specified.
if ($EwsUrl)
{
$service.URL = New-Object Uri($EwsUrl);
} else {
try {
$service.AutodiscoverUrl($EmailAddress);
} catch {
throw;
}
}

# Perform a test - try and get the default, well known contacts folder.

if ($Impersonate)
{
$service.ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $EmailAddress);
}
try {
$ContactsFolder = [Microsoft.Exchange.WebServices.Data.ContactsFolder]::Bind($service, [Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Contacts);
} catch {
throw;
}

# Add contacts
foreach ($ContactItem in $CSVFile)
{
# If impersonate is specified, do so.
if ($Impersonate)
{
$service.ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $EmailAddress);
}

$ExchangeContact = New-Object Microsoft.Exchange.WebServices.Data.Contact($service);
if ($ContactItem."First Name" -and $ContactItem."Last Name")
{
$ExchangeContact.NickName = $ContactItem."First Name" + " " + $ContactItem."Last Name";
}
elseif ($ContactItem."First Name" -and !$ContactItem."Last Name")
{
$ExchangeContact.NickName = $ContactItem."First Name";
}
elseif (!$ContactItem."First Name" -and $ContactItem."Last Name")
{
$ExchangeContact.NickName = $ContactItem."Last Name";
}
$ExchangeContact.DisplayName = $ExchangeContact.NickName;
$ExchangeContact.FileAs = $ExchangeContact.NickName;

$BusinessPhysicalAddressEntry = New-Object Microsoft.Exchange.WebServices.Data.PhysicalAddressEntry;
$HomePhysicalAddressEntry = New-Object Microsoft.Exchange.WebServices.Data.PhysicalAddressEntry;
$OtherPhysicalAddressEntry = New-Object Microsoft.Exchange.WebServices.Data.PhysicalAddressEntry;

# This uses the Contact Mapping above to save coding each and every field, one by one. Instead we look for a mapping and perform an action on
# what maps across. As some methods need more "code" a fake multi-dimensional array (seperated by :'s) is used where needed.
foreach ($Key in $ContactMapping.Keys)
{
# Only do something if the key exists
if ($ContactItem.$Key)
{
# Will this call a more complicated mapping?
if ($ContactMapping[$Key] -like "*:*")
{
# Make an array using the : to split items.
$MappingArray = $ContactMapping[$Key].Split(":")
# Do action
switch ($MappingArray[0])
{
"Email"
{
$ExchangeContact.EmailAddresses[[Microsoft.Exchange.WebServices.Data.EmailAddressKey]::($MappingArray[1])] = $ContactItem.$Key;
}
"Phone"
{
$ExchangeContact.PhoneNumbers[[Microsoft.Exchange.WebServices.Data.PhoneNumberKey]::($MappingArray[1])] = $ContactItem.$Key;
}
"Address"
{
switch ($MappingArray[1])
{
"Business"
{
$BusinessPhysicalAddressEntry.($MappingArray[2]) = $ContactItem.$Key;
$ExchangeContact.PhysicalAddresses[[Microsoft.Exchange.WebServices.Data.PhysicalAddressKey]::($MappingArray[1])] = $BusinessPhysicalAddressEntry;
}
"Home"
{
$HomePhysicalAddressEntry.($MappingArray[2]) = $ContactItem.$Key;
$ExchangeContact.PhysicalAddresses[[Microsoft.Exchange.WebServices.Data.PhysicalAddressKey]::($MappingArray[1])] = $HomePhysicalAddressEntry;
}
"Other"
{
$OtherPhysicalAddressEntry.($MappingArray[2]) = $ContactItem.$Key;
$ExchangeContact.PhysicalAddresses[[Microsoft.Exchange.WebServices.Data.PhysicalAddressKey]::($MappingArray[1])] = $OtherPhysicalAddressEntry;
}
}
}
"Method"
{
switch ($MappingArray[1])
{
"SetContactPicture"
{
if (!$Exchange2007)
{
if (!(Get-Item -Path $ContactItem.$Key -ErrorAction SilentlyContinue))
{
throw "Contact Picture File not found at $($ContactItem.$Key)";
}
$ExchangeContact.SetContactPicture($ContactItem.$Key);
}
}
}
}

}
} else {
# It's a direct mapping - simple!
if ($ContactMapping[$Key] -eq "Birthday" -or $ContactMapping[$Key] -eq "WeddingAnniversary")
{
[System.DateTime]$ContactItem.$Key = Get-Date($ContactItem.$Key);
}
$ExchangeContact.($ContactMapping[$Key]) = $ContactItem.$Key;
}

}
}
# Save the contact
$ExchangeContact.Save();

# Provide output that can be used on the pipeline
$Output_Object = New-Object Object;
$Output_Object | Add-Member NoteProperty FileAs $ExchangeContact.FileAs;
$Output_Object | Add-Member NoteProperty GivenName $ExchangeContact.GivenName;
$Output_Object | Add-Member NoteProperty Surname $ExchangeContact.Surname;
$Output_Object | Add-Member NoteProperty EmailAddress1 $ExchangeContact.EmailAddresses[[Microsoft.Exchange.WebServices.Data.EmailAddressKey]::EmailAddress1]
$Output_Object;
}

Download as ZIP

Tagged as: EWS, Exchange2010, exchangeserver2010, Powershell 3 Comments

20May/102

Does your domain start with “live."? Expect problems with Outlook 2010! [Updated with workaround]

Over on the Outlook Live forums today we discovered a very strange issue with Outlook 2010’s account setup preventing Exchange autodiscover from working for some domains. If your domain starts with “live.” then the Autodiscover and Guessmart processes don’t even kick in. You get prompted straight away to install the Hotmail Connector:

As you can see in the above example the domain doesn’t even exist. A NetMon trace shows no attempt to check the domain to somehow link it to Hotmail, and if you use the Test E-Mail Auto configuration utility it follows the “real” logic and doesn’t alert you to this problem.

Any information on exactly why this does this isn’t already out there – the closest I’ve come to an answer is over on the Outlook blog, here. If you know more – feel free to leave a comment. In the meantime I’ll be doing some more research.

Update 1 27/05/2010 – I have a solution from Microsoft for the issue. Just waiting for confirmation before I post.

Update 2 01/06/2010 - Workaround below:

NB: The following instructions are for use at your own risk. If you aren't sure what you are doing, get a professional to assist and always ensure you have an up-to-date backup that you know how to restore.

Open Registry Editor and navigate to:
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\AutoConfigDomains
Remove the following key:
live.*

This will of course make it so name@live.com will not autoconfigure with the Hotmail Connector.

If you want that that to still work change the Key name to HKLM\Software\Microsoft\Office\Outlook\AutoConfigDomains\live.com

Tagged as: Exchange, Outlook2010 2 Comments

11Mar/100

Checking for unmanaged Live IDs in Outlook Live

This isn’t a post for everyone – it’s aimed at Administrators of a Live@EDU / Outlook Live environment who are looking to find existing unmanaged EASI IDs / Windows Live IDs on the domain they’ve brought onto Outlook Live.

If you’re using automated provisioning you’ll find this can be a problem as when you use the New-Mailbox cmdlet it will fail, and you’ll have to re-run it with either the –ImportLiveID or –EvictLiveID options. This script allows you to get a CSV input file, with the column Username and generate a list of the status of the Live IDs so you can embark on your batch creation knowing where you stand.

Usage: .\Check-Unmanaged.ps1 -AdminUsername admin@uni.edu -AdminPassword Pa$$w0rd -InputFile .\input.csv -OutputFile .\output.csv

The -AdminUsername is typically you’re Outlook Live admin. It needs to be able to connect to the Windows Live Admin web service .-OutputFile is optional - results are printed to the screen also. For each user in your domains you will see either InUse for managed IDs, InUseUnmanaged for IDs you need to evict/import to use and Available for IDs not in use.

The included DLL, ManageDomain2.dll is required. This is auto-generated from the WSDL. If you wish to generate your own you need Visual Studio 2008 or similar. See the source of the ps1 file for the two-lines you need to re-generate the DLL - it's just a proxy web service library.

(NB. No warranty is provided with this script, it is provided as-is and any damage it may do is your responsibility. Please use on your own test environment first. That said - apart from connecting to the service, the main method used is GetMemberNameState)

Download CheckUnmanaged.zip

Tagged as: outlook live, Powershell, unmanaged, windows live ids No Comments

19Feb/101

Writing Powershell scripts that target Exchange 2007 and 2010

If you’re planning a migration to Exchange 2010 that won’t be completed overnight, you may want to be able to run Exchange Powershell scripts that execute both Exchange 2007 and 2010 cmdlets from the same script. There’s a few reasons for doing this, including:

If you use logic to determine where to place new user mailboxes, and some mailboxes will be on 2007 and some on 2010.
If you create new mailboxes on Exchange 2007 and then add the new mailbox to a Exchange 2010 distribution group (for example, if you use moderated distribution groups).
If you’re using Outlook Live (Live@EDU hosted Exchange 2010) and create MailUsers on-premise and Mailboxes in the hosted environment.
You are using the Transporter suite to migrate mail and need to create mailboxes on a temporary Exchange 2007 server, migrate mail, and then move mailboxes to Exchange 2010.

OK – so my examples are mostly about provisioning and these are real-life examples of where I’ve used this method, but I’m sure you can think of other examples where it might be useful to you. So – what do you need?

Exchange 2007 SP2 management tools on any OS that supports them.
Powershell 2.0
Remote Powershell enabled on the account you run the script as (using Set-User username –RemotePowerShellEnabled:$true)

You can use this on Windows Server 2003 R2, x86; no Exchange 2010 management tools are required. Enough of what you need – here’s what you need to put in your Powershell scripts to do Exchange 2007/2010:

# Add Exchange 2007. If you'll always run from the Exchange Management Shell, you don't need the next line.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

# Exchange 2007 Commands Go Here - i.e.

Get-MailboxDatabase

# Unload Exchange 2007

Remove-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

# Create Remote Powershell session with Exchange 2010 - edit the server name in ConnetionUri

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://exchange.contoso.com/powershell/ -Authentication Kerberos

Import-PSSession $Session

# Exchange 2010 Commands Go Here - i.e.

Get-MailboxDatabase

# Unload Exchange 2010

Remove-PSSession $Session

If you’re looking to connect to Outlook Live instead of Exchange 2010, simply replace the line beginning “$Session =” with a couple of lines similar to this:

$LiveCred = New-Object System.Management.Automation.PSCredential "yourliveadmin@contoso.edu", (ConvertTo-SecureString "password" -AsPlainText -Force)

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection -WarningAction SilentlyContinue

Hope this helps!

Steve

Tagged as: Exchange, Exchange 2010, Exchange2007, outlook live, Powershell, Remote Powershell 1 Comment

Using Powershell to import contacts into Exchange and Outlook Live

Getting started

Using the script Import-MailboxContacts.ps1

Does your domain start with “live."? Expect problems with Outlook 2010! [Updated with workaround]

Checking for unmanaged Live IDs in Outlook Live

Writing Powershell scripts that target Exchange 2007 and 2010

More from StevieG.org

Find Me On

Recent Posts

Top posts

Blogroll

Categories

Tags