ADSync: error 206: The filename or extension is too long (after in-place upgrade WinSrv2016 to 2025)

Question

Hello,

after performing an in-place upgrade from Windows Server 2016 to Windows Server 2025, I am experiencing an issue with Azure AD Connect (ADSync) on one of my domain controllers.

When attempting to start the ADSync service, it fails with the following error:

error 206: The filename or extension is too long

Details:

Service: ADSync

Executable path: C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe

The service is running under a domain user account

The issue appeared only after the in-place upgrade

Important note:

On a second domain controller, which was also upgraded in place from Windows Server 2016 to 2025, the ADSync service starts and works correctly with the same configuration.

I would appreciate any help or guidance on how to resolve this issue.Hello,

after performing an in-place upgrade from Windows Server 2016 to Windows Server 2025, I am experiencing an issue with Azure AD Connect (ADSync) on one of my domain controllers.

When attempting to start the ADSync service, it fails with the following error:

error 206: The filename or extension is too long

Details:

Service: ADSync

Executable path:
C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe

The service is running under a domain user account

The issue appeared only after the in-place upgrade

Important note:

On a second domain controller, which was also upgraded in place from Windows Server 2016 to 2025, the ADSync service starts and works correctly with the same configuration.

I would appreciate any help or guidance on how to resolve this issue.

Answer 1

Hello Mateusz Wantoch-Rekowski,

Has your issue been solved? If it has, please accept the answer so that it could be spread further to those in need too. If not, is there anything I can help you with? Please let me know. :)

VP

Answer 2

Hello again Mateusz Wantoch-Rekowski,

Your screenshots provide definitive evidence that negates the previous hypothesis regarding the Registry path and System PATH variable. Image 2 confirms the ImagePath is correctly quoted, and Image 3 shows a standard, concise System PATH that is well within the 4096-character limit. therefore, do not modify the PATH variable, as it is healthy. The shift to Error 1053 after switching to the Local System account is expected behavior because the Local System account lacks the necessary NTFS permissions to the underlying SQL LocalDB files (.mdf/.ldf) and does not possess the encryption keys tied to the original service account’s profile.

The persistence of Error 206 on the domain account, despite a correct registry entry, suggests that the User Profile or the Environment Block for that specific domain service account was corrupted during the OS upgrade, or the underlying SQL Server LocalDB instance is failing to initialize due to driver mismatches. Since the in-place upgrade modifies base libraries, the ADSync service, which acts as a wrapper for the miiserver.exe process, is likely crashing when it attempts to spawn the SQL instance. To pinpoint the exact failure, please revert the service to the original domain user account and check the Windows Event Viewer (specifically the Application log) for errors from sources "ADSync" or "SQL LocalDB" immediately following a start attempt.

To resolve this without further guesswork, open a Command Prompt as Administrator and run the command sqllocaldb info .\ADSync. If this returns an error or shows the instance is stopped, attempt to manually start it with sqllocaldb start .\ADSync. If the manual start fails (likely returning the true error masked by the generic "206"), you must repair the SQL component. Navigate to Control Panel > Programs and Features and attempt a "Repair" on "Microsoft SQL Server 2019 LocalDB" (or the specific version installed). If repair fails, uninstall the LocalDB component and reinstall it manually using the MSI found in the installation media or the Packages\SqlLocalDB folder of the AADC setup files. This ensures the database engine required by the service is actually functional before the service wrapper attempts to launch it.

VP

Answer 3

Hi!
I have checked the path in the registry and it looks correct on my side.

Could you please confirm what the expected / correct system PATH value should be?

I also changed the account under which the service is running to a local account. After this change, I no longer receive error 206, but now the service fails with error 1053.

All tests are being performed in an environment without internet access.
Additionally, I reinstalled Azure AD Connect (2.6.1 version), but unfortunately this did not resolve the issue.

Regards,

Mateusz

Answer 4

Hello again Mateusz Wantoch-Rekowski,

Just following up. Your description is sufficient to diagnose a pathing configuration error, though verifying the exact version of the Entra Connect (Azure AD Connect) agent is recommended to ensure full compatibility with the Server 2025 kernel changes.

To resolve Error 206 immediately, launch the Registry Editor and navigate to HKLM\SYSTEM\CurrentControlSet\Services\ADSync. Inspect the ImagePath value; it is imperative that the path is enclosed in double quotes (e.g., "C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe"). If the in-place upgrade stripped these quotes or appended non-printable characters, the service fails to interpret the spaces in "Program Files" correctly. Additionally, audit the System PATH environment variable. Major OS upgrades often concatenate legacy paths, causing the variable to exceed the 4096-character limit, which triggers this specific overflow error during service startup. If validating the quotes and truncating the System PATH does not resolve the issue, the most robust and supported path forward is to export your current configuration and perform a clean reinstall of the agent, as this will correctly re-register the service and its LocalDB dependencies.

If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP

Answer 5

Hello Mateusz Wantoch-Rekowski,

First, you should verify the image path for the ADSync service within the registry. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADSync and examine the ImagePath value. In some upgrade scenarios, this path can become corrupted with redundant quotes or trailing characters that push the string length over the limit. If the path is correct, the bottleneck is often the "Start parameters" or the user profile environment of the service account. Since this works on your second domain controller, compare the ImagePath and any FailureActions registry keys between the two servers to identify discrepancies in the string construction.

Another critical factor is the service account's profile path. If the domain user account running the service has a profile path that was migrated or renamed during the upgrade, the expanded environment variables might be exceeding the character limit. You can attempt to resolve this by temporarily changing the service to run under the Local System account to see if it initializes. If it does, the issue is strictly tied to the profile or environment of that specific domain user. Re-entering the credentials for the service account in the Log On tab of the service properties can often force Windows to re-evaluate and "clean" the execution string in the registry.

Finally, ensure that the bin path C:\Program Files\Microsoft Azure AD Sync\Bin\ isn't duplicated in the system PATH environment variable, as Windows often appends these when launching service executables. If the system PATH is excessively long due to legacy entries from the Server 2016 installation, it can trigger Error 206 when the service attempts to load its dependent DLLs. Cleaning the system environment variables and ensuring the ADSync service path is explicitly and cleanly defined in the registry is the best practice for resolving this post-upgrade state.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP