If you would like to read the other parts in this article series please go to
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 1)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 2)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 3)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 5)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 6)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 7)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 8)
Introduction
In part the first two parts of this series we looked at the simplest scenarios for moving mailboxes from Office 365 to an on-premise Exchange server, demonstrating how easy it is to move mailboxes around if we need to.
Part three began to look at our main scenario – moving a complete standalone tenant to a new Exchange 2010 organization. In the previous article we performed pre-requisite checks against the environment and exported user, group and group information. In this part of the series, we’ll create matching accounts in Exchange, and begin to configure DirSync.
Creating On-Premise Users, Contacts and Groups
After exporting user information, copy it to an appropriate location on the Exchange Server or computer with the Exchange Management tools installed. We’ll be creating matching users, contacts and groups using the following mappings:
Exchange Online Object |
Exchange On Premises Object |
Mailbox |
Remote Mailbox |
Mail User |
Mail User |
Contact |
Contact |
Distribution Group |
Distribution Group |
Table 1
The main difference in the mappings table shown above is that Exchange Online Mailboxes become Remote Mailboxes on Exchange on-premises. This means Exchange knows that there is a Mailbox in the cloud, and later on it will enable us to move the mailbox from Office 365 to Exchange Online.
For us to gain the ability to create a Remote Mailbox, we’ll need to implement an element of the Hybrid mode feature set before creating local users. The Remote Mailbox functionality relies on a Remote Domain being defined in Exchange with the Use this domain for my Office 365 tenant option set in the Exchange Management Console, or -TargetDeliveryDomain parameter set via the Exchange Management Shell. The format for the routing domain is based upon our tenant name, in the following form:
<tenantname>.mail.onmicrosoft.com
We’ll create the remote domain from the Exchange Management Shell using the following cmdlets:
$Tenant="exchlabs"
New-RemoteDomain -Name "Hybrid Domain - $($Tenant).mail.onmicrosoft.com" -DomainName "$($Tenant).mail.onmicrosoft.com" | Set-RemoteDomain -IsCoexistenceDomain:$true
If we examine the resulting Remote Domain in the Exchange Management Console, we’ll see that it’s correctly created the domain within Organization Configuration>Hub Transport under Remote Domains:
Figure 1: The Remote Domain used for Hybrid mail routing between on-premises Exchange and Office 365
You may note we’ve chosen a specific naming format for the Remote Domain. This is to match the format the Hybrid Configuration wizard will expect when we configure this later on.
We’ll also need to decide where our users, contacts and groups will be located in Active Directory. Feasibly this can be wherever you choose within your Active Directory forest; but for our example organization we’ve chosen to locate all users within an Office365 organizational unit during the migration:
Figure 2: Creating the organizational unit used to locate Office 365 objects
This will allow us to demonstrate a more advanced feature, DirSync Filtering. There’s no need to synchronize other Active Directory accounts to Office 365 except from those that we’ll create in a few moments, therefore we’ll configure DirSync later in the article to only synchronize against the Office365 OU. Whilst not essential for this article, if you are migrating accounts into an existing Exchange organization you’ll find this feature a blessing.
With our Remote Domain configured and Organizational Unit chosen, we’ll now look to use the Export files we’ve copied to the Exchange Server.
Importing Users and Contacts
Our first task is to import users and contacts exported in the previous part of this article, and set some basic information including the Common Accepted Domain, Remote Routing Domain and Organizational Unit.
Because we can’t retrieve their password, we’ve chosen to set a common password for these users, giving us the option later to change the passwords before migrating each mailbox.
$MigrationDomain="exchangelabs.co.uk"
$RemoteDomain="exchlabs.mail.onmicrosoft.com"
$OU="exchangelabs.co.uk/Office365"
$Password = ConvertTo-SecureString "Pa$$w0rd" -AsPlainText -Force
$Recipients = Import-CliXML .\Recipients.xml | Where {$_.WindowsLiveID -like "*@$($MigrationDomain)"}
$Users = Import-CliXML .\Users.xml | Where {$_.UserPrincipalName -like "*@$($MigrationDomain)"}
$Mailboxes = Import-CliXML .\Mailboxes.xml | Where{$_.UserPrincipalName -like "*@$($MigrationDomain)"}
$Contacts = Import-CliXML .\Recipients.xml | Where {$_.RecipientType -eq "MailContact"}
With the user and contact details imported, we’ll then create our Remote Mailboxes to match those in the cloud, using a ForEach loop and the New-RemoteMail/Set-RemoteMailbox cmdlets:
$Recipients|where{$_.RecipientTypeDetails -eq "EquipmentMailbox"}|foreach{
New-RemoteMailbox -Equipment -Name:$_.Name -SamAccountName:$_.SamAccountName -UserPrincipalName:$_.WindowsLiveID -Alias:$_.Alias -PrimarySMTPAddress:$_.PrimarySMTPAddress -OnPremisesOrganizationalUnit:$OU -RemoteRoutingAddress:"$($_.Alias)@$($RemoteDomain)"
Set-RemoteMailbox $_.WindowsLiveID -EmailAddresses:$_.EmailAddresses
}
$Recipients|where{$_.RecipientTypeDetails -eq "RoomMailbox"}|foreach{
New-RemoteMailbox -Room -Name:$_.Name -SamAccountName:$_.SamAccountName -UserPrincipalName:$_.WindowsLiveID -Alias:$_.Alias -PrimarySMTPAddress:$_.PrimarySMTPAddress -OnPremisesOrganizationalUnit:$OU -RemoteRoutingAddress:"$($_.Alias)@$($RemoteDomain)"
Set-RemoteMailbox $_.WindowsLiveID -EmailAddresses:$_.EmailAddresses
}
$Recipients|where{$_.RecipientTypeDetails -eq "UserMailbox" -or $_.RecipientTypeDetails -eq "SharedMailbox" }|foreach{
New-RemoteMailbox -Name:$_.Name -SamAccountName:$_.SamAccountName -UserPrincipalName:$_.WindowsLiveID -Alias:$_.Alias -PrimarySMTPAddress:$_.PrimarySMTPAddress -OnPremisesOrganizationalUnit:$OU -RemoteRoutingAddress:"$($_.Alias)@$($RemoteDomain)" -Password:$Password
Set-RemoteMailbox $_.WindowsLiveID -EmailAddresses:$_.EmailAddresses
}
$Mailboxes|foreach{
Set-RemoteMailbox $_.UserPrincipalName -ExchangeGUID $_.ExchangeGUID
}
Next, when Mail Users (accounts in Office 365 without Mailboxes) are required, we can create matching accounts:
$Recipients|where{$_.RecipientType -eq "MailUser"}|foreach{
New-MailUser -Name:$_.Name -Alias:$_.Alias -SamAccountName:$_.SamAccountName -UserPrincipalName:$_.WindowsLiveID -PrimarySMTPAddress:$_.PrimarySMTPAddress -OrganizationalUnit:$OU -ExternalEmailAddress:$_.ExternalEmailAddress -Password:$Password
Set-MailUser $_.WindowsLiveID -EmailAddresses:$_.EmailAddresses
}
After creating the base Remote Mailboxes and Mail Users in Exchange, we can also set additional Active Directory properties based upon User data retrieved from Office 365:
$Users|foreach{
Set-User $_.UserPrincipalName -City:$_.City -Company:$_.Company -Department:$_.Department
Set-User $_.UserPrincipalName -Fax:$_.Fax -FirstName:$_.FirstName -Initials:$_.Initials
Set-User $_.UserPrincipalName -LastName:$_.LastName -MobilePhone:$_.MobilePhone -Notes:$_.Notes
Set-User $_.UserPrincipalName -Office:$_.Office -Phone:$_.Phone -PostalCode:$_.PostalCode
Set-User $_.UserPrincipalName -StateOrProvince:$_.StateOrProvince -StreetAddress:$_.StreetAddress -Title:$_.Title
}
Finally, if contacts have been created in Office 365 we can create corresponding contacts within Exchange on-premises:
$Contacts|foreach{
New-MailContact -Name:$_.Name -Alias:$_.Alias -PrimarySmtpAddress:$_.PrimarySmtpAddress -ExternalEmailAddress:$_.ExternalEmailAddress -OrganizationalUnit:$OU
Set-MailContact $_.PrimarySmtpAddress -EmailAddresses:$_.EmailAddresses -DisplayName:$_.DisplayName
}
After importing user data, examine the remote mailboxes, contacts and mail users within the Exchange Management Console, within Recipient Configuration>Mail Contact:
Figure 3: Viewing the imported users and contacts within the Exchange Management Shell
An important point to note with account details imported is that you may need to customize the scripts to meet your particular situations needs, for example if additional properties are set that are not captured or set by the examples in this article.
Importing Distribution Groups
After importing user information our next step is to import Distribution Groups and Group members into the local Active Directory, again using our exported information.
Our first step is to import the Distribution Group and member information using the data exported from Office 365:
$OU="exchangelabs.co.uk/Office365"
$DistributionGroups = Import-Clixml .\DistributionGroups.xml
$DGMembers = Import-Clixml .\DGMembers.xml
After importing the data, we can then use a foreach loop to iterate through each Distribution Group, and then for each DG, create an array containing that group’s members and finally create the new distribution group:
foreach($DG in $DistributionGroups){
$ThisDGMembers=$DGMembers|Where {$_.Group -eq $DG.Name}|%{$_.PrimarySmtpAddress}
New-DistributionGroup -Name:$DG.Name -Alias:$DG.Alias -DisplayName:$DG.DisplayName -PrimarySmtpAddress:$DG.PrimarySmtpAddress -SamAccountName:$DG.SamAccountName -OrganizationalUnit $OU -Members $ThisDGMembers
}
Once we’ve created the groups and members, we’ll finally examine the results within the Exchange Management Console, within Recipient Configuration>Distribution Group:
Figure 4: Viewing the imported Distribution Groups within the Exchange Management Shell
As with the imported users, the examples in this article don’t cater for every property set against groups in Office 365, therefore if the tenant you are importing uses features not covered by these examples you will need to make adjustments.
Implementing DirSync
We’ve now populated our local Exchange 2010 organization, and it almost looks like we’re joined up with Office 365. Remote Mailboxes, Distribution Groups, Contacts and Mail Enabled users all match up.
Now it’s time to revisit the Office 365 Portal and check the status of Active Directory synchronization on the Users page listed under Management. Choose the option to Set up:
Figure 5: Navigating within the Office 365 portal to confirm DirSync is enabled
We should then see confirmation under section 3 that Active Directory Synchronization is enabled (shown below underlined). If that’s the case, choose to Download the Directory Sync Tool:
Figure 6: Downloading DirSync from the Office 365 portal
After downloading the Directory Synchronization tool, we’ll attempt to install it on the server we’ve chosen to act as our standalone DirSync server that meets the requirements published by Microsoft. In particular, our server has the following characteristics:
- Windows Server 2008 R2 SP1
- PowerShell 2.0 and .NET Framework 3.5 SP1 features enabled
We’ll then copy the DirSync.exe download to the server and begin the installation wizard:
Figure 7: Initiating setup of DirSync
Follow the installation wizard to initiate the installation. After accepting the terms and conditions for installation wait for a few minutes while the underlying SQL Server Express database server and ForeFront Identity Manager components are installed:
Figure 8: Installing DirSync components
After the installation completes, leave the checkbox Start the Configuration Wizard now ticked, then press Finish:
Figure 9: Completing the installation of DirSync
The Microsoft Online Services Directory Synchronization Configuration Wizard should begin. When prompted, enter the Office 365 tenant administrator credentials. These will be used by the underlying service to synchronize with Office 365, therefore consider setup of a separate account with password expiry disabled if you envisage a longer period of migration:
Figure 10: Entering Office 365 tenant administrator credentials
On the next page of the wizard you will be prompted for Administrator credentials to access Active Directory. The credentials used within setup are not saved after the wizard completes, and are used to create a dedicated account used for Directory Sync within Active Directory:
Figure 11: Entering Active Directory Administrator credentials
On the Exchange Hybrid deployment page, select the checkbox Enable Exchange hybrid deployment, then choose Next to begin the configuration of the underlying services:
Figure 12: Enabling Hybrid features for DirSync
After the configuration completes you will see the final page of the wizard. It’s important you uncheck the checkbox Synchronize directories now, then press Finish:
Figure 13: Ensuring DirSync does not attempt initial synchornization
Before we begin synchronizing directories we need to verify that we will synchronize the correct information, therefore to ensure that the scheduled synchronization task does not begin, we’ll open the Services management console and stop the Microsoft Online Services Directory Synchronization Service. To perform this task, choose Start>Run and enter services.msc then press OK:
Figure 14: Opening the Services Management Console
In the Services management console, locate the aforemention Microsoft Online Services Directory Synchronization Service, and choose Stop. If you suspect the server may reboot before you are able to verify and alter DirSync settings, change the Startup Type to Manual:
Figure 15: Stopping and disabling the DirSync service
With DirSync installed, configured and subsequently disabled we are now ready to perform the supported reconfiguration to only synchronize the chosen Organizational Units with Active Directory, and with DirSync stopped we will be able to step through the initial synchronization process and ensure that the correct Active Directory accounts are synchronized; all of which we’ll cover in the next part of this series.
Summary
In this part of this multi-part article we’ve imported accounts and distribution groups from our Office 365 tenant into our fresh Active Directory and Exchange 2010 installation. We’ve also performed the initial configuration of DirSync ready for further configuration.
If you would like to read the other parts in this article series please go to
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 1)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 2)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 3)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 5)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 6)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 7)
- Migrating a standalone Office 365 tenant to Exchange 2010 (Part 8)