Upgrading Azure AD Connect to Version 2.0

Azure AD Connect is one of Microsoft’s products for syncing your Active Directory users, groups, and devices to Azure AD. Of these products, it is the most used one and although it has some customization it also is very automated and easy to use in its set up and operations.

The Azure AD Connect application has had several versions since its release and over time Microsoft has posted notices that they would retire earlier versions – for example Microsoft announced in 2018 that they would retire versions 1.1.751 and earlier on 1st April, 2024.

Time has caught up with Microsoft as a few of the required components of Azure AD Connect 1.x will go out of support next year and so Microsoft will retire all 1.x versions on 31st August, 2022. As you can see this is considerably before the more generous retirement dates that had previously been posted.

Therefore, although versions 1.x may continue to sync to Azure AD after the end of August 2022 they will not get security updates, may unexpectedly stop working and will not get product improvement and service enhancements – that is, there will be no more 1.x versions to upgrade to. So, it is time to move to the newly released 2.x version. Upgrading the version is the responsibility of the Global Administrator and the server administrator on which the application is installed.

Version 2.0.3.0, the first 2.x version, was released in July 2021 and there have been three updates to this since then. At the time of writing this blog article (September 2021), the latest version of Azure AD Connect is 2.0.10.0, but we will refer to this version as 2.x in this article, because when you do your own upgrade, you would be upgrading to the latest available at that time and not the version that was released when I happened to write this article!

Version 2.x updates all the components that are going out of support at the end of August 2022 and the single installer for version 2.x updates all this software for you or if you are running the installation on a new server, then it will install the correct components for you. It is not going to work if you install just the components that are being retired, as version 1.x will still use the out-of-date versions already installed. For example, Azure AD Connect version 1.x uses Microsoft SQL Server2012 Express LocalDB, the ADAL authentication library and Visual C++ Runtime version 12. Azure AD Connect version 2.x will use SQL 2019 LocalDB, the MSAL authentication library and Visual C++ Runtime version 14 (as this is required by SQL 2019). Version 2.x will also require the underlying operating system to use TLS 1.2 and it will not install if TLS 1.2 has been disabled.

And it is this collection of requirements that mean there is more to this upgrade than might initially be seen. Previous 1.x upgrades have often been the simple process of downloading the latest version and running the installer or the application auto-updating itself. But this will not happen with version 1.x to 2.x upgrades. The first and biggest reason for this is that 1.x was supported on older versions of Windows Server as SQL Server 2012 would work on Windows Server 2008 R2 and later but SQL Server 2019 requires Windows Server 2016 or later – so if your Azure AD Connect installation is on a Windows Server OS earlier than Windows Server 2016 you have to do a swing migration – that is, install version 2.x on a new server and swap the active sync role to the new server when ready. If you have used the Azure AD Connect server for other roles as well, now would be the time to consider moving them and decommissioning this old server as well as just moving Azure AD Connect. Note that it is not supported to upgrade-in-place the Windows Server OS that Azure AD Connect is installed on and so a swing migration is your only option if your Windows Server OS is going out of support.

If you have installed version 1.x on Windows Server 2016 or later then you can upgrade 1.x to 2.x just by running the installer (and a few other things) unless you have a requirement or desire to do a swing migration. For example, if you have custom sync rules in place then you might already be in the habit of doing a swing migration and so you should keep to this practice here.

Azure AD Connect supports the idea of a standby server, installed, and configured but not syncing to Azure AD – this is known as the Staging Server. The Staging Server is a good Disaster Recovery option for Azure AD Connect and is also useful for the swing migration as the Staging Server can be upgraded to 2.x, changed into the primary active syncing server (and the other server changed to staging role) and if all is good then upgraded to the previous primary sync server.

This was the process I ran one of my client's deployments recently and which I am going to outline below. If you don’t have a staging server or your current deployment is on Windows Server 2012 R2 and earlier then you will need to do a swing migration, but you will migrate to the newly installed server having changed your current active syncing server to staging mode first.

Finally in preparation for a migration from 1.x to 2.x, the later versions of 1.x support a configuration export which can be used when installing 2.x. So, if your current 1.x deployment is not up to date I would suggest starting there – upgrade to the latest 1.x version, export the configuration, and then use that export to build the new 2.x server deployment where you don’t have an existing staging server on Windows Server 2016 or later that you can upgrade directly.

