Stupid WSUS question

[penfold]

It's been a very long time since I did any WSUS tasks and I have just taken over the management of it in my new job. From what I can see it has been installed and setup as they went along. Stupid question time - As there are old clients in the WSUS console which have not contacted the server for a long time, I want to run the server cleanup and remove old updates, clients etc. I have read that for the first time run it should be done at the weekend, and I'm guessing that I need to create a scheduled task to start it? If I want to run this as a schedule is there some consideration I need know?

[kennysarmy]

Why not just kick it off when you leave on Friday?

[penfold]

This is what I am thinking. But as I can't see it ever running, I'm just asking if there is anything to be aware of before I run it this weekend

[LeMarchand]

If it's never been run, chances are it will fail. I tend to find that unless run regularly it fails on the first stage.

 

Have a search around - there are ways to mitigate against this like increasing things in IIS and there is a (now paid) script method. At one place I even started from scratch!

Edited January 14, 2021 by LeMarchand

[penfold]

Yeah, I read about fails & the script on another thread here. I haven't been through the best practice setting for IIS yet, that is on my to do list for tomorrow. For the time being we need to get the numbers we have in WSUS to be accurate. I'm just thinking if it is worth manually deleting old systems and then running the cleanup? Or is that not recommended?

[LeMarchand]

Yeah, I read about fails & the script on another thread here. I haven't been through the best practice setting for IIS yet, that is on my to do list for tomorrow. For the time being we need to get the numbers we have in WSUS to be accurate. I'm just thinking if it is worth manually deleting old systems and then running the cleanup? Or is that not recommended?

 

Deleting old systems has never been something I've considered, I'm afraid. Too many machines only get used sporadically; I even untick that option! Don't know if it's frowned upon, but I have occasionally manually cleaned off some old machines.

[DavR]

I tend to be pretty active in managing my computer lists in WSUS (probably overly so), I manually delete computer entries all the time if I know they've been removed, this is no biggie. You could even wipe all computers off if you wanted to, and allow them to re-register, although that will delete evidence about machines that have been offline / are having trouble connecting, which you may want to troubleshoot.

 

If it were me taking over someone else's WSUS, I might be inclined to just wipe the whole thing and start again. I've recently installed a new WSUS server because the old one got very bloated and untidy, and Server Cleanup Wizard is next to useless. The AJ Tek script that often gets mentioned is good, but alas, now a paid product.

[kennysarmy]

Here is a good little bit of code to force clients to talk back in !

 

gpupdate /force

$updateSession = new-object -com "Microsoft.Update.Session"; $updates=$updateSession.CreateupdateSearcher().Search($criteria).Updates

wuauclt /reportnow

[DaveTheTech]

You can run the wsus clean up wizard from a command line, so it could be scheduled.

I have run it during the day and often find the wizard fails, but the powershell continues to run.

 

The main thing to do is to only look for updates that are needed and to decline any that have been succeeded

[PyROm]

To fix WSUS cleanup failing on first run (and if not run for a while) I followed the instructions on this page https://www.terminalworks.com/blog/post/2017/10/07/sccm-update-deployment-failing-with-wsus-errors-and-high-system-utilization , I believe it was the asp.net in web.config that made the biggest difference to me, until doing this the command line cleanup failed for me as well.

[penfold]

Here is a good little bit of code to force clients to talk back in !

 

gpupdate /force

$updateSession = new-object -com "Microsoft.Update.Session"; $updates=$updateSession.CreateupdateSearcher().Search($criteria).Updates

wuauclt /reportnow

I've ran this command and for 1 client it worked. For the other one it seemed to work, but it still shows an old report status in WSUS. If I check the log on the client I can see that the following status

<>: wsmprovhost.exe Success Pre-Deployment Check Reporting client status.

 

But the thing is, this is listed in the logs before. So it looks like updates are working, but it is not reporting to WSUS. Now I know there is google, but I'm being asked to do lots of different tasks at the same time so would really appreciate it if anyone could point me in the right direction to start it may save me lots of searching

[PyROm]

If the computer is showing in WSUS but has never returned a status (ever, it will say it is running windows 0.0 from memory), and this is happening for computers from a specific batch or model rather then all of them, then it could be it has a bad description string in the bios, e.g. invalid characters in the manufacturer/model name/serial that is stored on PC bios. I had this and it took me ages to track down as it doesn't really log anything. Edited January 15, 2021 by PyROm

[sigma]

Here is a good little bit of code to force clients to talk back in !

 

gpupdate /force

$updateSession = new-object -com "Microsoft.Update.Session"; $updates=$updateSession.CreateupdateSearcher().Search($criteria).Updates

wuauclt /reportnow

 

Or at an elevated command prompt:

 

wuauclt /resetauthorization /detectnow

wuauclt /reportnow

[penfold]

OK, I'm doing some troubleshooting here and I can see that the logs on some clients are showing that updates are downloading and even attempting to install. But on the WSUS server itself the system is still showing with an old Last Status report. I've run the PS command here and tried to force it to connect (which is does) but I don't see any errors showing.

 

