AADConnect and extending the on-prem AD schema

As I run into this question frequently on the different Office 365 forums, I though I’d make a more detailed post about it. Here’s the TL;DR version: if you have extended the schema, rerun the AADConnect setup (AzureADConnect.exe tool)!

If you need more detailed explanation, lets examine the most common example of extending the on-prem AD schema with the Exchange attributes. The first step is to download the Exchange binaries and extract them to a local folder. Then, open an elevated PowerShell (or cmd for the die-hard fans) and run setup.exe with the /prepareschema switch:

AADConnectschema1 e1482655191450

Once this is done, you will be able to use the newly introduced attributes. AADConnect however will not recognize them just yet, and any changes you make to said attributes will not be synced to O365. Why is that you might ask? Well, AADConnect uses connectors to represent the schema for each source directory it connects to, be it on-prem AD or Azure AD, and stores that representation in the Metaverse. Changes that are made to the source directory schema after the Connector has been created are not automatically reflected. We do have a manual way to force refresh of the schema from within the MIISClient tool, but I would advise against that.

Instead, one should simply rerun the AADConnect setup tool, located at “C:\Program Files\Microsoft Azure Active Directory Connect” (you should also have a shortcut on the desktop):


As shown on the screenshot above, you simply need to select the “Refresh connector schema” option, then press the Next button. You will be prompted to enter credentials for the Azure AD connector, and to select the directories for which connectors you would like to perform the schema refresh. As part of the process, sync will be disabled (the scheduled task as well), synchronization rules will be updated, and the overall state ‘defaulted’.


Once the process is completed, you should go over any custom rules you might have created (or similarly, over any of the default rules you have made changes to). You will notice that some of the default rules have been changed, as well as few new sync rules:

In from AD – User Common from Exchange                      8c5a1599-08a1-4240-8032-6c6e5e16fb75
In from AD – InetOrgPerson Common from Exchange             3cc8676b-c896-49bb-9753-c2b77c772fa5
In from AD – User Exchange                                  b0c347e6-9006-4a59-98a2-a4e8b28e2844
In from AD – InetOrgPerson Exchange                         fdbdfce8-aad3-43e8-9212-0796f3b33a47
In from AD – Group Exchange                                 f0f884f4-52d1-4237-9fe7-5417fa62de33

This is one of the reasons you should not to the refresh manually. All those newly introduced attributes must be correctly mapped to the relevant attributes in the metaverse, and subsequently in Azure AD. Without the sync rules, this will never happen (well you can create your own rules to include the attributes, but that will take some time). Once you have gone over the rules, you can also go to the MIISClient tool and verity that the Connector schema now includes the new attributes. If you want to be really cautious, you can also run a Preview sync for few objects or even switch AADConnect to staging mode. Once you are satisfied with the checks, don’t forget to re-enable the scheduled task for the sync process, and force a Full sync (should be forced automatically due to the ‘defaulted’ state.

That’s pretty much it – you will now be able to manage any of the Exchange related attributes and the changes you made will be reflected in Exchange Online.

5 thoughts on “AADConnect and extending the on-prem AD schema

  1. Thomas says:

    But this scenario is supported by Microsoft?

    Extend the schema and manage the objects through AD (ADSIEdit) and not by Exchange Server?


    1. Vasil Michev says:

      Nope, the only supported tools to manage Exchange related objects and attributes are the Exchange Management tools 🙂

  2. Ytsejamer1 says:

    Where do you view the rules or edit them?

    I”ve extended my schema to install a later CU for Exchange 2016 which we’re running in hybrid mode. Now i’m getting errors with the DirSync for SystemMailbox – which really should have been blocked by default.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.