Share via

Server 2019, WSUS MMC Snap-in: Increase timeout?

  • Article

Question

Tuesday, March 19, 2019 8:29 AM

I have a brand new Windows 2019 running a basic WSUS install in a virtual machine with two Xeon 3.5 ghz vCPUs, 8 gig of memory.

It is a fully default WSUS install using the Windows Internal Database SQL server, and the default language and product options. I ran the synchronization. Nothing has been approved, no computers are joined. Everything is working normally.

I am unable to view the synchronization status because the Windows Internal Database SQL engine is taking too long to respond to the MMC snap-in.

How can the snap-in timeout be increased? I have thoroughly searched C:\Program Files\Update Services and I can not find any MMC configuration files where there is a timeout option that can be adjusted.

WSUS for Windows Server 2019 appears to be broken as designed.

,

Steps to reproduce:

1. Open WSUS MMC management snap-in. Open Task Manager, says 0-5% CPU load.

2. Click on Synchronizations in WSUS MMC.

3. It says at bottom "Loading synchronization history, 0% complete"

4. Windows task manager suddenly shows 50% CPU usage across the two vCPU's (really, just 100% load for 1 CPU).

5. After about 5 minutes pass, the MMC snap-in is unhappy and claims it can't reach WSUS. Task manager continues to show 50% CPU usage across the two vCPU's for several more minutes by SQLServr.exe.

6. WID-SQL server eventually finishes whatever it was doing, and Task Manager drops to about 0-5% system load.

7. Can't do anything with the MMC after the internal database has stopped chugging along for 7-10 minutes now. The only option available is to "Reset Server Node," which discards anything that has been retrieved so far. 

8. Go back to Step 2 and do this all over again several more times. No change.

9. Stop VM, increase memory from 8 gb to 16 gb, start VM. This memory increase has no effect. The WSUS MMC still times out trying to load the synchronization history.

,

Is there any way to increase the Server 2019 WSUS MMC snap-in timeout, or am I being indirectly forced by Microsoft to buy a full license for Microsoft SQL Server, because the Windows internal database is too slow and low performance, to respond to the MMC snap-in within 5 minutes?

All replies (13)

Tuesday, March 19, 2019 10:23 AM

Hello

Do you regularly perform WSUS Server Cleanup Wizard (SCW) ?
If not, you should do so monthly.

Do you regularly perform WSUS database maintenance/reindexing?
If not, you should do so monthly.

Do you regularly "Decline" [Expired and Superseded] updates in your WSUS console?
If not, you should do so monthly.

https://technet.microsoft.com/en-us/library/cc708594(v=ws.10).aspx 

This script is the recommended reindex script:
https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

Note that for WSUS v6 (WS2012 / WS2012R2):

When using WSUS 2012 the instructions require a few changes and additions.

--For new server installs, you may need to first download and install:
  1. Microsoft Command Line Utilities 11 for SQL Server:
     http://www.microsoft.com/en-us/download/details.aspx?id=36433
  2. ODBC driver 11 for SQL:
     http://www.microsoft.com/en-us/download/details.aspx?id=36434

--Second, go to the SQLCMD.exe path
cd C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn

--Then run the following command:
SQLCMD -E -S np:\.\pipe\MICROSOFT##WID\tsql\query -i <script location>

"As you can see, *the SQL WID instance name changed in 2012, and the sql changed to tsql. *
No other changes needed, the WSUS 3 maintenance script works just fine."

Also, note this recent article:
http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

Although this article refers to System Center Configuration Manager (which uses WSUS), the issues, instructions, and scripts are directly applicable to WSUS - even when not used with ConfigMgr.

Mark it as answer if your question has solved. MCT Regional Lead. x2 MCSE-MCSA Exchange Server & Windows Server

Wednesday, March 20, 2019 5:16 AM

Hi Dale, 
  

Thank you for posting here.
Based on the situation you mentioned, it is recommended to try the following steps to fix it:
  

  1. Check the status of the application pool running the WSUS service.
    (1)  On your WSUS Server, launch the IIS Manager.
    (2)  Click 'Application Pools' is in the Connections list.
    (3)  Right click 'WsusPool' and select 'Start ' to restart the WSUSPool.
      
  2. Lower memory limits can also cause a situation.
    (1)  On your WSUS Server, launch the IIS Manager.
    (2)  Click 'Application Pools' is in the Connections list.
    (3)  Right click 'WsusPool' and select 'Advanced Settings…'
    (4)  Increase the WsusPool 'Private Memory limit' x4 times, or set to 0 (unlimited).
    (5)  Change 'Queue Length' from the default 1,000 to 25,000.
      

If the above is not suitable for your situation, please let me know.
  

Regards,
Yic

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact

[email protected].

Friday, March 22, 2019 12:29 AM

Nope, it still times out after trying these suggestions.

I am going to test the SQL 2017 Developer version to see if the problem is the lack of performance of the Windows Internal Database SQL.

But WSUS is supposed to work with WID-SQL out of the box without a separate SQL server license.

Possibly the Windows Internal Database SQL is intentionally performance-hobbled by Microsoft in some manner to make it not work properly as the default database for WSUS.

Monday, March 25, 2019 2:04 AM

Hi Dale,
 

The following article describes WSUS timeout errors and maintenance scenarios in several ways, which may help you: "WSUS TIMEOUT ERRORS - WHEN? AND WHY?, ELIMINATING AND AVOIDING"
*Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
 

Hope the above can help you.
 

Regards,
Yic

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

Monday, March 25, 2019 10:41 PM

I have this same problem as WSUS consoles timeouts in about 3 minutes and I have to click Reset Server Node.

