Showing posts with label AADConnect. Show all posts
Showing posts with label AADConnect. Show all posts

Azure AD Connect version 2.1.20.0 released with a new ability you probably can't use yet

Friday, November 4, 2022

UPDATE: Hot on the heels of the last update, Microsoft released Azure AD Connect version 2.1.20 (6 days later) which apparently fixes a bug in the new sync feature described below. If you implemented the custom sync rule described earlier, you'll need to undo it and do it again. <facepalm>

Microsoft updated Azure AD Connect to version 2.1.19.0 today. 

According to the release notes, "We added a new attribute 'employeeLeaveDateTime' for syncing to Azure AD. To learn more about how to use this attribute to manage your users' life cycles, please refer to this article".

Let's break this down.

First, the support article the release notes refer to is for Azure AD Connect cloud sync, not Azure AD Connect. At this time, syncing the employeeLeaveDateTime is still not supported in Azure AD Connect.


Since AAD cloud sync doesn't support Exchange hybrid at this time, AAD cloud sync is of no value for hybrid customers. However, the AD Connect team is working on adding Exchange hybrid support in the future. 

The support table shows that syncing the employeeHireDate attribute is already supported in Azure AD Connect, so I expect that suspect the configuration is the same. I could not find a similar support article for Azure AD Connect.

Second, the employeeHireDate and EmployeeLeaveDateTime attributes only exist in Azure AD. The on-premises Active Directory schema is not extended to add these two attributes, so the recommendation is to use one of the existing extensionAttribute* attributes an AD to hold these values.

At this time, Microsoft recommends using the extensionAttribute1 attribute for employeeHireDate, but the documentation makes no mention of how to handle the EmployeeLeaveDateTime attribute. See How to synchronize attributes for Lifecycle workflows - Microsoft Entra | Microsoft Learn. I hope this documentation will be updated soon with the missing info and how to handle it if this attribute is already in use in your organization.

Last, if you want to update the employeeLeaveDateTime attribute directly in Azure AD using the Graph API, please see Set employeeLeaveDateTime - Microsoft Graph | Microsoft Learn.


Read more ...

How to Setup Exchange Management Tools in Environments without Exchange Server

Friday, October 14, 2022

Some Exchange Online customers have an Active Directory on-premises, but never had Exchange Server on-prem. For example, customers who migrated their email from an Exchange hosted environment or from a different email system, such as Notes.

In some environments, these customers are having to manage user accounts and groups in both AD and Azure AD. This leads to confusion since accounts and passwords are not synced, so usernames and passwords can be different. Those customers may be looking for a way to master accounts, groups, and mailboxes from AD on-prem so they have a single source of authority, similar to the way that hybrid customers do.

In other environments, customers are using Azure AD Connect to sync users from AD on-premises to the cloud. Here, user accounts and groups are managed on-premises, but mailboxes are managed in Exchange Online. These customers may be looking for a way to manage mailboxes and groups from AD, so they also have a single source of authority.

The following steps will let you install the Exchange 2019 Exchange Management Tools (EMT) in an AD environment without having to install Exchange Server. 

Keep in mind that this solution is not supported by Microsoft, since manual configurations must be made in AD using ADSI Edit. The Microsoft supported way to do this is to install an Exchange Server in the org. The solution below does not require this.

Prerequisites

  • Active Directory is installed and the Forest Functional Level is Windows Server 2012 R2 or higher.
  • The Exchange Management Tools (EMT) must be installed on a domain-joined computer. Azure AD-joined by itself is not enough, since we need to be able to update Active Directory.
  • EMT can be installed on Windows 10, Windows 11, or any Windows Server 2016+ server.
  • You will need the Exchange Server 2019 CU12 or later media.
  • The AD schema will be updated during EMT installation. These procedures assume the installation is being performed by a Domain Admin.

