• The things that are better left unspoken

6 Responses to Azure AD Connect Provisioning Agent v1.1.281.0 now supports gMSA, PHS Filtering and many other improvements

1. 
   

   Thanks for write-up!

   Looking at using Azure AD Connect Cloud Provisioning agent on a project 3 disconnected forests.

   The MS FAQ doc states:

   • By default, cloud sync uses ms-ds-consistency-GUID with a fallback to ObjectGUID as source anchor. There is no supported way to change the source anchor.
     – and –
   • Cloud sync does not support writeback of ms-ds-consistencyGUID for any object (including user objects).

   How can I ensure “ms-ds-consistencyGUID” would be used and not the “fallback” ObjectGUID?

   Do I need to use PowerShell to manually populate the on-prem ms-ds-consistencyGUID with a ToBase64String conversion of the ObjectGUID –before the initial sync- as the Cloud Sync Provisioning agent can't writeback?

   Expecting it would be likely that we would need move a user from one ad forest to another in the future (aaauser1 moves to bbbuser1) – so expecting we would need to be able to create on-prem bbbuser1 and copy over the “ms-dir-consistencyGUID” from aaauser.

   from Kirsten Wahlstrom February 4, 2021 at 8:22 PM
   • 

     Hi Kirsten,

     To ensure mS-DS-ConsistencyGUID is used as the source anchor attribute, specify the attribute in Azure AD Connect as the source anchor attribute.

     • If Azure AD Connect has been configured with objectGUID as source anchor attribute, you can use the task to convert to mS-DS-ConsistencyGUID.
     • If Azure AD Connect has been configured with any other attribute than objectGUID or mS-DS-ConsistencyGUID, re-implement Azure AD Connect.

     Azure AD Connect writes its source anchor attribute configuration to Azure AD, where it is picked up by the Azure AD Connect Cloud Sync agent and the Azure AD Connect Provisioning agent.

     from Sander Berkouwer February 4, 2021 at 9:57 PM
     
2. 
   

   Thanks for the reply Sander!

   In our case none of the 3 disconnected forests were previously using Microsoft 365 or synced with "Azure AD Connect" (full sync soln) – We were considering just Using the Azure AD Connect Cloud Sync Provisioning agent- to initially get everyone on 1 365 tenant and start using 365.

   From your reply I get the impression I would need to install and sync with "Azure AD Connect" (full sync soln) on each forest before I would be able to ensure that Azure AD Connect Provisioning agent would use ms-DS-ConsistencyGUID. Then I could connect to Azure AD with powershell to disable directory synchronization (users would move back to cloud only) and then I could uninstall "Azure AD Connect" (full sync soln) and then re-setup the sync from using the Azure AD Connect Provisioning agent to "re-sync" everyone.
   Either I would have to setup the vpns line-of-site anyway, or go through that process 3 times??

   Since one of the benefits of Azure AD Connect Provisioning agent is supposed to be its ability to handle disconnected forest that seems like a lot to go through. I’m I misunderstanding?

   from Kirsten Wahlstrom February 5, 2021 at 8:35 PM
   • 

     Hi Kirsten,

     It sounds like you're already using Azure AD Connect for one of your Active Directory domains.
     Your options are to:

     • Deploy VPN connections to the other forests, create service accounts in these forests and bring these forests into scope of the one single Azure AD Connect installation you already have, or;
     • Deploy the Azure AD Connect Provisioning Agent on/near Domain Controllers in the remote forests and have them synchronize, based on the Azure AD-based logic that your Azure AD Connect installation has already configured there, or;
     • Deploy Azure AD Connect three times in the other three forests and synchronize to the same Azure AD tenant you're already synchronizing your first forest to.

     In the second scenario, there are a couple of caveats that you need to be aware of, including the WriteBack and Hybrid Exchange omissions in the Provisioning agent.
     The third scenario is an unsupported scenario, but works when users have been configured with different userPrincipalName suffixes per forest, there is no Hybrid Exchange, there is no cross-forest functionality and you don't need Group WriteBack functionality.

     from Sander Berkouwer February 6, 2021 at 10:35 AM
     
3. 
   

   Thank you so much for your feedback on our options!

   There is NO sync up to now none of the forests had been using Microsoft 365.
   No on prem-exchange.
   3 smaller affiliates that were previously using a non-Microsoft e-mail. E-mail address for users from all affiliates at a @affiliategroup.org
   (They have never had, nor do they want @affiliateA.com, @affiliateB.com e-mails)

   But the use of ms-ds-consistencyGUID on the remote forests in your second scenario is the base of initial question.

   We install AD Connect in one forest and have it synchronize. Azure AD Connect ms-ds-consistencyGUID used for source anchor as it is previously un-used, ms-ds-consistencyGUID is written back to on-prem AD and Azure AD Connect (from 1.1.524.0 and after) store information in your Azure AD tenant about the sourceAnchor attribute used during installation.

   If then install Azure AD Connect Provisioning Agent the other 2 remote forests and if ms-ds-consistencyGUID for these 2 remote forests is blank before the sync what will happen for creation of Azure AD properties for “ImmutableID” and “sourceAnchor attribute used during installation” for the users from the remote forests?

   from Kirsten Wahlstrom February 6, 2021 at 1:45 PM
   • 

     Hi Kirsten,

     I'm guessing you want to use the mS-DS-ConsistencyGUID, because you want to cross-forest migrate people at a certain stage and possibly collapse some forests to reduce complexity.
     If this is what you're aiming for, then only scenario 1 is applicable to your situation. It's the only way to perform cross-forest object migrations without significant downtime (there will be some).
     For all other scenarios, we don't need to be as focused on the source anchor attribute. We can sit back, relax and rely on the AD Recycle Bin to save our behinds in most cases.

     Note that mS-DS-ConsistencyGUID for users was new in Azure AD Connect version 1.0.524.0. Groups use it too, since version 1.5.18.0.

     from Sander Berkouwer February 7, 2021 at 12:03 AM