Multi-Forest Sync Without AD Connect: What Azure AD Cloud Sync Solves for MSPs

If you run SMB clients, most of your environments are hybrid. AD Connect (formerly DirSync) has synced local Active Directory into the cloud for years, and it shows up in nearly every email migration. The tool has improved a lot, but its supported topologies stayed limited. The one that hurt most: multiple forests into a single Azure AD tenant. Here is the standard AD Connect supported topology for reference:

Microsoft has now gone GA with Azure AD Connect Cloud Sync (opens in new tab), a lightweight agent installed from the Azure Active Directory admin center. It can replace AD Connect or run alongside it.

Where Cloud Sync wins for MSPs#

• Lightweight agent instead of a heavy application.
• Synchronizing to one Azure AD tenant from a multi-forest environment not on the same network.
• Coexistence of AD Connect and AD Cloud Sync.
• Configuration managed in Azure AD.
• No more 30-minute sync window.
• A new Hybrid Identity Admin role in Azure AD.

The agent installs easily and can run on multiple servers for high availability. The multi-forest support for environments not on the same network is the standout. With all the M&A activity in the SMB market, being able to sync separate environments into a single tenant, instead of planning a migration path, is a real win. You can run one forest on AD Connect and another on Cloud Sync, and you can move from AD Connect to Cloud Sync, though that process is more involved and is outlined by Microsoft here (opens in new tab).

Configuration like OU selection and attribute mapping is done in the Azure AD admin center, so you do not have to remote into the domain controller for every change. The new Hybrid Identity Admin role lets someone manage the connection without being a Global Admin. And the default 30-minute sync window is gone. In our testing, new users and changes replicated to the cloud in about 5 minutes.

Where it still falls short#

For all the upside, Cloud Sync carries some flaws as of February 2021. A full proof of concept surfaced these:

• No writeback capabilities.
• No advanced customization for attribute flows.
• No Azure AD Domain Services support.

Password hash synchronization is supported, but all writeback, including passwords and devices, is not, at least today. Microsoft may change this soon. Microsoft's full comparison of AD Connect to Cloud Sync (opens in new tab) is worth bookmarking.

The bigger detractor is the lack of attribute-flow customization and source anchor control. If you have ever set up AD Connect against a tenant with existing users, you know the pain of duplicate accounts when attributes are not configured correctly:

The usual fix is setting the mail attribute as the source anchor. In testing, there was no way to create that customization in Cloud Sync. To sync a tenant with existing users, you would have to run PowerShell to grab the ObjectGUIDs in AD and stamp them onto the existing Azure AD users first. That makes Cloud Sync unattractive for tenants that already have users.

Another common error worth testing for:

This one is the worst during a migration. You solve it by modifying the msExchMailboxGuid in the synchronization settings. You can still modify that attribute in Cloud Sync, so it is not actually a blocker. For more on this error and the duplicate-user problem, see our AD Connect best practices article.

Setting it up#

Microsoft's single-forest tutorial (opens in new tab) is easy to follow for setup. The full proof of concept is walked through in the video on the original post.

The verdict#

We like that Cloud Sync supports multi-forest configurations, which is the gap AD Connect never closed. But as of February 2021, the missing writeback, attribute-flow customization, and source anchor control mean it does not yet fit most customer environments. Worth piloting where multi-forest is the requirement; worth waiting on for tenants that already have users.