Steps for Installing the Exchange Management Tools

  • Logon to the domain-joined computer or server where you want to install the EMT as a Domain Admin. For ease of installation, it is recommended that this computer be in the same AD site as the AD Schema Master.
  • Install the .NET Framework 4.8.
  • Install the Visual C++ 2012 Runtime.
  • Install Windows Remote Server Administration Tools (RSAT) for Windows 10 or Windows 11. On Windows Server add the AD DS Tools from Server Manager.
  • Install the IIS 6 Metabase Compatibility component using the following command:
    • dism /online /Enable-Feature /FeatureName:IIS-IIS6ManagementCompatibility /all
  • Restart the management computer twice to ensure all files and installations are up-to-date.
  • Run Setup from the Exchange 2019 CU12+ media
    • Select only Management Tools in the Server Role Selection
    • You will be prompted to add the Exchange Organization Name (i.e., Contoso)
    • Restart the computer after EMT installation
  • Run the C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Add-PermissionForEMT.ps1 script from an elevated PowerShell prompt to create the Recipient Management EMT security group in the Users container.
  • Add admin accounts to the new Recipient Management EMT group. Domain Admins already have rights to run the EMT and do not need to be added.
  • Create a shortcut on the Desktop to the EMT:
    • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command "Add-PSSnapin *RecipientManagement"
    • Configure the shortcut to run as Administrator
Note:
All mailbox management will be done using the EMT PowerShell cmdlets. The Exchange Management Shell (EMS) will also be installed, but you will never use it because you have no Exchange Server to connect to.

There is no built-in GUI for EMT recipient management, but fellow Office Apps & Services MVP Steve Goodman wrote one on GitHub. You may want to check it out. 

Also, be aware that the EMT does not support roles based access controls (RBAC) and there is no auditing available. For complete Microsoft EMT documentation see Install the Exchange management tools | Microsoft Learn.

Microsoft Exchange System Objects (MESO) Configuration

In order for admins to create remote mailboxes, you need to add a remote domain to the Exchange configuration partition in Active Directory. This is done using ADSI Edit. The usual disclaimer applies - Don't use this tool unless you know what you're doing. I accept no responsibility. Yada yada yada.
  • Begin by getting your Microsoft 365 tenant's remote routing domain.
    • Open Exchange Admin Center
    • Navigate to Mail Flow > Accepted Domains
    • Record the accepted domain of the domain that looks like domain.mail.onmicrosoft.com
  • Open ADSIEdit.msc from the management computer. This was installed when you installed the Windows Remote Server Administration Tools (RSAT).
  • Connect to the Configuration Naming Context.
  • Navigate to CN=Configuration > CN=Services > CN=Microsoft Exchange > CN=domain > CN=Global Settings > CN=Internet Message Formats
  • Right-click CN=Internet Message Formats and select New > Object...
  • Select the class msExchDomainContentConfig and click Next
  • Enter Hybrid Domain - domain.mail.onmicrosoft.com for the value, using the value recorded above. Click Next and Finish.
  • Edit the Hybrid Domain you just created and set the following values:
    • contentType: 0
    • domainName: domain.mail.onmicrosoft.com, using the value recorded above
    • msExchContentByteEncoderTypeFor7BitCharsets: 15
    • msExchContentPreferredInternetCodePageForShiftJis: 0
    • msExchDomainContentConfigFlags: 1
    • msExchMinAdminVersion: -2147453113
    • msExchResolveP2: 2147483647
    • msExchRoutingAcceptMessageType: 351
    • msExchRoutingDisplaySenderEnabled: True
    • msExchVersion: 4535486012416
    • sendTNEF: True
  • Close ADSI Edit.

Add the remote routing domain as an accepted domain.
  • Run the following from an elevated EMT prompt, using the value you recorded above:
    • New-AcceptedDomain domain.mail.onmicrosoft.com -DomainName domain.mail.onmicrosoft.com

