AAD Connect: Different write scopes etc. if system once had on-premises Exchange?


  • Both of these are running Azure AD Connect:

    System A is new and has never has on-premises Exchange. The associated Exchange Online has address book lists which sometimes need 'encouraging' to populate and I do that by writing some arbitrary text to mailbox customAttribute15 via remote PowerShell i.e. this modification appear to cause mailbox address list membership to be re-evaluated.

    System B is old and they once had on-premises Exchange (hasn't existed for over three years). Their Exchange Online also has address book lists, but I can't write to customAttribute15 via remote PowerShell because "the object is being synchronized from your on-premises organization".

    Is there anything I can do to make the cloud-side for System B behave the same way as for System A? Or is this an unchangeable consequence of System B having the Exchange schema extensions in their Active Directory?

    • Edited by Alan_CR Tuesday, April 4, 2017 11:47 AM
    Tuesday, April 4, 2017 11:44 AM

All replies

  • Hi,

    There are 2 ways to provision User objects in Azure AD.

    1. You can create them directly in Azure AD using O365 portals, Azure portals, AAD PowerShell, Graph API, etc. User objects created this way is referred to as "cloud-mastered" objects.

    2. You synchronize the existing user objects in your on-premises AD to Azure AD. User objects created this way is referred to as "on-premises mastered" or sync'd objects. In this case, many of the attributes cannot be set directly in cloud. They must be set on-premises and sync'd to Azure AD.

    The latter case is the reason why you are getting the error in PowerShell.

    For System B, are you still syncing identity data from on-premises AD to Azure AD? If not, you can consider disabling Directory Synchronization feature in Azure AD. By doing so, you are telling Azure AD that you no longer want to sync anything from on-prem AD to Azure AD. This will result in Azure AD doing a "source of authority" transfer from on-prem to cloud. Once this is done, all the sync'd user objects become cloud-mastered objects.

    To disable directory synchronization, please refer to this article.


    Chun Yong

    Wednesday, April 5, 2017 1:07 PM
  • Having different thoughts about this now. Today I can't do anything to System A's (synchronised AD user) customAttribute15 in EOL PowerShell.

    I'm certain I could do that and the only recent change I've made was yesterday with an in-place upgrade of the System A Azure AD Connect version from 1.1.380 to 1.1.443.0. Alternatively it could also be some independent change on the cloud-side.

    The way I think this worked before is that I could change any System A mailbox customAttributeN in the cloud, unless the corresponding extensionAttributeN was being set/configured on premises via transformations (which I did for a few because those attributes don't exist in the on-premises AD schema).

    Unselecting extensionAttribute15 as a synchronised atrribute in the Azure AD configuration wizard hasn't helped.

    I have a pile AzureADConnectSyncDocumenter stuff from a few weeks ago so perhaps getting that to compare the config with now will reveal something, but I'm not hopeful...

    Wednesday, April 5, 2017 1:38 PM
  • No joy. AzureADConnectSyncDocumenter reckons the precedence has changed on some of the default rules and the only other differences are customAttribute15 has been removed from relevant default Out to AAD rules which is obviously the consequence of me unselecting it for synchronisation with the wizard a little earlier.

    This is irksome because ignoring my AddressLists scenario, there are 1001 reasons why someone might want to independently pin some custom data/info to cloud mailboxes rather than have everything 'custom' sourced in AD.

    • Edited by Alan_CR Wednesday, April 5, 2017 2:04 PM
    Wednesday, April 5, 2017 2:04 PM
  • As far as Azure AD is concerned, for sync'd user objects, there is a fixed set of attributes (including extensionAttributeX) which Azure AD expects it to be mastered on-premises. This is independent of how you configure your sync client (Azure AD Connect). You can choose to drop the attribute from the list of sync'd and it would have no material impact on its authority (which remains on-prem).

    The only reason I can think of is that the user object has been a cloud user object, and was subsequently soft-matched to an on-premises AD object. As a result, the object was converted from a cloud-mastered object to an on-prem mastered object.

    Your hypothesis about Exchange Online allowing you to set the attribute if it is null may be correct, but it seems a little strange to me. This will require somebody from Exchange Online Team to confirm.

    Wednesday, April 5, 2017 2:09 PM