Click on the Category button to get more articles regarding that product.
Event ID 7053,12072,12052,12042,12012,13042 on WSUS Server
ERROR:
Unable to open WSUS MMC or connect with Script/PS/Tools to the WSUS database. On Clients or Server your see an error when this happens because, the WSUS APP Pool on IIS is down.
What is the problem?
If this happens you will after a reboot of the server loose most of the APPROVAL or DENY on your WSUS backwards for years.
Solution:
Mostly 90% related to RAM memory the WSUS has and the Application POOL WSUS itself or you run out of space on your WSUS content drive.
Prelude:
In the past months, all long-time, running WSUS Server no matter on which OS they run seem to crash more often they did before. We first long time watched and thought this was related sporadic too:
- Multi usage of MMC Console (Several users checking WSUS)
- Space on D: drive (With all the Feature Update you are up to 1 Terra soon)
- Script, which we had running to maintain WSUS or best Clean up WSUS automatic after it, crashed again (Deny 12’000 Patches…)
- We also assumed it is caused by a mix of WID (Windows Intern DB/Different Version of SQL Express or STD > we updated some mixed used WSUS + EPO 5.10 to sql 2017)
- As always maybe AV Solutions, which pinpoint. But we use Mcafee ENS Endpoint with many Exceptions and it never blocked SQL or WID when configured right and not by beginners
None of that seemed the source of the problem.
It looks like the crashed are more often to memory handling of IIS Application Pools and total memory the HOST (VM) has.
Here are the errors we did see:
| Event ID 7053, Application |
| The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists,
Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.
System.NullReferenceException — Object reference not set to an instance of an object.
Source: Microsoft.UpdateServices.UI.SnapIn
Stack Trace: at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ResetScopeNode() |
| Event ID 12072/12052/12042/12012/13042, Application, Windows Server Update Services |
| The Server Synchronization Web Service is not working. |
| The WSUS content directory is not accessible.
System.Net.WebException: The remote server returned an error: (503) Server Unavailable. at System.Net.HttpWebRequest.GetResponse() at Microsoft.UpdateServices.Internal.HealthMonitoring.HmtWebServices.CheckContentDirWebAccess(EventLoggingType type, HealthEventLogger logger) |
 |
| The DSS Authentication Web Service is not working. |
| Self-update is not working. |
| The Reporting Web Service is not working. |
| The API Remoting Web Service is not working. |
| Event ID 10016, SYSTEM, DistributedCOM |
 |
Solution:
- Give the HOST on ESX/Hypervisor more memory. You could trace for hours to find out how much or you be smart and give it 16-20 GB RAM. It depends on history of WSUS (Like running for 5 years, amount of clients or patches, how you clean up the WSUS with Tools or scripts via SQL query).
- Open IIS, Application Pools, WSUSPOOL, Advanced Settings, Change the “Private Memory Limit KB” to something under your ESX Memory you gave. (In our example the IIS APP process runs around 14GB RAM and we gave the Server 18GB)
- Reboot and all works again
You can now see how much Memory the IIS APP poll is consuming on a larger WSUS with a lot of history over years (Lot of WID/SQL data…)
