Hey Checkyourlogs Fans,

Migrating from Azure AD Connect to the new Microsoft Entra ID Connect has become urgent for many organizations. Microsoft has set a deadline of April 30, 2025, for upgrading to the latest Entra Connect V2 release. More details here: learn.microsoft.com. Failing to upgrade in time doesn’t stop directory synchronization, but critical wizard functions and configuration capabilities will cease to work after that date. In this “notes from the field” post, I’ll share how we performed a side-by-side migration from an older Azure AD Connect server (Windows Server 2019) to a new Microsoft Entra ID Connect server (Windows Server 2022), including the challenges we encountered and how we resolved them. This migration was done in a production environment with minimal downtime, using staging mode and a custom service account (MSOL_Sync) for the sync service.

Background: Why the Migration and Why Now?

Microsoft’s rebranding of Azure AD to Microsoft Entra ID in 2023 also came with updates to Azure AD Connect (now Entra ID Connect) sync services. More details here: ​carysun.com. Many older Azure AD Connect installations (especially version 1.x or early 2.x) are now out of support or will be unsupported after April 30, 2025. In our case, the existing sync server was running on Azure AD Connect 1.6 on Windows Server 2019, which needed to be upgraded to the 2.x series for continued support. Rather than doing an in-place upgrade, we chose a side-by-side migration to a new Windows Server 2022 host. This approach allowed us to:

  • Minimize Risk: During the transition, the old server remained intact (in staging mode) as a rollback option.
  • Use the Latest OS and Prerequisites: Entra Connect V2 requires newer components (like .net 4.8 and newer SQL Localdb) and is better suited for Windows Server 2022.
  • Test Configuration on the new server without impacting the ActiveSync running on the old server.

Microsoft’s guidance was clear that being on the latest Entra Connect version (2.4. XX or above) is required to avoid functionality loss in the admin wizard after April 30, 2025. So we set out to migrate well before the deadline.

Preparation: New Server Setup and Configuration Export

Our new server (WS2022) was built and fully patched. We installed the Microsoft Entra ID Connect software (which at the time was the latest 2.x release) but initially kept it in staging mode (more on that shortly). Preparation involved a few key steps:

  • Exporting the Old Configuration: We ran the Azure AD Connect wizard on the old Azure AD Connect server and used the “View or export current configuration” option to generate a configuration file (.JSON). This “Export Settings” feature (in preview) allowed us to capture all synchronization settings, including selected OUS, filtering, and optional features, and import them on the new server. The JSON file was then copied over to the new server.
  • Setting Up a Service Account (MSOL_Sync): Rather than using the default managed account, we created a dedicated AD account, MSOL_Sync, to run the directory synchronization. A custom service account offers more control (for example, we can pre-set its permissions and manage its password). We made MSOL_Sync a regular domain user (not a Domain Admin) and followed Microsoft’s documentation to delegate the proper Active Directory permissions, which it needs. According to Microsoft, the account used by Entra Connect must have the ability to reset passwords, change passwords, write to the lockoutTime and pwdLastSet attributes, and the “Unexpire Password” extended right on user objects. As recommended, we granted these rights at the domain level (to all descendant user objects). This is crucial for features like Password Writeback (allowing cloud password resets to write back to on-prem AD).
  • Permissions Verification: It’s worth double-checking that the service account also has Replicate Directory Changes permissions on the domain (for password hash sync). Because we chose a custom account, we manually ensured it had “Replicating Directory Changes” and “Replicating Directory Changes All” on the domain partitions and the password reset/writeback permissions. This aligns with the official guidance – if you miss these permissions, the configuration may appear correct, but password writeback will fail with errors (more on the errors we saw later).

With the new server ready, the configuration file in hand, and the service account prepped, we proceeded to install and configure Microsoft Entra ID Connect on the new server.

Migration Process: Side-by-Side with Staging Mode

