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

Earlier this week, Microsoft released version 1.1.281.0 of the Azure AD Connect Provisioning Agent. Azure AD Connect provides provisioning from Active Directory to Azure AD. The Azure AD Connect Provisioning agent can be used alongside Azure AD Connect to:

  • Synchronize disconnected Active Directory forests in a multi-forest environment
  • Simplify the deployment with light-weight provisioning agents, because Azure AD Connect Provisioning Agent pick up their configuration from Azure AD
  • Provide a high available deployment for Password Hash Synchronization (PHS)

 

What’s New in version 1.1.281.0

The following features and improvements are reported for version 1.1.281.0 of the Azure AD Connect Provisioning Agent, released on November 23rd, 2020:

Support for gMSA

The Azure AD Connect Provisioning Agent now supports the use of group Managed Service Accounts (gMSAs) for running the agent.

Version 1.1.281.0 of the Azure AD Connect Provisioning Agent now prompts by default to create a group Managed Service Account, when upgrading from previous versions of the Azure AD Connect Provisioning Agent.

Support for groups up to size less than 1500 members

The Azure AD Connect Provisioning Agent now supports groups up to size less than 1500 members during incremental or delta sync cycle. This is applicable when using the group scoping filter.

Support for large groups with member size up to 15K

The Azure AD Connect Provisioning Agent now supports groups with over 15,000 members.

Initial sync improvements

The initial synchronization for Azure AD Connect Provisioning Agent has been improved.

Advanced verbose logging

The Azure AD Connect Provisioning Agent now offers advanced verbose logging to assist in troubleshooting and diagnosing performance and connection problems.

After enabling verbose logging through PowerShell or in the AADConnectProvisioningAgent.exe.config file, you can find the logs in the following folder:

C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace

Introduction of AADCloudSyncTools PowerShell module

Version 1.1.281.0 of the Azure AD Connect Provisioning Agent introduced the AADCloudSyncTools PowerShell module. This Windows PowerShell module offers the following eighteen cmdlets:

  • Connect-AADCloudSyncTools
  • Export-AADCloudSyncToolsLogs
  • Get-AADCloudSyncToolsInfo
  • Get-AADCloudSyncToolsJob
  • Get-AADCloudSyncToolsJobSchedule
  • Get-AADCloudSyncToolsJobSchema
  • Get-AADCloudSyncToolsJobScope
  • Get-AADCloudSyncToolsJobSettings
  • Get-AADCloudSyncToolsJobStatus
  • Get-AADCloudSyncToolsServicePrincipal
  • Install-AADCloudSyncToolsPrerequisites
  • Invoke-AADCloudSyncToolsGraphQuery
  • Repair-AADCloudSyncToolsAccount
  • Restart-AADCloudSyncToolsJob
  • Resume-AADCloudSyncToolsJob
  • Start-AADCloudSyncToolsVerboseLogs
  • Stop-AADCloudSyncToolsVerboseLogs
  • Suspend-AADCloudSyncToolsJob

You can use Install-AADCloudSyncToolsPrerequisites to install the latest version of MSAL.PS, which is a required Windows PowerShell module.

Fixed limitations to allow agent to be installed in non-English server

Previous versions of the Azure AD Connect Provisioning Agent could not be installed on Windows Server installations with other locales set then United States-English (en-us). Now, the Azure AD Connect Provisioning Agent can be installed on these Windows Server installations, too.

Support for PHS filtering

Version 1.1.281.0 of the Azure AD Connect Provisioning Agent introduces Password Hash Synchronization (PHS) filtering, so PHS is only enabled for objects in scope of provisioning. Previously, the agent synchronized password hashes for all objects.

Improved provisioning logs

Version 1.1.281.0 of the Azure AD Connect Provisioning Agent provides improved provisioning logs.

Support for configuring LDAP connection timeout

When performing LDAP operations on configured Active Directory domain controllers, by default, the Azure AD Connect Provisioning Agent uses the default connection timeout value of 30 seconds. If your domain controller takes more time to respond, then you may want to reconfigure the connection time-out.

Version 1.1.281.0 of the Azure AD Connect Provisioning Agent now offers the ability to configure this time-out (in milliseconds) through the LdapConnectionTimeoutInMilliseconds string registry value in the following registry location:

HKLM\Microsoft\Azure AD Connect Agents\Azure AD Connect Provisioning Agent\

Support for configuring referral chasing

By default, the Azure AD Connect provisioning agent does not chase referrals. Version 1.1.281.0 of the Azure AD Connect Provisioning Agent now offers the ability to enable chasing referrals through the ReferralChasingOptions string registry value in the following registry location:

HKLM\Microsoft\Azure AD Connect Agents\Azure AD Connect Provisioning Agent\

To do so, specify 96 as the value data.

 

Concluding

While still not offering all the functionality that are needed to run the Azure AD Connect Provisioning Agent without Azure AD Connect, version 1.1.281.0 does provide a significantly better experience for its current scenarios.

Further reading

What is Azure AD Connect cloud provisioning?
Azure AD Connect Provisioning Agent: Version release history
Download Microsoft Azure Active Directory Connect Provisioning Agent (Preview)

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.

    • 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.

       
  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?

    • 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.

       
  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?

    • 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.

       

leave your comment

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