What is Azure AD Connect Cloud Provisioning and should you plan to use it? Part Two

In part one, we examined why Azure AD Connect Cloud Provisioning has a clear use-case for organizations dealing with mergers and acquisitions – and how it helps move organizations to a cloud-based provisioning model rather than running more services on-premises to simply duplicate their directories in the cloud. In particular, Cloud Provisioning makes it possible to sync multiple Active Directory environments that aren’t connected over the network.

Azure AD Connect doesn’t allow this because only one instance can be installed per Azure AD/Office 365 tenant and the Azure AD Connect server needs to be able to access every AD forest.

To round up part one we set up three Active Directory environments, all running Exchange Server and synchronized them to Azure AD.

In part two we’ll explore the configuration that gets applied when you use Azure AD Connect Cloud Provisioning and explore some of it’s current limitations. As mentioned in part one – this technology is in preview so don’t go and try this out in your environment until it’s GA.

Exploring Azure AD Connect Cloud Provisioning’s configuration and limitations

However limitations with using Exchange Hybrid – or device sync (necessary for Hybrid Azure AD Join of Windows 10 devices) may mean that this is really a stop-gap solution rather, if these limitations persist when Azure AD Connect Cloud provisioning goes into General Availability.

This may be a big limitation for some uses because the attributes synced include the common set of Exchange Hybrid attributes, such as ExchangeGUID (and more) that correctly identify that a mailbox exists on premises and block creation of a user mailbox in the cloud. Third-party migration tools usually expect a target mailbox to be created in Office 365.

If you want to examine the schema and understand what is synced (and what isn’t) then instructions to access this in JSON format are available on Microsoft Docs. To follow the procedure, you’ll need to setup a sync configuration first – so to give you an example schema to examine I’ve uploaded one from the lab here. You can use a JSON tree viewer (as shown below) to make navigating the structure easier:

Dealing with duplicate objects

Naturally if you have multiple Active Directory forests, there’s a reasonable change that you will have objects relating to the same user across each forest. A common example might be contact objects or user accounts created to allow access to applications.

Azure AD Connect Cloud Provisioning doesn’t currently match objects across different source environments, which means if there are multiple objects relating to one user, then you need to either de-scope these users from the sync – or use Azure AD Connect.

But what happens if you do synchronize multiple objects? To test this out, we’ve created an object in Lab 01 that matches a user in Lab 02. This is a Mail User – a normal user account, with an External Email Address of the user in Lab 02:

You would expect that this would fail to synchronize because the Primary SMTP address already exists due to the sync relationship with Lab 02. However – it does successfully sync and results in a duplicate Mail User in Exchange Online – as shown below:

However – in the Office 365 Admin portal, this is recognised as an error when we attempt to licence the user. Although both have a different UPN value, attempting to licence the user results in an error message due to the duplicate SMTP address:

Therefore, the best advice if you are testing this today is to ensure that you validate uniqueness across directories before attempting to sync. The staging mode or error logs won’t highlight errors like this for you, nor prevent this from occurring.

What happens if you attempt an Exchange Hybrid configuration?

We can see one key reason by viewing the synchronization job schema (above) or reading the limitations around write-back to understand why Exchange Hybrid isn’t supported. The Hybrid attributes normally expected aren’t written back to the local Active Directory.

You can verify this after a successful sync by examining a mailbox. We would normally expect to see the LegacyExchangeDN created in Exchange Online written back as an X500 address to the local AD and Exchange environment. As you’ll see below, it’s not written back:

Additionally, upon attempting to perform an Exchange Hybrid configuration, we’re informed that Azure AD Connect isn’t in place – which should (hopefully) be a red flag.

To see what happens in the lab (and really, don’t try this in production – not only is Azure AD Connect Cloud Provisioning in preview but Exchange Hybrid is explicitly NOT supported) we choose I will install Azure AD Connect later on my own to allow the Exchange HCW to continue as normal.

For the purposes of testing we then Hybridized all three Exchange Server environments, and created Migration Endpoints for each.

After performing synchronization jobs to ensure that the additional mail.onmicrosoft.com email aliases were correctly synchronized to Azure AD, we successfully migrated mailboxes from each environment – however as the core Exchange attributes are being synchronized, and a mailbox migration isn’t reliant on Azure AD Connect itself, this was generally expected:

As a side note, it’s worth mentioning that although Azure AD Connect write-back wasn’t available, the attribute stamping process as part of a mailbox migration added the missing Legacy Exchange DN value:

Potentially more useful was testing the ability to use an Exchange Server to create an Office 365 mailbox. At present, if you have a Hybrid AD – then you’ll need to use an Exchange Hybrid server to create and manage mailboxes. That’s certainly a tricky support situation to be in with Azure AD Connect Cloud Provisioning.

As expected, after performing Hybrid Configurations in each environment the New Office 365 Mailbox option becomes available (or in Exchange 2010, New Remote Mailbox):

To test this worked correctly, we created a new mailbox in Office 365 using the Exchange Admin Center and archive-enabled it on-premises to ensure that relevant attributes were correctly synced. As shown below – once licenced the mailbox was created as normal in Office 365, including the archive:

Summary

The Azure AD Connect Cloud Provisioning preview is a good insight into what Microsoft are making available for helping organizations deal with disconnected multi-forest environments who are consolidating in Office 365, or using Azure AD as a central SSO platform. Right now the preview is very much a preview and if you need premium features like write-back – or common functionality like Exchange Hybrid, you’ll need to wait a little while yet.