We used staging mode on the new Entra ID Connect server to avoid disruption during the transition. Staging mode allows an Azure AD Connect (or Entra Connect) server to import and synchronize directory data without exporting changes to Azure AD or AD. Essentially, it keeps the server passive/standby. Here’s how we executed the side-by-side cutover:

  1. Install Entra ID Connect on New Server (Staging Mode): We ran the Entra Connect setup on the new WS2022 server using custom settings. During the setup, we chose to import the previously exported configuration JSON. This pre-populated all our existing settings (Azure AD tenant info, which AD to connect, sync rules, etc.), so we didn’t have to reconfigure everything manually. When prompted, we specified the MSOL_Sync account as the AD connector account (the installer can create or let you specify it, but we opted to input our existing account credentials). We also enabled additional features on the old server, like Password Hash Synchronization, Password Writeback, etc., to match parity with the old setup.
  2. Enable Staging on New Server: On the final step of the installation wizard (“Ready to configure”), we checked the box for “Enable staging mode” (and also left “Start synchronization when complete” checked). Once we hit Install, the new server would start syncing from on-prem and Azure AD, but it would not export any changes to the cloud or on-prem. The installer even warns that only one server should export changes simultaneously. The new server was up and running in parallel, continuously receiving updates from AD and Azure AD, but in read-only sync mode. In the Synchronization Service Manager, we verified that the initial sync cycles were completed on the new server (all runs are successful). The new server was effectively a standby, ready to take over.
    • Tip: While in staging mode, the new server also serves as a backup for sync. It’s tracking all changes. If something went wrong on the old server, we could quickly turn off staging on the new server to make it active.
  3. Cutover – Switch Active to New Server: After observing the new server running in staging for a short period and confirming no sync errors, we performed the cutover during a maintenance window. The cutover steps were:
    a. Put Old Server into Staging Mode: On the old Azure AD Connect server (WS2019), we opened the Azure AD Connect wizard -> Configure -> and chose “Configure staging mode”. We signed in with an Azure AD Global Admin as required, enabled staging mode on the old server, and then completed the configuration. This immediately stopped the old server from exporting further changes to Azure AD (now only imports). Essentially, the old server became the standby.
    b. Disable Staging on New Server: Next, we went to the new server’s Entra Connect wizard, chose “Configure staging mode”, and unchecked the “Enable staging mode” option (turning it off for the new server). We completed that configuration, which made the new server the active synchronization server (it now imports and exports changes). We checked the option “Start synchronization process when configuration completes” so it would begin syncing immediately. Once applied, the new server took over as the production sync engine.

This switch was seamless – the sync schedule continued on the new server with only a brief gap of a few minutes during the handover. Because the new server had been continuously syncing, it didn’t need to do a full import again; it already knew the state of objects. After enabling it, the pending exports (if any) were processed to Azure AD. We monitored the Azure AD Connect Health/Portal to see that the sync status was healthy on the new server and that the last sync time updated accordingly.

  1. Post-Cutover Monitoring: With the new server live, we closely watched the on-premises Event Logs and the Azure AD Connect Sync service logs for errors. We also did test modifications (e.g., create a new AD user, change an existing user attribute, test a cloud password reset) to ensure both dirsync and writeback were functioning as expected.
  2. Keep the Old Server in Staging for Safety: We did not immediately uninstall or shut down the old server. As a safety net, we left the old server in staging mode for about one week after the cutover. If any critical issue was discovered on the new server, we could quickly revert by disabling staging on the old server (making it active again). Fortunately, no rollback was needed. After a week of smooth operations, we powered off the old server. Following further confirmation that everything was still fine, we formally decommissioned the old Azure AD Connect server (uninstalling Azure AD Connect from it and cleaning it up). (Cary Sun’s migration guide recommends keeping the old server around for a few days, just in case.)

At this point, the new Entra ID Connect on Server 2022 was our sole active sync server. The organization’s directory synchronization continued normally, and we met the Microsoft-imposed deadline well ahead of time.

Troubleshooting: Event ID 6629 and 33008 – Fixing Permissions

Even with careful planning, we hit an interesting issue during post-cutover testing. We encountered errors while testing the Self-Service Password Reset (SSPR) writeback from Azure AD (to ensure our users can reset their passwords in the cloud and have it write back on-prem). Users attempting password resets received an error message indicating the on-premises policy did not allow the reset. In the new server’s Application event log, we saw Event ID 6629 and Event ID 33008 logged each time a password reset was attempted.

  • Event ID 33008 (ADPasswordPolicyError): This error in the Microsoft Entra Connect logs generally means the set password doesn’t meet the on-prem AD password policy requirements. However, we were using a known-good password that met complexity in our case. Another clue was Event ID 6629 (an error code which, while not documented on Microsoft’s site under that number, correlated with a generic “restriction prevents the password from being changed” error).

