One of my close find and Lead of Infra Mukesh called me last week with a deadline on his mind. One of the clients he consults for is still running an old version of Microsoft Entra Connect (the tool most of us still call AD Connect out of habit), and Microsoft has drawn a hard line in the sand: if you’re not on at least version 2.5.79.0 by September 30, 2026, synchronization simply stops. Not degraded, not delayed, stopped.

What started as a conversation about that deadline turned into a much longer one, because the client in question isn’t syncing from a single domain, they’re syncing from three. So this ended up covering two things at once: how to actually perform the upgrade safely using a swing migration, and everything that has to be true on that server beforehand when more than one domain is involved. I’m combining both parts here, the way we actually talked through it.

Why This Deadline Actually Matters

In May 2025, Microsoft shipped version 2.5.79.0 of Entra Connect Sync with a back-end service hardening change. Since then, they’ve been giving organizations time to move off older builds. Once September 30, 2026 arrives, any Entra Connect Sync server running a version older than 2.5.79.0 will simply stop synchronizing with Microsoft Entra ID. Password hash sync, group writeback, attribute sync, all of it halts until you upgrade.

Mukesh’s advice was blunt: “Don’t treat this like a routine patch. Treat it like a migration project, because for a lot of environments, that’s exactly what it is.”

In-Place Upgrade vs Swing Migration

Microsoft gives you a few ways to get current: automatic upgrade, in-place upgrade, and swing migration. For small, simple environments with a single server and a fairly standard configuration, an in-place upgrade works fine, you upgrade the existing server directly, and Entra Connect handles a full import and full synchronization automatically.

But Mukesh was firm that swing migration is the better route for most real production environments, especially if any of the following are true:

• You haven’t upgraded in over a year, and don’t fully trust what accumulated patches or manual tweaks might do to an in-place upgrade.
• You need to move to a newer Windows Server operating system at the same time.
• You’ve made custom sync rule changes and want to test them safely before they touch production.
• You’re syncing from more than one domain or forest, where a failed in-place upgrade would mean troubleshooting blind across multiple environments at once.
• You simply can’t afford the risk of an upgrade that can’t be rolled back if something breaks mid-way.

The core idea behind swing migration is simple: instead of upgrading your one production server and hoping for the best, you build a second server, get it fully current and fully verified, and only then do you switch production traffic over to it. If anything goes wrong, your original server is still sitting there, untouched, ready to keep serving as your safety net.

Setting the Scene: Cloud Knowledge, Three Domains, One Sync Server

Let’s make this concrete. Cloud Knowledge has grown, and now has three domains under management: corp.cloudknowledge.in, ops.cloudknowledge.in, and a recently acquired company running as cloudops.local in a separate forest. All three sync through a single on-premises Entra Connect server, ADSYNC01, currently on an old build from over a year ago. Shivam Tiwari, shivam.tiwari@cloudknowledge.in, is the identity administrator responsible for getting this environment current before the September 2026 cutoff, without breaking sync for any of the three domains in the process.

Before Shivam even opens an installer on a new server, there’s a set of prerequisites Mukesh insisted he confirm first, precisely because multi-domain setups are where these things quietly go wrong.

Part One: Prerequisites for a Multi-Domain Sync Server

One Server, Not Several

Whether you have a single forest with two or three child domains, or entirely separate forests like Cloud Knowledge does with cloudops.local, Microsoft’s guidance is consistent: one Entra Connect Sync server is expected to reach and synchronize all of them. Running two separate Entra Connect Sync servers against the same Microsoft Entra tenant to split the load or split the domains between them isn’t supported, even if each server is scoped to a mutually exclusive set of objects. The only second server allowed alongside the active one is a staging server, which reads everything but doesn’t export changes.

Mukesh’s framing stuck with me: “Think of it as one brain reaching into multiple rooms, not multiple brains each covering one room.”

The Server Must Be Domain-Joined and Reachable Everywhere

The Entra Connect server has to be joined to a domain, and it must be able to reach every domain and every forest root it’s expected to sync. If cloudops.local sits behind a firewall or in a separate network segment with no line of sight from the server, sync for that domain simply won’t work, regardless of how correctly everything else is configured.

DNS Has to Resolve Both Ways

This is the one Mukesh said trips people up more than anything else. The server needs DNS resolution for two completely different worlds at once: your internal Active Directory namespace, and the internet, specifically Microsoft’s Entra ID endpoints. If internal DNS is fine but the server can’t resolve login.microsoftonline.com, or external DNS works but domain controllers for one of the three domains aren’t resolvable, sync for that piece breaks silently or throws confusing connectivity errors.

.NET Framework and PowerShell Versions

Entra Connect needs at minimum .NET Framework 4.6.2 and PowerShell 5.0. Mukesh always pushes for .NET 4.8 or newer, since Microsoft notes it offers better accessibility compliance and it avoids revisiting this later for other reasons.

TLS 1.2 Must Be Enabled

From Entra Connect version 2.0 onward, TLS 1.0 and 1.1 are no longer accepted, the installer simply fails if TLS 1.2 isn’t enabled on the underlying OS. This is a common gotcha on older Windows Server builds that haven’t been patched or hardened in a while.

One SQL Instance, One Sync Engine

If Cloud Knowledge needs a full SQL Server instance instead of the bundled SQL Express LocalDB, that instance can only host one sync engine. It can’t be shared with MIM Sync, DirSync, or Azure AD Sync, and it needs a case-insensitive collation.

Correct Account Permissions

Shivam needs either a Global Administrator or Hybrid Identity Administrator account for the Entra ID side, assigned directly to his user rather than inherited through group membership, and, on the on-premises side, an account with enough rights across all three domains to read the objects that need to sync.

The PowerShell Checks Mukesh Runs Before Every Install

This is the part Mukesh was most insistent on. Before starting the Entra Connect wizard on the new server, he runs through a short list of checks so nothing surprises him mid-installation.

Check the installed .NET Framework version:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" | Select-Object Release, Version

A Release value of 528040 or higher generally corresponds to .NET 4.8. Anything below the minimum required build means you upgrade .NET before going any further.

Check the PowerShell version:

$PSVersionTable.PSVersion

You want to see at least major version 5.

Check and, if needed, set the execution policy:

Get-ExecutionPolicy
Set-ExecutionPolicy RemoteSigned -Scope LocalMachine

Entra Connect runs signed PowerShell scripts as part of installation, and a restrictive execution policy will quietly block them.

Confirm TLS 1.2 is enabled at the OS level:

[Net.ServicePointManager]::SecurityProtocol

If TLS 1.2 doesn’t appear in the output, or connections to Microsoft endpoints are failing, Mukesh sets the SchUseStrongCrypto registry values for both 32-bit and 64-bit .NET, then reboots:

New-Item -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value 1 -PropertyType DWord -Force

New-Item -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value 1 -PropertyType DWord -Force

Test DNS resolution for each domain, plus the Entra ID endpoints:

Resolve-DnsName corp.cloudknowledge.in
Resolve-DnsName ops.cloudknowledge.in
Resolve-DnsName cloudops.local
Resolve-DnsName login.microsoftonline.com
Resolve-DnsName graph.microsoft.com

If any of these fail to resolve from the server itself, sync for that domain, or the connection to Entra ID entirely, won’t work, and the fix is a DNS problem, not an Entra Connect problem.

Confirm the server can actually reach each domain’s domain controllers:

Test-NetConnection -ComputerName dc01.corp.cloudknowledge.in -Port 389
Test-NetConnection -ComputerName dc01.ops.cloudknowledge.in -Port 389
Test-NetConnection -ComputerName dc01.cloudops.local -Port 389

Port 389 is LDAP. If Cloud Knowledge also uses the Global Catalog for cross-domain lookups, Mukesh checks port 3268 as well.

Verify each domain and forest is actually discoverable from the server:

nltest /dsgetdc:corp.cloudknowledge.in
nltest /dsgetdc:ops.cloudknowledge.in
nltest /dsgetdc:cloudops.local

Confirm outbound HTTPS connectivity to Microsoft Entra endpoints:

Test-NetConnection -ComputerName login.microsoftonline.com -Port 443
Test-NetConnection -ComputerName graph.microsoft.com -Port 443

If Cloud Knowledge routes outbound traffic through a proxy, this is also the point where Mukesh checks whether proxy settings have been added to machine.config, since Entra Connect and the installation wizard won’t pick up system proxy settings automatically without it.

What to Do If One of These Fails

.NET Framework is outdated. Install the latest supported .NET Framework version (4.8 or newer is the safe target), then reboot before retrying the installer.

TLS 1.2 isn’t enabled. Apply the SchUseStrongCrypto registry keys shown above, confirm no group policy is forcing older protocols back on, reboot, and re-check with [Net.ServicePointManager]::SecurityProtocol.

DNS resolution fails for one domain but not others. This is almost always a conditional forwarder or DNS zone problem on the server’s configured DNS servers. Check that it’s pointed at DNS servers that either host or forward correctly for every domain and forest involved, not just the primary one.

Domain controller connectivity fails on port 389 or 3268. Usually a firewall rule between network segments, common when one domain, like cloudops.local in Cloud Knowledge’s case, came from a recently acquired company on a different network. Get the firewall rule opened between the Entra Connect server and the relevant domain controllers before trying again.

Outbound HTTPS to Microsoft endpoints fails. Check proxy configuration first. If a proxy is in place, confirm the URLs from Microsoft’s published Office 365 URL and IP ranges are allowed, and that machine.config has been updated with the proxy address.

Multiple identities appear for the same person across domains. This isn’t a prerequisite issue, it’s a consolidation configuration issue. On the “Uniquely identifying your users” page of the installation wizard, select the option that matches how you want users represented, so someone who technically exists in two domains still ends up as a single object in Entra ID.

Part Two: The Swing Migration Itself, Step by Step

With every prerequisite confirmed, Mukesh walked me through the actual migration at a level of detail beyond just “build a new server and switch.”

Step 1: Document and Export the Current Configuration on ADSYNC01

Before touching anything new, Shivam captures exactly what ADSYNC01 is currently doing, so there’s a clear source of truth to compare against later.

1. On ADSYNC01, he opens the Microsoft Entra Connect wizard and selects View or export current configuration from the additional tasks list. This gives him a readable summary of the current setup: connectors, domain and OU filtering, optional features enabled, and sign-in method.
2. He notes that every time the configuration is changed through the wizard, Entra Connect automatically drops a timestamped JSON file into %ProgramData%\AADConnect, named something like Applied-SynchronizationPolicy-<timestamp>.JSON. He grabs the most recent one and copies it somewhere safe.
3. Because changes made through PowerShell, the Synchronization Service Manager, or the Synchronization Rules Editor aren’t automatically captured in that file, he also runs an on-demand export from the wizard to make sure everything current is actually reflected in the JSON.
4. He copies the exported settings folder (commonly named something like Exported-ServerConfiguration-<date>) to a network share he can reach from the new server.

Step 2: Review and Catalog Custom Sync Rules Separately

The exported JSON captures most of the configuration, but Mukesh was clear that custom synchronization rules need their own separate check, because they don’t always travel cleanly inside that single export.

1. Shivam opens Synchronization Rules Editor on ADSYNC01 and filters the rule list to show only custom rules, not the out-of-box Microsoft default rules, so he has a clean list of exactly what’s been added or changed for Cloud Knowledge, across all three domains.
2. For each custom rule, he selects it and chooses Export. This opens a Notepad window containing a PowerShell script that recreates that rule. He saves each one with a .ps1 extension and keeps them together in one folder, named clearly, one file per rule.
3. He also writes down anything that isn’t a synchronization rule but still counts as custom configuration: domain and OU filtering scope for each of the three domains, optional features like password writeback or group writeback, and the connectors in use. These have to be reapplied manually on the new server since they aren’t part of the rule export.

Step 3: Stand Up the New Server and Import the Configuration

With everything documented, and with the prerequisites from Part One confirmed on the new machine, Shivam provisions ADSYNC02, a new Windows Server matching the OS version Cloud Knowledge wants going forward, and downloads the current Entra Connect Sync installer from the Microsoft Entra Admin Center.

1. He runs the installer as Administrator on ADSYNC02, accepts the license terms, and instead of Express Settings, selects Customize.
2. On the customize path, he ticks Import synchronization settings and browses to the JSON file he copied over from ADSYNC01.
3. He works through the rest of the wizard: Entra global admin credentials for the cloud side, the on-premises AD account for the sync engine (this creates its own new service account, separate from the one ADSYNC01 uses), and the sign-in method matching whatever ADSYNC01 is currently configured for, along with Seamless SSO if it’s enabled. Because this is a multi-domain, multi-forest setup, he double-checks that all three domains, corp.cloudknowledge.in, ops.cloudknowledge.in, and cloudops.local, are correctly picked up as connected directories.
4. On the optional features page, he re-ticks the same boxes ADSYNC01 has enabled: password writeback, group writeback, or anything else in use, since these aren’t always carried over automatically by the JSON import.
5. On the “Uniquely identifying your users” page, he selects the same consolidation option ADSYNC01 uses, so users who exist across more than one of the three domains still resolve to a single identity in Entra ID, rather than duplicating.
6. On the final Ready to configure page, this is the step Mukesh said people forget under pressure, he makes absolutely sure Enable staging mode is ticked before clicking Install. If this checkbox is missed, ADSYNC02 starts exporting changes to Entra ID immediately, alongside ADSYNC01, which is exactly the unsupported dual-active scenario you don’t want.

Step 4: Reapply the Custom Sync Rules

1. On ADSYNC02, Shivam opens Synchronization Rules Editor and exports one of the out-of-box rules for each connector type, purely to get each connector’s new GUID, since with three domains there are multiple connectors to account for.
2. He opens each .ps1 file he saved earlier in a text editor and replaces the old connector GUID from ADSYNC01 with the matching new GUID from ADSYNC02.
3. He runs each updated script in a PowerShell prompt on ADSYNC02, which recreates that custom rule on the new server. He repeats this for every custom rule on his list from Step 2, double-checking each one lands against the correct domain’s connector.

Step 5: Run a Full Import and Full Sync on Staging

With the configuration and custom rules mirrored across all three domains, Shivam lets ADSYNC02 run a full import and full synchronization cycle from the Synchronization Service Manager. Since the server is still in staging mode, none of this exports anything to Entra ID, it’s purely local processing so Shivam can see exactly what would happen if this server went live.

Step 6: Verify Before Switching Anything

This is the step Mukesh kept emphasizing: don’t skip verification.

1. Shivam reviews the pending exports queued up on the staging server’s connectors, checking specifically for unexpected attribute changes or unexpected deletions, on each of the three domain connectors individually.
2. He compares total object counts on ADSYNC02 against what ADSYNC01 currently manages, for every connector, all three on-premises domains and the Entra ID connector.
3. He spot-checks the JSON export summary against the new server’s actual configuration using View or export current configuration on ADSYNC02, comparing it side by side with the original ADSYNC01 export to catch any drift.
4. If anything looks off, whether it’s an unexpected deletion, a missing custom rule, or an object count mismatch on any single domain, this is the moment to fix it, while ADSYNC02 is still safely in staging mode and production is untouched.

Step 7: Swap Active and Staging Roles

Once everything checks out, Shivam switches ADSYNC01 into staging mode using the wizard’s Configure staging mode task, and promotes ADSYNC02 to active the same way, disabling staging mode there. From this point forward, ADSYNC02, now running the current supported version, is the one actually exporting changes to Microsoft Entra ID for all three domains at Cloud Knowledge. He watches the next couple of sync cycles closely to confirm exports are going through cleanly for each domain.