Update the email address policy that was created when the EMT was installed.
  • Run the following from an elevated EMT prompt:
    • Get-EmailAddressPolicy | Set-EmailAddressPolicy -EnabledEmailAddressTemplates "SMTP:@domain.com","smtp:@domain.mail.onmicrosoft.com"
    • Replace the domains with the correct values.
      • SMTP:@domain.com (SMTP in all caps) is the primary SMTP address for your organization.
      • smtp:@domain.mail.onmicrosoft.com is the remote routing domain that you recorded above.

Now you can run all the EMT cmdlets to update your on-prem user accounts, mailboxes, and groups.

Configure AD Synchronization with Azure AD

Now that you have a way to update Exchange attributes in AD, the final step is to configure Azure AD Connect to sync the AD objects with Azure AD. 

If your environment already has AAD Connect installed and configured, you only need to update the AAD Connect configuration to use Exchange Hybrid Deployment in Optional Features.



If your environment doesn't already have Azure AD Connect installed and configured, you will need to do so and perform a soft match of the AD accounts to Azure AD. That's beyond the scope of this article. 

If you need help please reach out to me at EXPTA Consulting.

Read more ...

AAD Connect 2.0.88.0 breaks Shared Mailboxes for Exchange hybrid customers

Tuesday, December 21, 2021

Microsoft released Azure AD Connect version 2.0.88.0 as a download-only version on 12/16/2021. This update includes several bug fixes and introduces support for syncing AD objects from a single forest to multiple tenants.

However, this version contains a new potentially devastating bug that removes disabled user accounts in AD from Azure AD

Because shared mailboxes use disabled user accounts this means those mail users are also deleted from Exchange Online. Cloud users will no longer see on-prem shared mailboxes in the GAL or be able to access them. Inbound mail flow will also be affected for these mailboxes since they no longer exist from an Exchange Online Protection perspective.

Luckily, version 2.0.88.0 is not being pushed as an auto upgrade version, so only customers who download and install it are affected.

AAD Connect version 2.0.89.0 has been released. If you are affected by this bug, you should update to the latest version. See my other updates below.

The workaround is to remove AAD Connect 2.0.88.0 and reinstall the previous AAD Connect version 2.0.28.0. Since Microsoft removes all but the most current version, I've made AAD Connect 2.0.28.0 available on my blog here.

I recommend exporting your current AAD Connect configuration first, then importing it when installing version 2.0.28.0. Be sure to uncheck the "Enable staging mode" when completing the installation. 

During the first sync you will see that the disabled accounts in AD are being synced again to Azure AD.


Update #1 - Dec 22, 2021

The Azure AD Connect Version History website was updated yesterday after my blog post to say that version 2.0.89.0 has been released which addresses this issue. However, at this time only 2.0.88.0 is still available from the AAD Connect download website.

Update #2 - Dec 22, 2021

AAD Connect version 2.0.89.0 is now available for download. Strangely, this new version is no longer listed in the version history. :-/ 

I  have confirmed that the bug has been squashed.


Read more ...

Azure AD Connect V1.X versions no longer support the V2 endpoint

Thursday, November 4, 2021

Microsoft introduced the Azure AD Connect sync V2 endpoint with version 1.6.4.0 in March 2021. Among the improvements, the V2 endpoint includes performance improvements and allows for synchronization of groups with up to 250K members. Enterprise customers with groups of 50K or more were encouraged to move to the new V2 endpoint.

AAD Connect version 2.0.3.0 was released in July 2021 and was a major upgrade. It supports the V2 endpoint by default, but requires Windows Server 2016 or 2019 due to it's dependency on SQL Server Express 2019 for localDB. There are still many customers running AADC V1.x for this reason.

Today, Microsoft updated the AADC version history to say that the V2 endpoint is no longer available for V1.x versions

UPDATE - 11/10/2021: Microsoft just added the following information to the AAD Connect version history:

Known Issues

