Migrating a standalone Office 365 tenant to Exchange 2010 (Part 4)

If you would like to read the other parts in this article series please go to

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:

Image
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:

Image
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:

Image
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:

Image
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:

Image
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:

Image
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:

Image
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:

Image
Figure 8:
Installing DirSync components

After the installation completes, leave the checkbox Start the Configuration Wizard now ticked, then press Finish:

Image
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:

Image
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:

Image
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:                         

Image
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:

Image
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:

Image
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:

Image
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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top