Troubleshooting IIS after removing WSUS Role on a Windows 2012 Server

Several months ago, for one of my customers, I needed to remove the WSUS role from a server where AD and Exchange role were also configured (Windows 2012 + Exchange 2013). I agree with you, this is not an optimal scenario, but when the budget come into place…
Once I rebooted the server after removing WSUS role, any HTTPS connection to Exchange AppPool in IIS was impossible. This means that any ActiveSync sync, any request to the OWA, any request to the ECP in an error 500 at IIS.
This is the worst error because your browser is unable by default to return you an error code more detailed about the issue that could put you on a track.
After much research, I enabled debugging and I read more consistent IIS logs. These logs in matters related to me the error 500.19. Ahhh !!! Finally a track.
To get more details on this error 500.19, I launched an HTTPS connection on the same server and here’s what it returned me:

IIS is constructed in the following manner:

The default web content: C:\inetpub\wwwroot
The IIS Engine: C:\%windir%\ system32\Inetsrv\
The global configuration file: C:\% windir%\system32\inetsrv\config\ ApplicationHost.config (regains all your IIS configuration)
The websites hosted configuration file:%PhysicalPath_website%\web.config (specific configuration website)
The AppPool related to hosted website:%PhysicalPath% AppPool (the AppPools load the complementary modules in IIS and for the proper functioning of Apps-There are AppPools as for SMEX Trend, Exchange, and many others.)

According to the error returned, the problem could come from two main files:

• The web.config Site
• The ApplicationHost.config


To ogo further in the dignostic, I based my investigations on the following points:


With this page, I knew which module was the guilty one. With the error code returned by the webpage, I was able to define the origin of the issue with my friend Google 🙂

I could find what I was looking for via this website :



The “web.config” file being very limited with its content, It was an evidence for me that there wasn’t any references to the « DynamicCompression » module. So, I edited the file “ApplicationHost.config” file and I started a search on the concerned module.

Bingo !!!!

Here the guilty line. The one that gave me headaches!

<scheme name=”xpress” doStaticCompression=”false” doDynamicCompression=”true” dll=”C:\Program Files\Update Services\WebServices\suscomp.dll” staticCompressionLevel=”10″ dynamicCompressionLevel=”0″ />

The Exchange website and all its loaded modules called a DLL file that was not there anymore.

After deleting this line, saving the modifications in “ApplicationHost.config” and finally applying an “IISreset” command, everything came back!


 So, if you are in a similar scenario than me, Exchange 2013 that is no more functional after removing WSUS role on the server, take a in the “ApplicationHost.config” file and check any references related to WSUS.