I am, again, having issues with the WSUS database. After trying a multitude of things, I pulled the SUP off, and unijstalled WSUS. I then rebooted… all good, or so I thought.
The next day, I noted Config Manager node alerts from point of reboot. Yeah, that usual sinking feeling…
- MP Control Manager detected management point is not responding to HTTP requests. The HTTP status code and text is 500, Internal Server Error.
- MP Control Manager detected DMP is not responding to HTTP requests. The http status code and text is 500, Internal Server Error.
I also noted that PCs were having issue with client install (this server is set as the primary MP go to in client install properties – long story… site migration, overlapping boundaries).
So I checked IIS logs and noted error code 500 19 against various websites hosted on the affected server.
- 2017-07-26 23:02:55 22.214.171.124 GET /CRLD/MCRDC01+.crl – 80 – 126.96.36.199 Microsoft-CryptoAPI/6.1 – 500 19 126 1444 292
- 2017-07-26 23:03:05 fe80::d11b:2a19:8094:4bce%12 GET /SMS_MP/.sms_aut MPLIST 443 – fe80::d11b:2a19:8094:4bce%12 SMS_MP_CONTROL_MANAGER – 500 19 126 5333 105
So to troubleshoot this, you need to do two things. We need to trace what component is causing the error, but I could not access the website to view the actual error.The solution? Failed Request Tracing.
There are two elements to consider. Firstly you need to enable FRT on the website. I went to the default website and enabled Failed Request Tracing. It’s as simple as ticking the box; make sure you copy and paste log location and browse to it. It will come in handy later.
The second element! Open the Failed Request Tracing Rules. You can do it on a specific website if preferred, however I did it at the root.
Double click on he icon, and on the right hand side click ADD:
Specify the error code; IIS reported 500 19, so enter it as 500.19:
We will now have an entry under FRTR:
Retry accessing website (or whichever website you set hte rule to monitor! The log location from above is now used; you kept it open right? 😛 It should have XML files in it. Open the file in Internet Explorer and you’ll get something like this:
So now I had the modules, a good error. It also started to fit in with the removal of WSUS. I had noted that the WSUS IIS website was still intact along with the WSUS application files on the C:. Microsoft, why no clean removal?
So I did a quick bit of reserach and I found references to x64 SUS DLLs trying to run in all application spaces, including x86, causing this issue, This would explain the complete failure of all websites in IIS.
This website was very helpful. Scroll down or search using the 0x8007007E code.
The Microsoft spiel:
For above specific error (mentioned in this example), DynamicCompressionModule module is causing the trouble. This is because of the XPress compression scheme module (suscomp.dll) which gets installed with WSUS. Since Compression schemes are defined globally and try to load in every application Pool, it will result in this error when 64bit version of suscomp.dll attempts to load in an application pool which is running in 32bit mode.
…but come on, if it is known why aren’t you doing something about it?
I ran the command stipulated:
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name=’xpress’]
…for an instant success:
- 2017-07-27 11:41:40 188.8.131.52 GET /CRLD/MCRDC01+.crl – 80 – 184.108.40.206 Microsoft-CryptoAPI/6.1 – 500 19 126 1444 220
- 2017-07-27 11:41:51 220.127.116.11 GET /CRLD/MCRDC01+.crl – 80 – 18.104.22.168 Microsoft-CryptoAPI/6.1 – 200 0 0 1089 243
Straight over to 200.0 – marvelous. My IIS FU just went orbital.
Just remember to disable FRTR and remove rule to tidy up 🙂
Time for a bit of World of Tanks to celebrate!