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 4)
- 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 parts one and two of this series, we looked at a simple scenario for migrating mailboxes back from Office 365. After seeing that it’s actually rather simple, the rest of this article focuses on how we put together everything else around it if we’re looking to migrate an entire organization from Exchange Online to Exchange 2010 on-premises.
Parts three and four of this series looked at how to populate our local Active Directory and Exchange organization with a mirror of what we already have in Office 365; after which we installed the Microsoft Online Services Directory Sync Tool – DirSync. In this part of the series, we’ll now look at what’s under the hood of DirSync, perform reconfiguration to ensure we only synchronize a specific Organization Unit then after checking everything is in order, perform an initial synchronization.
Under the hood of DirSync
Microsoft’s DirSync tool may appear to be a black box, however under the hood the engine driving DirSync is Microsoft Forefront Identity Manager 2010 (FIM) alongside Microsoft SQL Server. FIM is a synchronization engine that uses a number of Management Agents to connect to different identity sources or targets.
For DirSync, a local Active Directory agent is configured, known within FIM as SourceAD and a target Office 365 agent is configured, known as the TargetWebService. Changes within the local Active Directory forest are pulled in via the SourceAD agent and after synchronization to the local FIM metadirectory (which consists of the metaverse and the connector space) are pushed out to Office 365 via the TargetWebService agent. In Hybrid configurations, certain attributes from Office 365 are also written back to the source Active Directory.
You’ll find a full list of attributes that are synchronized by DirSync both to and from Office 365 using this link.
Now we know a little bit more about what DirSync is and does, we’ll launch the FIM Synchronization Service Manager on our DirSync server. You’ll find this GUI-based tool at the following location, assuming you’ve installed DirSync into the default location, named miisclient.exe:
C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell
Figure 1: DirSync’s Management GUI file system location
After launching the Synchronization Service Manager for the first time, you’ll find it initially looks rather empty. That’s OK, as we’ve not attempted to synchronize anything just yet:
Figure 2: The Operations tab of the Synchronization Service Manager
The two tabs we’re interested in are shown above – the first two. The Operations tab will show the log of actions taken, and allow us to examine previous synchronization jobs. The Management tab, where we’ll look at next, is used to configure each Management Agent and also allows us to initiate execution of each agent:
Figure 3: The Management Agents tab of the Synchronization Service Manager
Reconfiguring the scope for DirSync
While optional, we’ve chosen to reconfigure the scope for DirSync to only use on a specific organizational unit with within our on-premises Active Directory.
On the Management Agents tab of the Synchronization Service Manager, select the SourceAD Management Agent and then choose Properties from the Actions pane as shown above. You’ll then see the Properties for that management agent.
Under the heading Management Agent Designer, select Configure Directory Partitions and then choose Containers:
Figure 4: Properties of the SourceAD Management Agent
You’ll then be prompted for valid Active Directory credentials. By default you’ll be asked for the credentials for the MSOL_AD_Sync account. As DirSync generates this during setup, you won’t know the account password but its fine to use another AD account here instead – it’s only used for selecting the Organizational Unit within the GUI.
When the Select Containers window opens, we’ll choose the Office365 Organizational Unit we created our matching accounts within in the previous part of this series:
Figure 5: Configuring the DirSync scope to filter against Organization Units
After making our selection, choose OK to confirm changes within the Select Containers window, then choose OK within the Management Agent Properties window to save changes.
You can read more about the supported scenarios changing DirSync’s scope in the TechNet article Configuring filtering for directory synchronization.
Verifying the accounts DirSync will attempt to synchronize
This is another optional step, but it’s a step that will help you ensure that after reconfiguring the scope for DirSync we have a chance to double check what we’ll be synchronizing to Office 365 is correct.
To accomplish this, we’ll perform a staged import from Active Directory into the local DirSync server. This won’t make any changes to Office 365 yet as we’ve stopped the Microsoft Online Services Directory Sync Service in the previous part of this series.
First, select the SourceAD management agent, and then choose Run from the Actions panel:
Figure 6: Selecting the Run action to initiate a synchronization
The Run Management Agent window should open. Select Full Import Stage Only, then choose OK:
Figure 7: Executing a Full Import, Stage Only against the SourceAD Management Agent
After pressing OK, the management agent’s state should change to Running. Depending upon the size of the organization you’re importing, this could take few minutes to complete; this is because it must download data from Active Directory and insert it into the local SQL Server database that underpins FIM and DirSync.
Upon completion, the state of the management agent should return to Idle indicating it has finished its staged import.
Figure 8: Monitoring the status of the SourceAD Management Agent
You’ll see below that we now have some interesting data within the Synchronization Statistics – 59 new additions from Active Directory. If you’re wondering why it’s not Updates or Unchanged, this is firstly because these are additions to the local FIM instance, not Office 365. Second, our first run against Office 365 won’t result in immediate matches as we’ll be performing soft matches based on the PrimarySMTPAddress.
If the number of additions looks round about right, we can go a little further and validate these by choosing Search Connector Space within the Actions panel shown above.
After the Search Connector Space window opens, we can view details about objects that have been imported from Active Directory so far by choosing Sub-Tree under the Scope heading and then selecting Search:
Figure 9: Viewing the Active Directory accounts imported into DirSync
Examine the results here and ensure they match up with what you are expecting to be synchronized – if not double check the scope you’ve set when configuring DirSync filtering and re-attempt the staged import. If all looks good, it’s time to begin synchronizing Active Directory accounts with Office 365.
Performing the initial synchronization with Office 365
We can initiate DirSync synchronization on demand by using the DirSync Configuration Shell, a PowerShell snap-in that allows us to control the DirSync scheduler.
To launch the DirSync Configuration Shell, navigate to the following path:
C:\Program Files\Microsoft Online Services Directory Sync
Figure 10: Opening the DirSync Configuration Shell
Within this folder, locate and launch DirSyncConfigShell.psc1. A PowerShell session should launch. To begin our initial synchronization, execute the following cmdlet:
Start-OnlineCoexistenceSync
Figure 11: Initiating the first full synchronization job
In the background, this will execute a number of run profiles, very similar to the Full Import Stage Only we performed in the previous section. Returning to the Synchronization Service Manager, select the Operations tab to verify the tasks have executed successfully:
Figure 12: Using the Operations tab to verify the first synchronization job has completed
After the first synchronization the local Active Directory account will not be joined to their Office 365 counterparts, so execute the Start-OnlineCoexistenceSync cmdlet a second time. This will use the soft matching technique mentioned earlier to link the accounts together.
If the operation is successful, we’ll expect the latest SourceAD management agent export to perform updates against our on-premises Active Directory objects, as highlighted below:
Figure 13: Using the Operations tab to verify the second delta synchronization job has completed
At this point we’ll expect that our on-premises Exchange 2010 organization’s Remote Mailboxes are synchronized with their Office 365 mailboxes, and we’re one step away from moving Mailboxes from Office 365 to our new Exchange 2010 servers.
Summary
In this part of this series we’ve successfully configured DirSync to synchronize our new matching Exchange 2010 remote mailboxes with the Office 365 tenant we’re intending to migrate mailboxes from. In the final two parts of this series we’ll run through updating AutoDiscover, execute the Hybrid Configuration Wizard, switch over mail routing and attempt to migrate mailboxes from our once-was standalone tenant before looking at how to decommission the Office 365 tenant.
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 4)
- 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)