Friday, March 29, 2019 5:21 PM

Well, as least I have established that a default install of SQL Server 2017 used with WSUS behaves in the same manner.

  • Install SQL 2017 Developer which creates a default instance for its own use.
  • Make a second instance just for WSUS, use all default settings. No clustering, just basic config.
  • Install WSUS, deselect internal database (auto selected), specify SQL connector.
  • Initial WSUS sync: use default selection of "all Windows products" which includes things I may never use like XP and RT.
  • Select some more stuff, like Driver sets, Updates, Update rollups.
  • Run the initial sync overnight.
  • Next day all is quiet.
  • Close WSUS management, reopen it.

Initial status page:

,

  • Select Synchronization.
  • As with the internal database, the progress meter at the bottom remains at 0%
  • Process monitor shows 50% load, across both CPUs, as with internal database, but it is SQL
  • After about 5 minutes, WSUS console eventually says it lost connection to the WSUS server.
  • Process monitor continues to show 50% load for several minutes after the error appears.



So then, does this behavior continue, if I wait for the load to end? Or will the situation repeat itself?

  • Click Reconnect

  • Click on Synchronizations again.
  • CPU again jumps to 50% load
  • And after about five minutes, it again shows a connection error, while CPU remains at 50% with SQL doing something, for another several minutes.

Well. Although it is not good to see that the problem also occurs with SQL Server 2017, there is one main difference with it vs the Windows Internal SQL Database...

I should be able to run a trace to see what commands are being issued by WSUS to SQL Server 2017, and then perhaps determine what the SQL server is doing that is taking so long, that the MMC times out waiting for it.

Though I am no SQL database expert. I have never done traces before, and I do not know how to only log commands sent to it from a client and the time it takes to complete those commands. I don't want to run a trace in a manner that bogs the SQL down even more with unnecessary tracing detail that I do not need.

Friday, March 29, 2019 6:22 PM

Results of my initial trace attempts shows that SQL Server is taking more than five minutes to complete the following request from WSUS, which is causing the connection error to appear.

,

  • Event Class: RPC:Completed
  • Text Data: exec spSearchUpdates @updateScopeXml=N'<?xml version="1.0" encoding="utf-16"?><UpdateScope ApprovedStates="-1" UpdateTypes="-1" FromArrivalDate="03-29-2019 00:08:14.383" ToArrivalDate="03-29-2019 05:23:01.853" IncludedInstallationStates="-1" ExcludedInstallationStates="0" IsWsusInfrastructureUpdate="0" FromCreationDate="01-01-1753 00:00:00.000" ToCreationDate="12-31-9999 23:59:59.997" UpdateApprovalActions="-1" UpdateSources="1" ExcludeOptionalUpdates="0" />',@preferredCulture=N'en',@apiVersion=204800
  • Application Name: WSUS:ApiRemotingWS:6188
  • NT Username: WSUS$
  • Login Name: FOO\WSUS$
  • CPU: 365641
  • Reads: 85335029
  • Writes: 464
  • Duration: 366939
  • Client Process ID: 6188
  • SPID: 56
  • Start Time: 2019-03-29 12:39:18.910
  • End Time: 2019-03-29 12:45:25.850

So this SQL command took 366.939 seconds to complete .... which is 66.939 seconds longer than the WSUS MMC response time-out.

There are two possible solutions:

  • SQL Server needs to complete this command faster. How? I am no database optimization expert.
  • The WSUS MMC source code needs to be rewritten to intelligently tolerate an SQL response longer than 300 seconds to a command like this.

,

Any suggestions?

Friday, March 29, 2019 9:04 PM

REINDEX the WSUS server using the script from Microsoft and it fixes it sometimes but it is not consistent.

https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

Friday, March 29, 2019 9:21 PM

There has to be a setting in IIS, where we can set the WSUS console time-out to greater than 3 minutes, maybe more like 15 minutes, which would give the SQL server sufficient time to complete the query.

Monday, April 1, 2019 4:55 PM

One option that I have not tried is to build WSUS on a solid state drive. Possibly that will solve the problem because as the SQL trace shows, there were "85 335 029" database reads.

I am attempting to use WSUS in a VMWare 6.5 virtual machine, on a Dell PowerEdge R730 with the H700 SAS RAID-6 controller and a RAID-6 array of 1.2 TB 10k RPM SAS drives.

It is possible that this is the bottleneck, the "enterprise grade, redundancy protected" disk storage is too slow for fast SQL response times.

Monday, April 1, 2019 6:59 PM

My implementation is on a NVMe SSD.  WUSU console timeouts after 3 minutes.

Tuesday, July 30, 2019 5:43 AM

Are there any updates on this from anyone else? Microsoft needs to fix their buggy WSUS console code so it doesn't time out.

It seems the only real fix is to file an official break-fix request with Microsoft's official support which is going to cost several hundred US$, and I am moderately poor and I would prefer to not have to do this. 

I have used the JetBrains .NET decompiler to poke around in the WSUS code and I can pretty much see where the problem is, but it's beyond my skills to actually patch the code and fix this problem..

https://www.jetbrains.com/decompiler/

Thursday, August 8, 2019 5:29 AM

I'm using 2019 and I have no issues (using WID).

https://www.ajtek.ca/wsus/wsus-system-requirements-what-should-i-plan-for/

See my notes on WID in part 1 of my 8 part blog series (where I recommend it over SQL Express)

https://www.ajtek.ca/wsus/how-to-setup-manage-and-maintain-wsus-part-1-choosing-your-server-os/

Adam Marshall, MCSE: Security
https://www.ajtek.ca
Microsoft MVP - Windows and Devices for IT