Configuring an Exchange 2013 Hybrid Deployment and Migrating to Office 365 (Exchange Online) (Part 9)

By /

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

Introduction

In part 8 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we installed and configured the Windows Azure Active Directory (WAAD) Sync tool on our Windows Server 2012 domain-member server and started object synchronization from the on-premises Active Directory to the Office 365 tenant.

In this part 9, we will continue where we left off in part 8. We will take a look at the WAAD Sync tool engine and verify that objects synchronize as expected from our on-premises Active Directory to the Office 365 tenant. In addition, I will talk a bit about what objects and attributes are synchronized to the Office 365 tenants as well as directory synchronization filtering.

Note:
The WAAD Sync tool was formerly known as the Directory Synchronization tool (DirSync tool).

Let’s get going…

Verifying Active Directory Object Synchronization

When it comes to verifying directory synchronization, what I usually do first is to launch the WAAD Sync tool UI shell by navigating to “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell” and double-click on “miisclient” as shown in Figure 1.

Image
Figure 1: Launching the MIIS client

In the “Synchronization Service Manager on DIRSYNC” console, you can see the status for the last run of each management agent. You can also see the number of added, updated and deleted objects etc.

If you have MIIS/ILM/FIM experience this is probably the best place to look in order to verify synchronization is running as expected.

Image
Figure 2: Synchronization Service Manager on directory synchronization server

Besides the Synchronization Service Manager console, you can also look in the Application log. Here you can see event IDs that can give you a quick indication of the health state for the directory synchronization.

Image
Figure 3: Directory Synchronization related event IDs in the Application log

Finally, we can check the Office 365 portal for when the last directory synchronization occurred (Figure 4).

Image
Figure 4: Checking the time for the last synchronization in the Office 365 portal

You can also try to update a few attributes for a couple of users or create new users to see if the changes are reflected on the Office 365 user. To force a synchronization, see the next section.

Forcing a Directory Synchronization

Since delta synchronizations from your on-premises Active Directory forest to Office 365 are scheduled to run every 3 hours, there may be situations where you want to force a synchronization. This can be done using the “Start-OnlineCoexistenceSync” cmdlet. But in order to run this cmdlet, you must first launch a Windows Powershell console on the server and then navigate to “C:\Program Files\Windows Azure Active Directory Sync” folder and from here run the “DirSyncConfigshell.psc1” script.

Image
Figure 5: Windows PowerShell console

This will open another Windows PowerShell console where you can enter the “Start-OnlineCoexistenceSync” cmdlet. Doing so will immediately force a synchronization.

Image
Figure 6: Running the Start-OnlineCoexistenceSync cmdlet

Switching back to the synchronization Service Manager, we can see that a delta import is in progress.

Image
Figure 7: Delta Import in progress

List of Attributes Synchronized to Office 365 Tenant

So when it comes to object attributes that can be synchronized from the on-premises Active Directory to the Office 365 tenant, the WAAD Sync tool can sync approximately 140 different object attributes (for a complete list, see this KB article). In order for an object to be valid for sync, the following attributes need to contain values:

  • cn
  • member (applies only to groups)
  • samAccountName (applies only to users)
  • alias (applies only to groups and contacts)
  • displayName (for groups with a mail or proxyAddresses attribute populated)

Object-wise, the following five objects types are synchronized:

  • User accounts
  • Contact objects
  • Service accounts
  • Distribution groups
  • Security groups

By default the following objects are filtered based on name and value:

Any object is filtered if:

  • Object is a conflict object (DN contains \0ACNF:

Contact objects are filtered if:

  • DisplayName contains “MSOL” AND msExchHideFromAddressLists = TRUE
  • mailNickName starts with “CAS_” AND mailNickName contains “{“

SecurityEnabledGroup objects are filtered if:

  • isCriticalSystemObject = TRUE
  • mail is present AND DisplayName isn’t present
  • Group has more than 15,000 immediate members

MailEnabledGroup objects are filtered if:

  • DisplayName is empty
  • (ProxyAddress doesn’t have a primary SMTP address) AND (mail attribute isn’t present/invalid – i.e. indexof (‘@’) <= 0)
  • Group has more than 15,000 immediate members

User objects are filtered if:

  • mailNickName starts with “SystemMailbox{“
  • mailNickName starts with “CAS_” AND mailNickName contains “{“
  • sAMAccountName starts with “CAS_” AND sAMAccountName has “}”
  • sAMAccountName equals “SUPPORT_388945a0”
  • sAMAccountName equals “MSOL_AD_Sync”
  • sAMAccountName isn’t present
  • isCriticalSystemObject is present
  • msExchRecipientTypeDetails == (0x1000 OR 0x2000 OR 0x4000 OR 0x400000 OR 0x800000 OR 0x1000000 OR 0x20000000)

Directory Synchronization Filtering

Some (mostly large enterprise organizations) often wish to configure filtering, so that the WAAD Sync tool doesn’t synchronize each and every valid object in the on-premises Active Directory to Office 365. Fortunately, directory synchronization filtering is supported as long as one or a combination of the following methods are used:

  • Organizational-unit (OU)–based: You can use this filtering type to manage the properties of the SourceAD Management Agent in the Directory Synchronization tool. This filtering type enables you to select which OUs are allowed to synchronize to the cloud.
  • Domain-based: You can use this filtering type to manage the properties of the SourceAD Management Agent in the directory synchronization tool. This type enables you to select which domains are allowed to synchronize to the cloud.
  • User-attribute–based: You can use this filtering method to specify attribute-based filters for user objects. This enables you to control which objects should not be synchronized to the cloud.

For information about how you comfigure the above three directory synchronization methods, see this piece of TechNet documentation.

Directory Synchronization Limitations

There is a default limitation to how many objects that can be synchronized to an Office 365 tenant. The limitation is 50.000 by default. If you have a need to synchronize more than 50.000 objects into the tenant, then you need to open a service ticket with Office 365 support through the Office 365 portal or via phone.

When you do a default installation of the WAAD Sync tool, it will be configured to use a SQL Express 2012 instance locally on the directory synchronization server which has a database size limit of 10 GB.

If you have more than 50.000 objects that need to be synchronized to the Office 365 tenant, it’s recommended to configure the WAAD Sync tool to use a dedicated SQL instance on a SQL server. If this is relevant for your specific scenario, you need to install the WAAD Sync tool using the command prompt. See instructions on how this is accomplished here.

This concludes part 9 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

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

About The Author

Read Next

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