There is an issue where customers who have the V2 endpoint running with an older version and try to upgrade to a newer V1.6 release will see that the 50K limitation on group membership is reinstated. We will not fix this issue in V1.6 and require customers to upgrade to AADConnect V2.0 if this is an issue for them.

Azure AD Connect V1.x customers are strongly encouraged to update to V2.x, keeping in mind that this may require installing AADC V2.x on a new Windows 2016 or Windows 2019 server. I wrote a step-by-step article on upgrading here.

In the meantime, if you are still using Azure AD Connect 1.x you should make sure you're using the V1 endpoint using the following steps.

First, check to see which sync endpoint you're using with these cmdlets, run from the server where Azure AD Connect 1.x is running:

  • Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
  • Get-ADSyncAADConnectorExportApiVersion
  • Get-ADSyncAADConnectorImportApiVersion
If both Get-* cmdlets return the value "1", you're using the V1 endpoint. Nothing more to do here, except plan to upgrade to AAD Connect V2.x as soon as reasonable.

If the values returned are "2", you're using the V2 endpoint and need to change it back to V1.
  • Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
  • Set-ADSyncScheduler -SyncCycleEnabled $false
  • Set-ADSyncAADConnectorExportApiVersion 1
  • Set-ADSyncAADConnectorImportApiVersion 1
  • Set-ADSyncScheduler -SyncCycleEnabled $true
Be aware that the V1 endpoint cannot sync groups with 50K+ members. You should plan to upgrade to AAD Connect V2.x as soon as possible.

Read more ...

IMPORTANT: AAD Connect versions 1.x will retire August 31, 2022

Friday, August 27, 2021



Microsoft released AAD Connect version 2.0.8.0 on August 10, 2021 which included many important changes. Not the least of which is that the localDB database used by AADC was changed to SQL Server 2019. This means that AAD Connect version 2.x can only run on Windows Server 2016 or later, since that's a requirement for SQL Server 2019.

Today, Microsoft posted in the Azure Active Directory Connect version history that all 1.x versions of AAD Connect will be retired August 31, 2022, roughly one year after version 2.x was released.

Important

On 31 August 2022, all 1.x versions of Azure Active Directory (Azure AD) Connect will be retired because they include SQL Server 2012 components that will no longer be supported. Either upgrade to the most recent version of Azure AD Connect (2.x version) by that date, or evaluate and switch to Azure AD cloud sync.

You need to make sure you are running a recent version of Azure AD Connect to receive an optimal support experience.

If you run a retired version of Azure AD Connect it may unexpectedly stop working and you may not have the latest security fixes, performance improvements, troubleshooting and diagnostic tools and service enhancements. Moreover, if you require support we may not be able to provide you with the level of service your organization needs.

Go to this article to learn more about Azure Active Directory Connect V2.0, what has changed in V2.0 and how this change impacts you.

Please refer to this article to learn more about how to upgrade Azure AD Connect to the latest version.

For version history information on retired versions, see Azure AD Connect version release history archive

A few notes on this announcement:

  1. "Retired" doesn't necessarily mean it won't work anymore, but I suspect Microsoft will eventually block it in the future. You should ALWAYS keep AAD Connect up-to-date for the best features, performance, and security.
  2. Although the announcement mentions evaluating and switching to Azure AD cloud sync, be aware that AAD cloud sync is not compatible with Exchange. See my article, How to Decide Between Azure AD Connect and Azure AD Connect Cloud Sync on the Practical365 blog. I also recorded a video podcast about AAD cloud sync with Steve Goodman from Practical365 here.
  3. Refer to my article, How to migrate AAD Connect to a new server for step-by-step instructions how to move AAD Connect to a new Windows 2016 Server using the latest version of AADC. There's really no better time to do it than now.

Read more ...

How to migrate AAD Connect to a new server

Wednesday, July 21, 2021

As I posted earlier, Microsoft has released Azure Active Directory Connect version 2.0.3, which now requires Windows Server 2016 or later. Customers running AAD Connect on Windows Server 2012 or Windows Server 2012 R2 will need to install a new copy of AADC on new Windows Server 2016 computer or later.

