WSUS Integrated, BatchPatch still "Searches" for 6+ hours for downloaded updates

[Mordanthanus]

Hello all,

I am evaluating BatchPatch, making sure it will improve our process before selling to the management team. We use a WSUS server, and the machines are set to download the updates (per this post – batchpatch-integration-with-wsus-and-group-policy) and wait for me to initiate install via the “BatchPatch Actions > Windows Updates > Install downloaded updates” option. Even though I am telling it to install downloaded updates, BatchPatch still initiates the “Searching” function and sits for hours. Out of 40 or so machines, 8 actually installed updates after about 3.5 hours. I ended up cancelling the rest after 6 hours as they never left the searching stage (production was starting back up). I did verify that the client was running on multiple machines, so the process appears to be working, just not fast enough.

I don’t understand why it is searching for updates if they are already downloaded. If I remote to the machine directly, I can initiate the install and it just installs downloaded updates and takes 10 minutes tops.

Any help with this issue would be greatly appreciated. We currently manually install pushed updated each month manually via RDP to over 200 machines. Showing management we can do them all in roughly 20 minutes would be an immediate sell.

Thanks.

[doug]

When you perform ‘Install downloaded updates’ in BP, the ‘Searching’ that you see take place occurs because before we can install updates we have to search for updates that have already been downloaded to the computer. This is actually an offline search that doesn’t reach out to WSUS or Windows Update, and normally this search should be quick, but it seems that something might have changed with Windows Updates this month because we did hear of one other customer (so far) who experienced very slow searching on Windows 2012 R2 targets this month too, similar to what you experienced.

Starting about 2 years ago, Windows 7 targets began to experience very slow search for updates. You can find discussions about this all over internet forums, and you can read our posting about it here: Checking for Available Windows Updates on Windows 7 Targets Takes Too Long

The aforementioned issue was not specific to BatchPatch usage, but rather was just slow searching for Windows Updates, regardless of the method used to perform the updates search/download/install. They claimed the issue was related to supersedence rule chain processing, which is why one of the characteristics is that svchost.exe consumes a lot of CPU while the search is taking place. That issue was resolved a couple of months ago (after plaguing users for the better part of 2 years) for Windows 7 targets, but now the behavior seems to be the same this month for at least some people with Windows 2012 R2. I would expect that if you checked the CPU usage during the search that you too would see svchost.exe consuming a lot of CPU resources while the search is being performed.

What we saw in the WindowsUpdate.log file for the one customer who reported slowness this month was that even for AutomaticUpdates, the search was also very slow. However, I think it seems fast when you do the action at the Windows Update control panel GUI directly on the target computer because Microsoft is utilizing some sort of caching, such that when you go to install the updates at the panel, the slow search was already performed behind the scenes, and so all you end up seeing is the download/install going pretty quickly.

Ultimately the issue is not something that we really have any control over since it’s tied to the Windows Update Agent and not to BP specifically, but we are researching and testing now to see if we can reproduce it or learn any more about what is really going on here. I will post here with any updates, and I predict that we will probably also end up posting about it in the BP blog at some point too.

-Doug

[Author]

Posts