Earlier this week, I wrote on installing Azure AD Connect on Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012.
Today, I want to elaborate a bit on why I don’t recommend installing Azure AD Connect on Windows Server 2008, despite the many reasons you might have to think you want to.
1. It doesn’t support password synchronization
The number one reason why you don’t want Azure AD Connect on Windows Server 2008 is that this combination doesn’t support password synchronization.
This limits the functionality of Azure AD Connect.
… while your reason to stick with Windows Server 2008 was because you dídn’t have (client access) licenses for Windows Server 2008 R2, Windows Server 2012 or Windows Server 2012 R2…
2. It doesn’t support configuring write-back
Azure AD Connect supports write-back functionality through the ADSyncPrep.psm1 Windows PowerShell Module in the \ADPrep folder of the Azure AD Connect installation folder.
You’ll find the following Cmdlets in this Windows PowerShell Module:
The Windows PowerShell Module, however, requires the Active Directory PowerShell Module. This module is not available for Windows Server 2008.
To configure the write-back capabilities of Azure AD Connect, you will need to copy the PowerShell Module off of Windows Server on which you installed Azure AD Connect to a Windows Server or Windows Client that is capable of running the Active Directory Windows PowerShell Module, the Azure Active Directory Windows PowerShell Module and the ADSyncPrep.psm1 Windows PowerShell Module.
… while your reason to stick with Windows Server 2008 was because it aligned perfectly with your Windows XP clients…
3. It is not as secure as on later Windows versions
Through the decades, Microsoft has increased the level of built-in security mechanisms in each Windows and Windows Server version.
Azure AD Connect benefits from each and every enabled security measure, since it is a (vital) link in your Hybrid Identity chain. Your Identity and Access Management (IAM) might be state of the art, but when your Azure AD Connect installation runs on (a full installation of) Windows Server 2008, this will be a relatively easy target.
Rest assured that the passwords used for the Management Agent (MA) service accounts are stored as encrypted strings in the Azure AD Sync database.
The aspect of security holds especially true for x86 (32-bit) versions of Windows Server 2008, where you would not have the benefit of driver signing.
… while you had secured everything…
4. It requires four reboots to get installed
When you want to deploy Azure AD Connect it requires four reboots:
- After you install Windows Management Framework Core (KB968930)
- After you install the Windows Graphics, Imaging and XPS Library (KB971512)
- After you install Extended Protection for Authentication (KB968389)
- After you install the Windows Management Framework 3.0 (KB2506414)
This makes it far from ideal to install Azure AD Connect side-by-side on a Windows Server 2008 installation.
… while you wanted to save time and money by reusing an existing server…
5. Its support lifecycle won’t last five years
While the same goes for Windows Server 2008 R2, Windows Server 2008s extended support lifecycle ends on January 14th, 2020. Already, Windows Server 2008 and Windows Server 2008 R2 don’t offer mainstream support options.
My rule of thumb is that when I deploy something, I deploy it so my customers can enjoy it for the time they need to write off the hardware and/or software. Writing off in four years is hard.
… while your reason to use Windows Server 2008 was to save money…
Don’t install Azure AD Connect on Windows Server 2008. When you do, though, make sure you’re doing it for the right reasons.
Installing Azure AD Connect on Windows Server 2008, 2008 R2 and 2012
Hashing password hashes in Azure AD Connect and Sync per scenario
A new version of Azure AD Connect was released today
Ten things you should know about Azure AD Connect and Azure AD Sync