To double-check staging mode status on both servers rather than relying on memory, Mukesh runs this on each:

Get-ADSyncScheduler | Select-Object StagingModeEnabled

It should return True for whichever server is currently in staging mode, and False for the active one. He runs it right before and right after the switch, on both servers, just to be certain it actually took effect.

Step 8: Upgrade or Decommission the Old Server

With ADSYNC01 now sitting in staging mode on the old version, Shivam has two options: upgrade it too using the same installer, so it can serve as a proper disaster-recovery standby running the same current version as ADSYNC02, or fully decommission it. If he decommissions it, he makes sure to completely uninstall Entra Connect and its components, or delete the VM outright, because a forgotten old sync server left running on the network can quietly reintroduce stale data during a future sync cycle if it’s ever powered back on.

The Known Issue Mukesh Warned Me About

Partway through our conversation, Mukesh brought up something he’d personally run into on a recent upgrade to Entra Connect 2.5.190.0, and it’s worth knowing about before you start.

If your miiserver.exe.config file was manually modified in the past, commonly because of earlier Microsoft guidance for enabling Password Hash Synchronization in FIPS-enabled environments, the upgrade process detects that the file has been customized and skips updating it. The result is that a required dependency binding goes missing, and synchronization fails right after the upgrade completes.

The symptom is unmistakable. You’ll see a System.IO.FileLoadException in the sync logs complaining that it couldn’t load the System.Diagnostics.DiagnosticSource assembly, or one of its dependencies, because the located assembly’s manifest doesn’t match what was referenced.

The fix is a manual one, and it only takes a few minutes:

1. Navigate to %programfiles%\Microsoft Azure AD Sync\Bin on the upgraded server.
2. Make a backup copy of miiserver.exe.config before touching anything.
3. Open the file and, inside the assemblyBinding section, add the following entry:

<dependentAssembly>
  <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>

4. Save the file.
5. Restart the ADSync service so the change takes effect.

Mukesh’s rule of thumb: if you know your environment ever touched miiserver.exe.config for FIPS-related PHS configuration, check this file immediately after any upgrade, before assuming sync is healthy again. It’s a quick check that can save you a confusing afternoon of troubleshooting a cryptic assembly loading error.

A Few Things Worth Remembering

Don’t roll back once you’ve cut over. Once your new server has started actively exporting to Microsoft Entra ID, going back to an old DirSync or Azure AD Sync installation isn’t supported, and it can cause real data loss in Entra ID. The swing migration path only moves forward.

Consider whether you need three or four servers instead of two. With just an active and a staging server, you temporarily lose your safety net the moment you upgrade the second one. Some organizations, especially larger ones with multiple domains in play, keep a primary and standby pair on the current version at all times, specifically so there’s always a ready disaster-recovery server.

This deadline is separate from the Cloud Sync migration wave. Microsoft is also encouraging a lot of customers to move from Entra Connect Sync to Entra Cloud Sync entirely, which is a different, longer-term architectural decision. The September 30, 2026 cutoff is strictly about being on a current, supported build of Entra Connect Sync, it doesn’t require you to switch to Cloud Sync to stay compliant.

Final Thoughts

What I took away from this conversation with Mukesh is that this upgrade isn’t something to leave until the last week before the deadline, and it’s even less forgiving when more than one domain is riding on the same server. A swing migration, done properly, takes planning: prerequisites verified on the new server first, a config export, custom rules cataloged and reapplied, a full sync cycle to verify against on every connected domain, and a clean cutover. Rushed under deadline pressure, on a single production server with no rollback path and three domains depending on it, is exactly when things go wrong.

If your organization is still sitting on an old Entra Connect version, especially one syncing multiple domains or forests, now’s the time to start planning the staging server, not in September 2026.

This article is part of the Cloud Knowledge identity and access series. For more deep dives into hybrid identity, IAM, and DevOps practices, visit us at cloudknowledge.in.