In this walk-through I will show you how to do this and migrate all your current settings to the new Windows 2016 server. These same steps can be used whenever you wish to move AADC to a new server.

The high-level steps are:

  • Export the existing AAD Connect configuration from the current server.
  • Install the latest version of AADC on a new or existing Windows Server 2016 computer.
  • Import the AADC configuration, put it into staging mode, and sync.
  • Uninstall AADC from the old server.
  • Remove the new server from staging mode.


Begin by exporting the AADC configuration on the current server. Open Azure AD Connect and select View or export current configuration.

Select View or export current configuration and click Next

Click the Export Settings button

The settings will be exported as a single JSON file in C:\ProgramData\AADConnect by default.
Copy this file to the new AAD Connect server.

Now login to the Windows Server 2016 or later computer where you want to install AADC. This can be either a new or existing domain-joined server.

Download the latest version of AAD Connect from https://www.microsoft.com/en-us/download/details.aspx?id=47594 and install it.

Start the AADC installer.


Select Customize since we're going to import the existing config.

Check Import synchronization settings and browse to the JSON file you copied from the old server.
Click Install to begin the installation.

The installer will walk you through setup using the existing config, similar to a manual upgrade.

Make sure Enable staging mode is checked, then click Install.

Installation will take a few minutes to complete and should look like this. Click Exit.

Open Computer Management on the new server and add the domain's Enterprise Admins group to the local ADSyncAdmins group so they can manage AAD Connect. Log off and back on to get the new management permissions.

You will notice that the two Azure AD Connect Health Sync services and the Microsoft Azure AD Sync service are now installed and running on the new server.

Open the Synchronization Service Manager client located at "C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe". You will see that the initial full sync occured on the new server.

Now you're ready to complete the AAD Connect migration by uninstalling AADC from the old server and disabling staging mode on the new server.

Login to the old AADC server, open Programs and Features, and uninstall Microsoft Azure AD Connect.

Make sure to check "Also uninstall supporting components" and click Remove.

AADC is successfully uninstalled from the old server.

Now login to the new AADC server again and run Azure AD Connect to disable staging mode.

Select Configure Staging Mode and click Next.


Enter the tenant credentials for an admin who has Hybrid Identity Administrator or Global Admin rights.

Clear the checkbox to Enable staging mode and click Next.


Click Configure to disable staging mode and start the sync process.

Click Exit. The migration to the new AAD Connect server is now complete!


The final step is to delete the old MSOL_<guid> user account from Active Directory. You will find one MSOL_<guid> user account for each AADC installation. Uninstalling AADC does not remove the old account from AD.

Using Active Directory Users and Computers, find the MSOL accounts. They will be normally in the Users container by default. Examine the Description which will tell you which computer created each account.

Delete the MSOL_<guid> account that was created by the old AADC server.


Read more ...

Important updates to AAD Connect

Wednesday, July 21, 2021


AAD Connect is used to synchronize Active Directory with Azure Active directory and is a critical component in a Exchange hybrid configuration. It's very important for admins to keep AAD Connect up-to-date with the latest build for security and feature enhancements.

Microsoft just released AAD Connect version 2.0.3.0, which includes a number of significant changes and new features. At top of the list is that AADC is no longer supported on Windows Server 2012 R2 or earlier. This is because the built-in database, LocalDB, is now using components from SQL Server 2019 which requires Windows Server 2016 or later.

If you're currently running AADC on Windows Server 2012 or Windows Server 2012 R2, auto upgrade will not happen, for obvious reasons.

Customers running AADC on earlier OS's will need to install a new copy of AADC on new Windows Server 2016 computer or later. I wrote a step-by-step walkthrough of that process here.