I've checked the ReportingEvents file under the SoftwareDistribution folder and also the events under Event Viewer\Application & Services\Microsoft\Windows\WindowsUpdate but I just see successful entries for finding updates. Where should I start to look into why it is not reporting into WSUS properly?

[PyROm]

Have you tried deleting the computer out of WSUS and seeing if it gets re-created when you run windows update again? maybe the entry got corrupt/confused and so doesn't update computers record.

[DavR]

Yup, first step I would take is delete the computer in WSUS, then re-register with wuauclt /resetauthorization /detectnow

[PyROm]

There is mixed information out there, but some suggest that wuauclt isn't working on newer versions of windows 10 and to use USOClient instead, from what I can tell this is just to do with triggering Windows update and has no effect on the update process if it manages to trigger it. USOClient commands half way down this page. https://www.idkrtm.com/windows-update-commands/#:~:text=The%20windows%20update%20command%20utility,windows%207%20and%20server%202012R2.

[DavR]

There is mixed information out there, but some suggest that wuauclt isn't working on newer versions of windows 10 and to use USOClient instead, from what I can tell this is just to do with triggering Windows update and has no effect on the update process if it manages to trigger it. USOClient commands half way down this page. https://www.idkrtm.com/windows-update-commands/#:~:text=The%20windows%20update%20command%20utility,windows%207%20and%20server%202012R2.

 

Wuauclt is partly deprecated on Windows 10 I think, but I'm pretty sure that command still works, specifically for re-registering computers with the WSUS server.

 

Usoclient StartInteractiveScan is now the best / quickest way to start a new download and install of updates though, agreed.

[googlemad]

As mentioned I would highly recommend looking at AJTek WSUS Automated Maintenance, I'm sure even on a tight school budget they can find $60/year down the back of a sofa!

 

https://www.ajtek.ca/

 

But I get the feeling Microsoft have quietly left WSUS to just silently die in the background, we now use ManageEngine Patch Manager Plus but I think that comes in at £££££

 

At least with Windows 10 you generally just get a single cumulative update each month rather than 1,000,000 individual patches from the Windows 7 days!

[penfold]

I will look to delete the account and re-register. The thing is WSUS is working, the problem is generating any report. Because the system is not updating in WSUS we cannot see if the updates are being applied or not. Checking the client locally shows that it is downloading and trying to install, but I need to be able to generate reliable reports. So far I am getting really poor success rate because so many systems are reporting as unknown.

@googlemad - there will be no looking at any other solution as it is currently working. What we have are lots of machines which are not updating their status in WSUS so we have a lot of old entries which are a mix of old systems and problem systems. I'm trying to go through and get all the live systems to connect properly & delete the old systems. If I delete all old entries I will end up deleting lots of systems which I need to troubleshoot why they are not reporting into WSUS.

[penfold]

Here is a good little bit of code to force clients to talk back in !

 

gpupdate /force

$updateSession = new-object -com "Microsoft.Update.Session"; $updates=$updateSession.CreateupdateSearcher().Search($criteria).Updates

wuauclt /reportnow

Where do $updates and $criteria and there values from? Is this generated during the $updatesession or I should be passing something here?

[penfold]

I think we have found out why there are a large number of clients not connecting. It seems that we can run a force check in with WSUS using the script here, but it errors with a time out exceeded max round trips. If we run this command a few times it will succeed. I haven't yet changed the WSUS server settings to best practice and can see that we have what looks like default settings. Before I make any changes on the WSUS Server I wanted to check the IIS logs to see if there was anything in there which indicated timeouts from clients. Unfortunately there is no Logging icon as it looks like the Health & Diagnostics feature has not been added under the WebServer (IIS) role.

 

I wanted to check the Server logs here, but am I looking in the wrong place? Is this not required for WSUS monitoring & troubleshooting? I basically wanted to check server side to see if I can see lots of timeouts of clients which I think may be an issue at the minute.

[kennysarmy]

Where do $updates and $criteria and there values from? Is this generated during the $updatesession or I should be passing something here?

 

Should just be a copy and paste of my text and run it

[penfold]

Should just be a copy and paste of my text and run it

 

Yeah, I did that and I am getting them connected....I was just wondering

 

The only outstanding issue I have now is to see if I should enable logging on the WSUS Server? So far I have run the script remotely against servers and it possible to get them reconnected. But as it looks like some are timing out I still need to make some changes in IIS. Is it worth enabling IIS logging so it can be used to check if there are systems trying to connect but failing?

[penfold]

OK, Quick update and another question on this. We have now got WSUS into a place were it is working and clients are connecting OK(mostly) But, I can't find out an answer for this....when a clients checks for updates, does it only scan against approved updates in WSUS?

 

We have some clients that are timing out when scanning for updates and I think will be fixed by declining update. At the minute we have updates which are showing as needed by a handful of clients so I cannot decline them yet. Will it make any difference to decline updates not yet approved or required? Or scanning times will only be reduced by declining approved updates now longer needed?