So I am having a bit of fun with finally getting round to migrating to Current Branch. there are a lot of cool new features, which tbh, I probably don’t need but I am like a child in a sweet shop!
I noted that we have a new log called DeltaDownload – it was just sat there humming quietly to itself though. Little did I know it was about to unleash hell.
I managed to start testing this month’s software update release on the Current Branch servers, with my alpha test group. Everything was rolling along fine. to my delight, i noticed that the DeltaDownload.log was finally doing something:
…but, true to form. It was not quite right. It took *hours* for the delta download to run. it got to 1830, Friday night, so I was off home. I had plans for the evening!
Come Monday morning, I return to my terminal server session, but every, and I mean every active PC that had been migrated to Current Branch, had their WUAHANDLER.log splatered with red.
OnSearchComplete – Failed to end search job. Error = 0x80244022.
So, every PC… after returning from a sudden and unexpected bathroom run, I took a look at the WSUS server. I couldn’t open the snap in. The standard event logs were not happy either.
component SMS_WSUS_CONTROL_MANAGER on computer **SNIP** reported: WSUS Control Manager failed to configure proxy settings on WSUS Server “**SNIP**”.
Possible cause: WSUS Server version 3.0 SP2 or above is not installed or cannot be contacted.
Solution: Verify that the WSUS Server version 3.0 SP2 or greater is installed. Verify that the IIS ports configured in the site are same as those configured on the WSUS IIS website.You can receive failure because proxy is set but proxy name is not specified or proxy server port is invalid.
Additionally, every WSUS IIS element was reporting an error, as per the screenshot above. I am now starting to think this is something IIS/WSUS related. Interestingly, the errors started around the time ONE of my test PCs went active with a Delta Download. Purely a coincidence I hear you say. Yes.
Config Manager was equally unhappy, but again, it was pointing at an inability to communicate with WSUS on the server.
WSUS Control Manager failed to monitor WSUS Server “**SNIP**”.
So I dive into IIS. To my surprise I found that the WSUS Application Pool was stopped:
I started the WSUSPool, but it just failed again. I did some more digging, and found this rather fabulous explanation here. Basically, the memory limit default is around 1.7GB, and it isn’t enough!
In a nutshell:
- Select the WsusPool from the list under Application Pools
- Right click and select Advanced Settings
- Scroll to the bottom to Private Memory Limit (KB)
- Amend the value to something appropriate to your needs
I set my value to 8GB. I kickstarted the WsusPool, and thus far, everything is good. Obviously I would not recommend setting it higher than the memory limit on the server. Cos you know… stupid is as stupid does 😛
I do worry what will happen when we have one hundred or one thousand Windows 10 PCs hitting WSUS for the DeltaDownload. Having one PC seems to have brought down my house of cards…
Perhaps it’s just an initial hit, as you’d need the main file plus delta file changes and it’ll be a one-off per PC – which is in itself troubling.
Or perhaps increasing the memory pool will fix it period.
Time will tell.
What is very worrying is that over the course of the weekend, no anti-virus definitions went out. We’re integrated into SCEP; I do personally love it, and the integration of information into the Config Manager console. However having WSUS syncs fail, and the only clue being an email stating a failure out of hours… well scary times! Obviously that’s a resourcing issue for where I work but still. It shows the problems of integrating – not that I’d change it mind.
Either way, changing the memory limit and starting the application pool was an instant fix.