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 : https://support.microsoft.com/en-us/kb/942055
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.
I hope this post helped you,
Dont’ hesitate to comment, like or rate,
Your host,
You can always reach me here:
You can always reach me here:
itpassionate 
Thank you for this posting. Today I had exactly the same situation as you, W2016 server with Exchange 2016 and WSUS. I uninstalled WSUS and then I had the same problem. In my case the uninstaller also did not remove the WSUS site in the IIS.
LikeLiked by 1 person
This worked thanks
LikeLike