Microsoft Entra Connect Sync Halts After Auto-Upgrade: Diagnosing and Fixing Broken Directory Synchronization

Two distinct, documented issues in the same version range produce the symptom of "sync stopped after an upgrade I did not manually initiate."

The miiserver.exe.config auto-upgrade halt (versions 2.5.190.0 and 2.6.1.0). Entra Connect's auto-upgrade mechanism checks for local modifications to miiserver.exe.config and miisclient.exe.config before replacing them. On these two versions, that check did not correctly handle servers where the config file had been previously modified, most commonly because an administrator followed earlier Microsoft guidance to edit miiserver.exe.config to support Password Hash Synchronization on a FIPS-enabled server. The upgrade proceeded without updating the modified file, which left a missing assembly binding redirect for System.Diagnostics.DiagnosticSource. The result is that the ADSync service fails to start after the upgrade completes, with a System.IO.FileLoadException naming that assembly and HRESULT 0x80131040. This is a total halt of the sync engine, not an error surfaced inside a sync run.

The Application-Based Authentication parameter loss (fixed in 2.6.1.0). A separate, related issue on versions prior to 2.6.1.0 caused Application-Based Authentication parameters to be deleted when an administrator used the Synchronization Service Manager UI to modify the Microsoft Entra ID connector configuration directly, rather than through the Entra Connect wizard. Losing those parameters causes wizard failures and breaks automatic certificate rotation for the connector's authentication certificate, which shows up later as an unrelated-looking certificate expiration or authentication failure. Microsoft's own guidance for the affected versions is not to use the Synchronization Service Manager UI to edit connector configuration at all, and to make those changes through the wizard instead.

Both issues share a root cause worth naming plainly: auto-upgrade assumes the server's Entra Connect installation matches a known-good baseline, and both issues are what happens when a prior manual customization or manual edit put the server outside that baseline without auto-upgrade detecting it correctly. Version 2.6.3.0, released March 10, 2026 as a hotfix, closes the gap for the config file case: auto-upgrade now detects modifications to miiserver.exe.config and miisclient.exe.config and skips the automatic upgrade on those servers rather than upgrading into a broken state. A manual upgrade on a server with a previously modified config file can still fail; Microsoft's documented workaround for that case is covered in the fixes section below.

Before applying any fix, confirm you are looking at this specific failure and not a generic sync error:

1. Check the ADSync service state first. Open Services (services.msc) on the Entra Connect server and check whether the Microsoft Azure AD Sync service (ADSync) is running. If it is stopped or in a crash loop, that already points away from a per-object sync error, which requires the service to be running.
2. Check Windows Event Viewer for the specific exception. Look in the Application log for an error referencing System.IO.FileLoadException and System.Diagnostics.DiagnosticSource, with HRESULT 0x80131040 in the exception text. This exact combination is the signature of the miiserver.exe.config auto-upgrade halt. A different exception, or no exception at all with the service simply stopped, means a different cause and this guide's fix will not apply.
3. Confirm the current installed version. Open Synchronization Service Manager (if it will launch) or check the installed program version in Windows, and compare it against 2.5.190.0, 2.6.1.0, or 2.6.3.0. If the server is already on 2.6.3.0 or later and still halted, this is not the known auto-upgrade bug and needs a fresh investigation, likely starting with the generic sync error troubleshooting guide or Microsoft support.
4. Check whether miiserver.exe.config was ever modified. Look for a backup copy, a change ticket, or prior documentation showing the config file was edited, particularly for FIPS-mode Password Hash Synchronization support. If nobody on the team modified this file and the server has always run a stock configuration, the config-mismatch cause does not apply and the halt has a different origin.
5. Check for symptoms of the authentication parameter loss separately. If the sync engine itself is running but the Entra Connect wizard fails on load, or a connector certificate did not auto-rotate as expected, check recent change history for edits made directly through Synchronization Service Manager rather than the wizard. This is a distinct symptom from the FileLoadException halt and has a different fix.

Fix 1: Upgrade to 2.6.3.0 or later. This is the primary fix. Download the current Entra Connect installer from the Microsoft Entra admin center (Get Started page) and run the upgrade manually rather than waiting for auto-upgrade to retry. Version 2.6.3.0 and later detect a modified miiserver.exe.config or miisclient.exe.config before upgrading and skip the automatic upgrade path on that server rather than repeating the failure, but a manual upgrade can still hit an installation failure on a server with a previously customized config file. If the manual upgrade itself fails with the same FileLoadException, proceed to Fix 2 first, then retry the upgrade.

Fix 2: Apply the manual configuration workaround (if you cannot upgrade immediately, or the upgrade itself fails). This is Microsoft's documented workaround for the FileLoadException:

1. Navigate to %programfiles%\Microsoft Azure AD Sync\Bin on the Entra Connect server.
2. Back up miiserver.exe.config before making any change.
3. Open miiserver.exe.config and add a dependent assembly binding redirect for System.Diagnostics.DiagnosticSource inside the assemblyBinding section, redirecting old versions 0.0.0.0 through 8.0.0.0 to the new version 8.0.0.0, with public key token cc7b13ffcd2ddd51.
4. Save the file.
5. Restart the ADSync service and confirm it starts without error.

