Exchange Server Setup fails with DependentAssemblyGenerator.exe error.

Last week I was updating one of my customer’s Exchange 2016 Servers to CU19. Usually this is a rather simple and straightforward task, which normally takes between 1 and N hours. That of course, only as long as nothing goes wrong….

While this update was approaching step 17 of 18, the message “Microsoft Exchange stopped working” appeared, and with it, the setup failed. The detailed error looked like this:

This looked quite shocking at first (given that in this situation, I was updating a single-node Exchange organisation), but a little research quickly showed, that this problem’s solution is rather simple.

The cause

The full error message is already telling us very directly what happened: It began with:

Error:
The following error was generated when "$error.Clear(); 
          $dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, "bin", "DependentAssemblyGenerator.exe");
          $exchangeBinPath  = [System.IO.Path]::Combine($RoleInstallPath, "bin");
          $clientAccessPath = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess");
          $sharedWebConfig  = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess", "SharedWebConfig.config");

          $a = &"$dependentAssemblyGeneratorExePath" -exchangePath "$exchangeBinPath" -exchangePath "$clientAccessPath" -configFile "$sharedWebConfig";
          $allOutput = @();
          $a | % { $allOutput += $_ };
          Write-ExchangeSetupLog -Info ($allOutput -join "`r`n");
          Stop-SetupService -ServiceName WAS;
          Start-SetupService -ServiceName W3SVC;
        " was run: "System.Management.Automation.RemoteException".

And further down continued with:

Error:
The following error was generated when "$error.Clear(); 
          $dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, "bin", "DependentAssemblyGenerator.exe");
          $exchangeBinPath  = [System.IO.Path]::Combine($RoleInstallPath, "bin");
          $clientAccessPath = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess");
          $sharedWebConfig  = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess", "SharedWebConfig.config");

          $a = &"$dependentAssemblyGeneratorExePath" -exchangePath "$exchangeBinPath" -exchangePath "$clientAccessPath" -configFile "$sharedWebConfig";
          $allOutput = @();
          $a | % { $allOutput += $_ };
          Write-ExchangeSetupLog -Info ($allOutput -join "`r`n");
          Stop-SetupService -ServiceName WAS;
          Start-SetupService -ServiceName W3SVC;
        " was run: "System.Management.Automation.RemoteException: System.UnauthorizedAccessException: Access to the path "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\SharedWebConfig.config" is denied.
   bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   bei System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   bei System.Xml.XmlDocument.Save(String filename)
   bei Microsoft.Exchange.Management.DependentAssemblyGenerator.UpdateConfigFile(String configFilePath, IList`1 exchangeAssemblies, Int32& numAssembliesAdded)

So from what we can get from this we can safely assume, that a program called DependentAssemblyGenerator.exe has been denied access to a config file called SharedWebConfig.config in the ClientAccess folder of the Exchange installation.

This could have been caused by the antivirus software, or some corrupt folder permissions. I didn’t find that out in the end, but the problem cam be fixed easily:

What is DependentAssemblyGenerator.exe?

The DependentAssemblyGenerator.exe is a tool that Exchange Server uses to create a config file including all assemblies used under a given Exchange installation path.

The solution

There are usually two places inside an Exchange installation that have a SharedWebConfig.config file within them. One is

"%ExchangeInstallPath%\ClientAccess\SharedWebConfig.config"

and the second one can be found at

"%ExchangeInstallPath%\FrontEnd\HttpProxy\SharedWebConfig.config".

While searching for the file inside the ClientAccess folder, I noticed that it was completely gone.

One possible and very simple solution is, to copy this file from another Exchange Server within the same organization and to re-run the setup. Yep, it’s that simple!

In my case though, it was a single node Exchange installation. So what to do here? Well, we’ll just generate this file anew. Actually, we just run the command that the Exchange setup wanted to run ourselves. I found some information on how to do that here. Open an elevated PowerShell and enter:

cd %ExchangeInstallPath%\bin

DependentAssemblyGenerator.exe -exchangePath "%ExchangeInstallPath%\bin" -exchangePath "%ExchangeInstallPath%\ClientAccess" -configFile "%ExchangeInstallPath%\ClientAccess\SharedWebConfig.config"

iisreset

After this, the file should be re-generated. You can safely take your Exchange Server out of maintenance now, because after this, the Exchange Setup is officially finished.

Summary

Because of a simple file access problem, Exchange setup couldn’t finish its very last step. Luckily we could do this last step ourselves, and the problem was solved. What a relief 🙂

Further reading:

I was facing an additional small problem with taking the Exchange Server out of maintenance, after the above situation happened. I wrote another article on how to solve this. You can find it here:

ServerComponentState cannot be changed to Active after Exchange Server Maintenance