Other significant changes in this version include:

  • TLS 1.2 is enforced in this build. If TLS 1.2 is disabled in the OS, will you will see an error message when attempting to install AADConnect and the installation will not continue until you have enabled TLS 1.2.
  • Added two new cmdlets to the ADSyncTools module to enable or retrieve TLS 1.2 settings from the Windows Server:
    • Get-ADSyncToolsTls12
    • Set-ADSyncToolsTls12
  • You no longer need to be a Global Admin to install or manage AADC. The "Hybrid Identity Administrator" user role can now be used.
  • AAD now honors the "User must change password at next logon" flag when set in AD.
For a full list of the all the new features and big fixes visit Azure AD Connect: Version release history.

Read more ...

Install AAD Connect 1.6.4.0 if you installed version 1.6.2.4

Thursday, April 1, 2021

Microsoft released AAD Connect 1.6.2.4 as a download-only version. Although it includes significant changes, including updating the software to use the new AAD V2 endpoint, it was not offered as an automatic update. Turns out that was a wise decision since it breaks the Azure AD Connect Health feature.

1.6.4.0

Release status

3/31/2021: Released for download only, not available for auto upgrade

Bug fixes

  • This release fixes a bug in version 1.6.2.4 where, after upgrade to that release, the Azure AD Connect Health feature was not registered correctly and did not work. Customers who have deployed build 1.6.2.4 are requested to update their Azure AD Connect server with this build, which will correctly register the Health feature.

If you installed build 1.6.2.4 (either first-time install or as a manual update) please update ASAP to the newest build 1.6.4.0. Get it here: Download Microsoft Azure Active Directory Connect from Official Microsoft Download Center


Read more ...

New Article: How to Decide Between Azure AD Connect and Azure AD Connect Cloud Sync

Thursday, March 11, 2021

I just published an article describing the differences between using Azure AD Connect and Microsoft's new Azure AD Connect Cloud Sync service. In it, I give the information you need to decide if the new Cloud Sync service is right for you. (Spoiler alert: If you run Exchange hybrid, it isn't.)

Please read How to Decide Between Azure AD Connect and Azure AD Connect Cloud Sync on the Practical 365 website.

Read more ...

Why AAD Connect auto upgrade doesn't always upgrade

Monday, November 16, 2020

Azure AD Connect is a crucial component used to sync user accounts and enable mailboxes on-premises to be migrated to Microsoft 365. Not only does it synchronize accounts from Active Directory to Azure Active Directory, it also is used to configure authentication, provides ways for you to filter objects to sync, enables Exchange hybrid, allows for self-service password reset, enables seamless single sign-on, and more.

AAD Connect receives regular updates that include bug and security fixes as well as feature enhancements. Updates are normally delivered using AAD Connect's auto upgrade feature which is normally enabled by default. You can easily check to see if auto upgrade is configured by running the following cmdlet from your AAD Connect computer:

Get-ADSyncAutoUpgrade

Auto upgrade may be disabled if your deployment is more complicated (i.e., if you're using SQL Server instead of localDB, etc.) or if your admin has manually disabled it.

If AAD Connect auto upgrade is enabled, you may assume that it will automatically upgrade your AADC instance whenever a new version is released. That's not always the case. Clarification about this was recently added to the Azure AD Connect: Version release history website:

To clarify the use of Auto Upgrade, it is meant to push all important updates and critical fixes to you. This is not necessarily the latest version because not all versions will require/include a fix to a critical security issue (just one example of many). An issue like that would be addressed with a new version provided via Auto Upgrade. If there are no such issues, there are no updates pushed out using Auto Upgrade, and in general if you are using the latest auto upgrade version you should be good. However, if you’d like all the latest features and updates, the best way to see if there are any is to check this page and install them as you see fit.

Please follow this link to read more about auto upgrade.

In other words, auto upgrade will only upgrade if your version of AAD Connect needs it. This is similar to the way that Microsoft Update only applies updates for roles and features that are installed in Windows.

If you still want to manually install the latest version, simply download it from the Microsoft Azure Active Directory Connect website and install it. The current version number is listed in the Details section.


Read more ...

Significant Improvements in Azure AD Connect

Wednesday, May 20, 2020

Microsoft just announced that the Azure AD Connect sync V2 endpoint API (public preview) is now available. This new endpoint improves the performance of synchronizations to Azure Active Directory, especially during the exports and imports that happen during sync.

Even though the new V2 endpoint is in public preview, customers can deploy this in their production environments.

For large enterprises, the new endpoint also supports syncing groups with up to 250K members. The previous limit for the V1 endpoint is 50K members. However it's important to know that the new endpoint doesn't have a configured group size limit for Office 365 groups that are written back to Active Directory. For this reason, Microsoft recommends increasing O365 groups incrementally if member size was previously a blocker for your org.

You will need to deploy Azure AD Connect version 1.5.30.0 or later to use the V2 endpoint. Microsoft recommends using a swing migration for deploying the V2 endpoint, where you deploy the V2 endpoint to your staging server, validate it, and then switch over to the staging server. Then you can update your main AAD Connect server to Azure AD Connect version 1.5.30.0. Read the full guidance here.

Switching to the new V2 endpoint is performed via PowerShell.
Set-ADSyncScheduler -SyncCycleEnabled $false
Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
Set-ADSyncAADConnectorExportApiVersion 2
Set-ADSyncAADConnectorImportApiVersion 2
Set-ADSyncScheduler -SyncCycleEnabled $true
 
If you have large groups you will need to manually reconfigure the Out to AAD – Group Join sync rule before re-enabling the sync scheduler. See the deployment guidance document for details.
Read more ...

AAD Connect 1.5.29.0 released - With a gotcha

Friday, April 24, 2020
Microsoft released a major update to AAD Connect with build 1.5.18.0 on April 2, 2020. In the last 22 days they've released three newer builds to fix issues in this updated version.

Today they released AAD Connect build 1.5.29.0 which you can download here. But be aware, in my testing Microsoft Defender SmartScreen in the new Chromium Edge browser blocks the download because "this app is not commonly downloaded or is not signed by its publisher".


In order to download it using Edge, click Show More and Keep anyway. This does not happen with the Chrome browser.

I verified that the download is indeed digitally signed with a valid certificate, so I'm not sure why the download is being blocked.



The AAD Connect version release history on this build only lists one unhelpful hint as to what this build fixes:
1.5.29.0

Release status

04/23/2020: Released for download

Fixed issues
This hotfix build fixes an issue introduced in build 1.5.20.0 where a tenant administrator with MFA was not able to enable DSSO.
DSSO is a new acronym to me and I can't find it any any Microsoft documentation, so if you aren't having any trouble with AAD Connect, I suggest skipping this build until the documentation is updated with a better description.
Brian Desmond advised me that DSSO stands for Desktop Single Sign-On - a term I previously only associated with Okta. It's the early name for Seamless Single Sign-On (SSSO).

Read more ...

AAD Connect version 1.5.18.0 is available now

Friday, April 3, 2020
Microsoft released AAD Connect version 1.5.18.0, which is a major version upgrade. Most AADC implementations should automatically upgrade to the latest version. Run Get-ADSyncAutoUpgrade to ensure automatic upgrade is enabled.

The most important functional change is that group objects now use mS-DS-ConsistencyGuid as the source anchor. This helps in multi-forest scenarios.

Read the Azure AD Connect: Version release history here.

1.5.18.0

Release status

04/02/2020: Released for download

Functional changes ADSyncAutoUpgrade

  • Added support for the mS-DS-ConsistencyGuid feature for group objects. This allows you to move groups between forests or reconnect groups in AD to Azure AD where the AD group objectID has changed, e.g. when an AD server is rebuilt after a calamity. For more information see Moving groups between forests.
  • The mS-DS-ConsistencyGuid attribute is automatically set on al synced groups and you do not have to do anything to enable this feature.
  • Removed the Get-ADSyncRunProfile because it is no longer in use.
  • Changed the warning you see when attempting to use an Enterprise Admin or Domain Admin account for the AD DS connector account to provide more context.
  • Added a new cmdlet to remove objects from the connector space the old CSDelete.exe tool is removed, and it is replaced with the new Remove-ADSyncCSObject cmdlet. The Remove-ADSyncCSObject cmdlet takes a CsObject as input. This object can be retrieved by using the Get-ADSyncCSObject cmdlet.
 Note
The old CSDelete.exe tool has been removed and replaced with the new Remove-ADSyncCSObject cmdlet

Fixed issues

  • Fixed a bug in the group writeback forest/OU selector on rerunning the Azure AD Connect wizard after disabling the feature.
  • Introduced a new error page that will be displayed if the required DCOM registry values are missing with a new help link. Information is also written to log files.
  • Fixed an issue with the creation of the Azure Active Directory synchronization account where enabling Directory Extensions or PHS may fail because the account has not propagated across all service replicas before attempted use.
  • Fixed a bug in the sync errors compression utility that was not handling surrogate characters correctly.
  • Fixed a bug in the auto upgrade which left the server in the scheduler suspended state.
Read more ...

How to Delete a Directory from AAD Connect

Thursday, April 2, 2020
You can use Azure Active Directory Connect (AADC) to synchronize one or more on-premises Active Directories to Azure Active Directory. Once additional directories are added to AADC, it may not be obvious how to remove a directory. Here's how to do it.

First, let's look at our example which syncs two directories, theguillets.com and contoso.com to the same AAD tenant.

Here's what it looks like from the View current configuration option in AADC:



And here's what it looks like from Customize synchronization options in AADC. Notice that you can only add directories, not remove them.



In this example, I want to remove the contoso.com directory from AADC so it will no longer sync to Azure AD. Before we can remove the directory we need to disable the AADC sync scheduler. Run the following PowerShell cmdlet:
Set-ADSyncScheduler -SyncCycleEnabled $false
Next, open the AADC Synchronization Service Manager located at C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe. This tool is useful to see the synchronization process and confirm that syncs are happening error-free.



Click the Connectors button at the top and you will see the directories that are currently configured to sync.



Select the directory you want to remove and click Delete. I'm deleting the contoso.com directory.



Select Delete Connector and connector space and click OK. Click Yes on the following prompt to delete the directory from AADC and Azure AD:



It will take a few seconds to delete the contoso.com directory objects from Azure AD and the AADC metabase.



After the directory has been removed from AADC, re-enable the AADC sync scheduler and perform a delta sync using PowerShell:
Set-ADSyncScheduler -SyncCycleEnabled $true
Start-ADSyncSyncCycle
Click the Operations button at the top and you will see that the contoso.com directory is no longer listed in the sync cycles.



 The directory is now removed from the AADC configuration.

Read more ...

Postpone upgrading AAD Connect if you deployed Hybrid Azure AD join

Tuesday, October 8, 2019
Microsoft has reported an issue with Azure AD Connect 1.4.18.0 and Hybrid Azure AD joined devices. They recommend not deploying this version if you have deployed Hybrid AAD join.

1.4.18.0https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history#14180


Warning
We are investigating an incident where some customers are experiencing an issue with existing Hybrid Azure AD joined devices after upgrading to this version of Azure AD Connect. We advise customers who have deployed Hybrid Azure AD join to postpone upgrading to this version until the root cause of these issues are fully understood and mitigated. More information will be provided as soon as possible.

This version has been removed from manual download until their incident investigation is complete. The latest version available now on the website is AAD Connect 1.3.21.0.

Details of the incident are not available, but if you have deployed AADC 1.4.18.0 and are experiencing problems, I recommend completely uninstalling AAD Connect and installing version 1.3.21.0.

Read more ...