Azure AD Connect 184.108.40.206, released in late April, has several new features.
Azure AD Connect is often updated, but changes are usually small and incremental, such as update 220.127.116.11 in May 2019 which included only minor fixes.
The 18.104.22.168 upgrade is significant, with new features, improvements, capabilities and important fixes.
Anyone running this key piece of software really should have an understanding of its features and limitations.
These notes explain the new features in the recent release of Azure AD Connect. They are intended to assist students of our Azure AD Connect Masterclass (which naturally we have also updated with these changes), but will be useful to anyone who has deployed an earlier version. Enjoy!
Modified Default Sync Rule Handling
This is the feature change that has the greatest impact on our Masterclass – and potentially on existing implementations of Azure AD Connect. First, the simple stuff – UI changes. The rule editor now looks like this:
The new view button lets you simply view a rule (which is a common requirement). Previously, if you wanted to take a quick look at an existing sync rule, you would select the sync rule, click “Edit” and then click “No” on the warning dialog.
Previously, you could edit an out-of-the-box rule as above. Now, in Azure AD Connect 22.214.171.124, if you try to do this, you get a new dialog which gives equivalent choices of the ”No” and “Cancel” buttons on the old dialog. Your own rules can be edited without hindrance.
You CAN still edit an out-of-the-box rule using PowerShell. This is important, and we will come to it shortly.
Since you can’t edit an out-of-the-box rule, we now need a “Disable” button – which has been supplied. You can still disable/enable your own rules in the old way.
If you have changed an out-of-the-box rule in an earlier version of Azure AD Connect, a new out-of-the-box rule will be added, but disabled – while the modified one will be flagged (but still in use). If you modify out-of-the-box rule using PowerShell, then it is flagged:
In this way Microsoft do not break your existing configuration. Hooray!
If this flag is totally unexpected (for example, you don’t think you modified any out-of-the-box rules), you can export both rules (the flagged and the new, disabled, default rule), and compare them using windiff (or any other file comparison tool). Once you establish what is different you can decide whether to enable the new default rule and delete the old one, or something else (read on!)
As a general guideline you should not change the Microsoft rules in any way. So for example, if you want to replace a default transformation, you should create a new rule, with more powerful precedence, the same scope, and your new transformation.
So why would you disable a Microsoft rule, and edit a copy of it? An example would be where you need to change the Join Rule. Since all rules in scope share a common Join Rule, there can only be one such rule. So to change the Join Rule in a given situation, you will disable the old rule, and use a modified copy of it. Now you will have to take care that if the out-of-the-box rule is modified during a subsequent upgrade, you may need to edit your rule too!
Editing Microsoft Rules
This is the last resort, is not supported, and is to be avoided! However, an example where it is unavoidable is where you wish to change a transformation from an Update to a Merge (perhaps you wish to merge memberships of groups). The Sync Rule Processing Pipeline will not cope with two transformations to the same target attribute, that have different Merge Types, even if one of them is disabled. In this circumstance you have little option but to export the out-of-the-box rule concerned, edit the PowerShell thus created to specify one of the Merge options, then run the PowerShell to modify the out-of-the-box rule. The rule will be flagged, as described above.
Add support for Domain Refresh
As far as one can see, in the wizard, when you are adding domains, you used to have a button called “Refresh OU/Domain” (which didn’t really work). Now it says “Refresh Domains”. This at least makes it explicit that you can’t refresh the OU list. Presumably it does search for domains!
Exchange Mail Public Folders and Unified Groups Writeback features go GA
This is simple enough, they were in preview – in Azure AD Connect 126.96.36.199 they are generally available (unified groups are Office 365 groups).
Added warning link for old UI on connector properties page
This is just to emphasize that you should use the wizard when you can, and know what you are doing if you use the UI!
Allow EA creds from a child domain
For example, if you have a single forest with a parent and a child domain, you can use the EA credentials when adding and configuring the child domain (apparently there was a problem with this before).
Allow database name to be entered during install (default name ADSync)
On the “Required Components” page of the installation wizard, if you select “Use an existing SQL Server”, as well as specifying the server and instance, you can now also specify a different database name.
Added a new agent running as a windows service
If you need support from Microsoft ask you to install a special “Admin Agent” (which is not installed by default). This enables deeper remote diagnostics of the Azure AD Connect server to help Microsoft Engineers troubleshoot when you open a support case.
When installed, the Azure AD Connect Administration Agent waits for specific requests for data from Azure Active Directory. It gets the requested data from the sync environment and sends it to Azure Active Directory, where it is presented to the Microsoft support engineer.
The information that the Azure AD Connect Administration Agent retrieves from your environment is not stored in any way. It is only displayed to the Microsoft support engineer to assist them in investigating and troubleshooting the Azure AD Connect related support case that you opened.
Updated the End User License Agreement (EULA)
This is the thing we all don’t read before pressing “Agree”. You should carefully ignore the updated one too!
Several features that relate to AD FS
Now that we have Pass-through Authentication (PTA), few organizations will install AD FS just to support Azure AD Connect SSO. So generally, if AD FS is present, it will be performing a wider federation role. It is a large subject, and so in our Masterclass we don’t say a great deal about AD FS, and we certainly don’t have any AD FS labs.
Azure AD Connect 188.8.131.52 introduces a number of features which improve support for AD FS – most do not impact the course at all.:
- Modify Group Sync Rules to flow samAccountName, DomainNetbios and DomainFQDN to cloud – so that they can be used in claims (for example, some applications are configured to use group membership when authenticating with ADFS).
- Added auto upgrade support for deployments that use AD FS as their login type. This also removed the requirement of updating the AD FS Azure AD Relying Party Trust as part of the upgrade process.
- Added an Azure AD trust management task that provides two options – analyse/update trust and reset trust – so that it always uses the -SupportMultipleDomain switch (includes trust and Azure AD domain updates).
- Changed the install new AD FS farm behavior so that it requires a .pfx certificate by removing the option of using a pre-installed certificate.
- Updated the install new AD FS farm workflow so that it only allows deploying 1 AD FS and 1 WAP server. All additional servers will be done after initial installation.
Several features of Azure AD Connect 184.108.40.206 are “under the covers”
These are not obvious, or easy to demonstrate – and they do not affect our Azure AD Connect Masterclass, but are called out here for general interest.
- Improved wizard error handling for service failures
- Improved SSPR error messages
- Added diagnostics for DCOM registry errors during install
- Improved tracing of PHS RPC errors
- Upgrade to ADAL 3.19.8 to pick up a WS-Trust fix for Ping and add support for new Azure instances
A number of fixes
Azure AD Connect 220.127.116.11 includes a number of fixes which do not affect our Masterclass, but will hopefully improve your experience!
- Fix the SQL reconnect logic for ADSync service
- Corrected an issue where installation of Azure AD PowerShell on a server could potentially cause an assembly conflict with Azure AD Connect
- Now allowed: clean Install using an empty SQL Always On Availability DB
- Miscellaneous Autoupgrade fixes
- Fix PS Permissions script to refine group write-back permissions (AADConnectPermission.ps1 can be used to configure permissions for a number of AAD Connect scenarios)
- Volume Snapshot Service (shadow copy) errors with LocalDB fixed
- Misleading error message when object type is not in scope now fixed
- Fixed PHS bug on Staging Server when Connector Credentials are updated in the old UI
- Fixed some memory leaks
- Miscellaneous fixes to Export and Unconfirmed Import Processing
- Fixed a bug with handling a backslash in Domain and OU filtering
- Fixed an issue where ADSync service takes more than 2 minutes to stop and causes a problem at upgrade time
See Azure AD Connect version release history.
Learn! If you haven’t already taken our Azure AD Connect Masterclass, I strongly recommend it. You can take it instructor-led in the classroom or via Skype in 3 days, or online, self-paced. Either way, its the only comprehensive, structured training course for this complex and powerful technology. Discover what you’ll learn.
Download our free Azure AD Connect Rule Tool. It makes editing rules so much simpler and easier! You’ll be able to see what you’re doing and get syntax checking for sync rule expressions!