Apply this same check to miisclient.exe.config if the Synchronization Service Manager client itself also fails to launch with the same exception.

Fix 3: Restore Application-Based Authentication parameters if they were lost. If the connector's authentication parameters were deleted by an edit made through Synchronization Service Manager rather than the wizard, do not attempt to hand-edit the parameters back. Re-run the Entra Connect wizard's authentication configuration step to reprovision Application-Based Authentication cleanly, which regenerates the certificate and parameters the wizard expects. Going forward, make connector configuration changes through the wizard, not Synchronization Service Manager, on any version prior to 2.6.3.0. For the broader set of hardening steps around Application-Based Authentication, certificate lifetime, and service account permissions, see our Entra Connect and Azure AD Connect security hardening guide.

Fix 4: If auto-upgrade is disabled or you are managing rollout manually, confirm the scheduled task and update channel are pointed at 2.6.3.0 or later before re-enabling automatic upgrades, so a future auto-upgrade cycle does not repeat the same failure on a server you have already fixed by hand.

Work through these in order after applying a fix:

1. Confirm the ADSync service is running and stays running. Check Services immediately after the fix, then again 15 to 30 minutes later, to rule out a crash loop that only appears after the first sync attempt.
2. Confirm the installed version. Verify the server now reports 2.6.3.0 or later in the installed program list.
3. Force a sync cycle and watch it complete. From an elevated PowerShell session, run Start-ADSyncSyncCycle -PolicyType Delta and confirm the cycle finishes with a Success result in Synchronization Service Manager's operations tab, rather than stopping partway through or the tool failing to connect at all.
4. Confirm objects are actually flowing again. Pick a small set of recently changed on-premises objects (a new user, a password reset, a group membership change) and confirm the corresponding change appears in Entra ID within the next scheduled cycle.
5. If you touched authentication parameters, validate certificate rotation separately. Check the connector's certificate expiration date and confirm it reflects a normal Application-Based Authentication lifecycle rather than an expired or missing certificate. Do not wait for the next scheduled rotation window to find out it is broken again.
6. Re-enable and monitor the next scheduled auto-upgrade cycle if you disabled it during troubleshooting, and confirm it completes cleanly against the now-current version baseline.

The manual upgrade can still fail on a server with a customized config file. Microsoft's own release notes for 2.6.3.0 state plainly that a manual upgrade may still encounter installation failures if miiserver.exe.config or miisclient.exe.config were previously modified. Auto-upgrade skipping the server protects you from a repeat auto-upgrade failure, it does not retroactively fix a manual upgrade attempt; apply Fix 2 first if a manual upgrade fails with the same exception.

The workaround is a stopgap, not a permanent fix for the underlying customization. If your organization's FIPS-mode Password Hash Synchronization configuration required the original miiserver.exe.config edit, re-adding the assembly binding redirect restores service but does not eliminate the need to track that this server's config file diverges from a stock installation on every future upgrade. Document the modification clearly so the next admin, or the next auto-upgrade cycle, does not rediscover this the hard way.

Restoring authentication parameters through the wizard resets the certificate. If you apply Fix 3, expect the connector's authentication certificate to be reissued as part of that process. Any external system, firewall rule, or monitoring check pinned to the old certificate's thumbprint will need to be updated.

This fix does not address unrelated sync errors that happen to appear after the service restarts. Once the ADSync service is running again, a backlog of normal attribute or object errors that occurred before the halt, or unrelated configuration issues, can surface in the same sync run. Treat those separately using the generic troubleshooting guide rather than assuming they are part of the auto-upgrade bug.

Retired versions have no further support. Entra Connect versions are retired 12 months after a newer version ships. If the affected server is running a version old enough to already be past its support window for reasons unrelated to this bug, plan a full upgrade rather than only patching around this one issue.

Handle this internally through the steps above when the symptoms match exactly: the FileLoadException naming System.Diagnostics.DiagnosticSource, on a server confirmed to be running 2.5.190.0 or 2.6.1.0, with a known or discoverable prior modification to miiserver.exe.config.

Escalate to Microsoft support when any of the following apply:

• The ADSync service still fails to start after both upgrading to 2.6.3.0 or later and applying the manual configuration workaround.
• The exception text does not match the documented signature (a different assembly name, a different HRESULT, or a different exception type entirely), which means you are looking at a different problem that happens to share the surface symptom of "sync stopped after an upgrade."
• Application-Based Authentication parameters are missing and re-running the wizard's authentication step fails to reprovision them, or certificate rotation continues to fail after reprovisioning.
• The server supports a business-critical hybrid identity boundary (federated authentication, password hash sync for a large user population) where extended downtime carries material business risk and you need Microsoft's direct involvement rather than iterative troubleshooting.
• You suspect the miiserver.exe.config modification came from something other than the documented FIPS-mode Password Hash Synchronization guidance, and cannot confirm what changed or why.

When you open a case, have the exact exception text and HRESULT, the pre-upgrade and post-upgrade version numbers, and a copy of the current miiserver.exe.config ready. That is the information Microsoft support will ask for first, and having it up front materially shortens time to resolution.