After some investigation, we realized the root cause was missing permissions for the MSOL_Sync account in AD. Despite our efforts to delegate rights, one permission was overlooked: the “Unexpire Password” extended right was not correctly applied to the account in one of the domains. Essentially, the account lacked a specific permission to allow password resets (which made AD respond as if a policy restriction was in place). This was a classic case of the documentation being right that if you don’t assign all the required permissions, password writeback may appear configured correctly, but will throw errors.

Resolution: We followed Microsoft’s guidelines to the letter to fix the permissions. Specifically, we opened Active Directory Users and Computers (ADUC) with Advanced Features enabled and did the following for each domain partition:

  • Granted Reset Password and Change Password permissions to the MSOL_Sync account at the domain root for all descendant user objects.
  • Granted write permissions on the lockoutTime and pwdLastSet attributes on all descendant user objects.
  • Granted, the “Unexpire Password” extends right on the domain object (it applies to all descendant user objects). More details are here: learn.microsoft.com.

After applying these permissions (and allowing AD replication to propagate them), we re-tested the SSPR functionality. This time, the password reset from Azure updated the on-prem AD. The 6629/33008 errors disappeared from the logs. In summary, the error events were indeed caused by a permissions gap. Once corrected, the new Entra ID Connect server was fully functional, and the password writeback worked as intended.

Conclusion and Lessons Learned

Migrating to Microsoft Entra ID Connect (Azure AD Connect V2) on a new server was a successful project, but not without lessons learned:

  • Plan for Microsoft’s Deadlines: The April 30, 2025 deadline was a driving force. Proactively upgrading ensured we remain supported and retain full functionality (the sync service would have kept running, but specific configuration changes or the sync wizard would fail beyond that date). It’s always better to upgrade on your schedule than scramble after losing features.
  • Use Side-by-Side with Staging for Zero Downtime: The side-by-side approach with staging mode allowed for a near-seamless transition. Both the old and new servers synced in parallel, and only one exported changes at any time. This provided a safety net and a quick rollback strategy. We highly recommend this approach for organizations with mission-critical sync requirements.
  • Leverage Export/Import Configuration: The ability to export the config from the old server and import it on the new server saved us a ton of time and ensured consistency. All the selected OU filters, synchronization rules, etc., came over exactly as before. Double-check things like custom sync rules or attribute mappings if you have any – those should come over via the export, but it’s worth validating on the new server.
  • Please don’t Skimp on Service Account Setup: Using a custom service account (like our MSOL_Sync) is a good practice, but requires careful configuration. Follow Microsoft’s documentation for account permissions meticulously. Missing even one permission (as we initially did) can lead to subtle issues, especially with features like password writeback. After fixing the permissions, we saw how everything started working smoothly – a direct testament to following the principle of least privilege with the proper privileges in place.
  • Monitor Logs and Test Thoroughly: After migration, we didn’t declare victory until we tested key functionalities – syncing new changes, password writeback, group writeback (if enabled), etc. Monitoring the event logs (for any error IDS like 6329/6629, 33008, or others) was crucial to catch issues early. It’s easier to adjust configurations or permissions in the immediate aftermath of a migration than weeks later when an overlooked issue finally surfaces.

Ultimately, our new Entra ID Connect on Windows 2022 is running flawlessly. We have retired the old 2019 server, and the organization is positioned to stay current with Microsoft’s updates going forward. If you’re still on an older Azure AD Connect instance, consider planning your move now. The process isn’t trivial, but you can achieve a smooth migration with careful preparation and by following community guides like Cary Sun’s step-by-step blog post on migrating to v2 (which we used as a reference). And as always, ensure you refer to Microsoft’s official documentation for any special configurations – in our case, the password writeback permission setup was critical.

Dave Kawula – Microsoft MVP