If you would like to read the other parts in this article series please go to:
- Off-boarding email from Office 365 to Exchange 2013 (Part 1)
- Off-boarding email from Office 365 to Exchange 2013 (Part 3)
- Off-boarding email from Office 365 to Exchange 2013 (Part 4)
- Off-boarding email from Office 365 to Exchange 2013 (Part 5)
- Off-boarding email from Office 365 to Exchange 2013 (Part 6)
Creating AD and Exchange on-premises objects
Copy the exported XML files from part one of this series into a location on the Exchange Server. 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 combined with the ExchangeGUID attributes set 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 -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 -TargetDeliveryDomain:$true -Identity “Hybrid Domain – $($Tenant).mail.onmicrosoft.com” |
Figure 1: The Remote Domain used for Hybrid mail routing between on-premises Exchange and Office 365
The format we have chosen when creating the name for the Remote Domain is intention. This is intended to match the format the Hybrid Configuration Wizard will use when we configure this later on.
We’ll also need to decide where our users, contacts and groups will be located in Active Directory. 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:
Figure 2: Creating the organizational unit used to locate Office 365 objects
This will allow us to use a feature called DirSync Filtering. This specifically allows us to avoid synchronizing any irrelevant accounts (such as service accounts) to Office 365. We’ll configure Windows Azure AD Sync in the next part of this series to only synchronize the Office365 OU.
With our Remote Domain configured and Organizational Unit chosen, we’ll now use the export files we’ve copied to the Exchange Server.
Creating Users and Contacts
Our first task is to import users and contacts exported in the part one of the series, 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 – at least for the time of account creation.
| $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 Admin Center, within Recipients, selecting the Mailboxes and Contacts tabs:
Figure 3: Viewing the imported users within the Exchange Admin Center
Two important point to note are firstly that you may need to customize the scripts to meet your particular needs, for example if additional properties are set that are not captured or set by the examples in this article.
Secondly – it’s expected that before you configure Password Sync you will change each user password and issue them out – after DirSync is enabled they will need that password to access Office 365:
Creating 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 Admin Center, within Recipients and under the Groups tab:
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.
Installing Windows Azure Active Directory Sync
After creating matching accounts in our local AD and Exchange 2013 implementation we should now have a mirror of the state of Azure AD and Exchange Online on-premises ready to link up.
We’ll now login to the Office 365 portal and after checking Directory Sync is enabled, download the correct version of Azure AD Sync.
To do this, navigate to Users>Active Users and then under Active Directory synchronization choose the option to Manage:
Figure 5: Navigating within the Office 365 portal to download the Azure AD Sync tool
We should then see confirmation under section 3 that Active Directory Synchronization is enabled. 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 DirSync server that meets the requirements published by Microsoft.
We’ll then copy the DirSync.exe download to the server and begin the installation wizard.
Follow the installation wizard to initiate the installation. After accepting the terms and conditions for installation wait for a few minutes while the components (such as SQL Server and FIM) are installed:
Figure 7: Installing Azure AD Sync components
After the installation completes, leave the checkbox Start the Configuration Wizard now ticked, then press Finish:
Figure 8: Completing the installation of Azure AD Sync
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 9: 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 10: 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 11: Enabling Hybrid features for DirSync
Next, we’ll choose to enable Password Hash Sync. This will, once we have finished configuring Azure AD Sync in the next part of this series, change the Office 365 passwords to match their on-premises equivalents:
Figure 12: Enabling Password Hash Sync
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 Azure AD Sync does not attempt initial synchronization
Before our first synchronization between AD and Azure AD, we will need to verify that we will synchronize the correct information. Therefore, to ensure that the synchronization task does not begin, we’ll open the Services management console and stop the Widows Azure Active 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 Windows Azure Active Directory Synchronization Service, and choose Stop.
If you suspect the server may reboot before you are able to verify and alter Azure AD Sync settings, change the Startup Type to Manual:
Figure 15: Stopping and setting the Azure AD Sync service to manual
Summary
In this part of the series we’ve created on-premises accounts to match the cloud and installed then disabled Azure AD Sync. In the next part of this series we’ll configure and test Azure AD Sync before performing the initial match and synchronization.
If you would like to read the other parts in this article series please go to:
- Off-boarding email from Office 365 to Exchange 2013 (Part 1)
- Off-boarding email from Office 365 to Exchange 2013 (Part 3)
- Off-boarding email from Office 365 to Exchange 2013 (Part 4)
- Off-boarding email from Office 365 to Exchange 2013 (Part 5)
- Off-boarding email from Office 365 to Exchange 2013 (Part 6)
Hi Steve
I already had ADDSync with password synchronization running in my environment before the deployment. Which parts of the script do I leave out?
I’m busy offboarding (to Exchange 2016). When you have a Shared mailbox in Office 365 and you add this Shared mailbox as a RemoteMailbox (as written on this page), the mailbox is disappeared from the Shared mailbox section within Office 365 but will be shown within the User mailboxes. I’ve found some sites mention to change some Attributes in the Active Directory account. I’ve not done this, is this necesarry?
Hello,
You can temporarily use convert to shared mailbox in the Exchange Online admin center – though this will be reverted back should you make further changes to the object.
Then migrate it back to on premises, and if needed set it as an on premises mailbox.
Steve
Hi Steve,
Thank you for taking the time to write all this up!
I am very good at following instructions, however, I am getting stuck at the importing the users section and cannot figure out how to move forward. I would also like to point out that I am migrating to Exchange 2016 is that makes and difference – I don’t think it does.
This is an amazing writeup. How would the process differ if the target domain was prepopulated with the users already?
Hi, the post is one of the best I saw on the internet after googling for days.
I have on difference only and that is the users are already created in the AD no sync with O365 nothing there as if standalone but the same domain what step should be replaced ?