Figure 1 Azure AD Connect - Version 1.6.4.0

As I mentioned above, I recently took a two server Azure AD Connect deployment from version 1.x to 2.x and it was mostly seamless. Here is what I found.

The deployment was already on Windows Server 2019 and there were two servers in two different locations, one being the active syncing server and the other the staging server. We started with the staging server and just downloaded and ran the latest 2.x installer. And this is where I hit my first issue, and this issue is now mentioned on the download page as well. The Windows Server 2019 deployment supported TLS 1.2, but was not detected as being the primary version of TLS in use, so the Azure AD Connect installer errored, pointed me to a Microsoft Docs article on what to run (a short PowerShell script) but after doing this and rebooting the server the Azure AD Connect 2.x installer claimed the previous installation had failed and gave me an option of uninstall or repair. I choose repair and we were fine from that point onward. The installation continued, the dependencies were upgraded, and the sync configuration migrated to the newer settings.

Once this was done, I opened the Synchronization Service Manager application and verified that sync was happening successfully – sync was happening from my Active Directory forests and from Azure AD and as it was in staging mode, there was nothing being synced to Azure AD or back to the Active Directory forests I was syncing from.

With a successful install of Azure AD Connect 2.x on the staging server it was time to place the primary server, which is still on version 1.x, into staging mode. Swinging the sync role to the staging server means the configuration on the second server starts to be used – so check the configuration of both primary and staging servers and make sure they match – for example, if the staging server is missing an OU to sync from then the objects in this OU will be deleted in the cloud when this server becomes the primary server. I would also suggest running a full sync at this point as well.

Figure 2 Azure AD Connect - Configure Staging Mode

Once staging mode is enabled on the primary server, disable staging mode on the recently upgrading second server. This second server will become the primary server and will complete an export step which it was not doing when in staging mode. You should wait until this export finishes before starting the upgrade on the original primary server – the plan is that there is always one of the two servers successfully working.

As mentioned above, there is an issue in version 2.0.10.0 that breaks the installer if the installer somehow detects that TLS 1.2 is not enabled even though it is. All the supported OSes for Azure AD Connect v2.x have TLS 1.2 enabled but the only workaround at the time of writing it to run the script that Microsoft provides on the Azure AD Connect documentation to enable TLS 1.2 – you need to run this if the installer tells you to.

Figure 3 Azure AD Connect - TLS 1.2 Detection

Because the installer is just looking for the existence of registry keys to see if TLS 1.2 is enabled, you just run the PowerShell Microsoft provide and there is in this case no need to reboot the server because TLS 1.2 was enabled, and it was just an issue detecting this. Restart the Azure AD Connect wizard to complete the upgrade. If you run the installer software again you will get a prompt about repair or remove the software as mentioned above – choose Repair here if you rerun the installer application.

Figure 4 Azure AD Connect - Running the installer after the TLS 1.2 PowerShell

The Azure AD Connect upgrade wizard will update the components required (SQL, VC++ etc) and will then ask you enter your Azure AD credentials, and for Azure AD Connect v2.x you do not always need to be the Global Administrator – the new “Hybrid Identity Administrator” role can be used to avoid giving away more Global Administrator role holders. The time to complete the upgrade is a factor of the number of Active Directory forests that you are syncing.

Figure 5 Azure AD Connect - Upgrading

Once your upgrade is completed ensure sync is working from the Azure AD Synchronization Service application and then you can optionally move staging server role back to the original server before you started this whole process. At the end of the upgrade a Full Import from Azure AD and then a Full Synchronization step happens for each connector, so you need to wait for this to complete before you can enable staging mode on your standby server and then turn off staging mode on your original primary server.

Figure 6 Azure AD Connect - Upgraded to Version 2.0.10.0

Azure AD Connect Monitoring and Reporting

Active Directory is the foundation of your network, and the structure that controls access to the most critical resources in your organization. The ENow Azure AD Connect Monitoring and Reporting tool uncovers cracks in your Active Directory that can cause a security breach or poor end-user experience and enables you to quickly identify and remove users that have inappropriate access to privileged groups (Schema Admins, Domain Administrators). While ENow is not an auditing software, our reports reduce the amount of work required to cover HIPAA, SOX, and other compliance audits.

Access your FREE 14-day trial to accelerate your security awareness and simplify your compliance audits. Includes entire library of reports.