WSUS Windows 2008 R2 clients high CPU when updates are approved and ready

The last few months when I approve updates in WSUS, the clients on Windows 2008 R2 seem to have continuous cycles of 100% CPU usage, I assume beings when they are checking in with WSUS.  The applications running on the server struggle when this happens many times each day.  If I move the Windows 2008 R2 clients to a different computer group that has no updates approved, this all stops.  It seems that when there are updates waiting on WSUS, the Windows 2008 R2 clients experience this.  This does not seem to be the case with Windows 2012 R2 clients.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

clients meaning the RDS users? Or are you talking about when you approve the updates, the transfers of update files begin immediately impacting the network, performance of the server.

What is our GPO setting for frequency of update checks?

WSUS is a PULL technology, each client has to connect and check/report to identify from what is available what they need. and Download what has been approved for install.

You might be mixing coincidence with causation.
Try approving updates off-peak before you leave versus when you come in.

Configure auto-approval for Critical/security level updates as well as make sure the product selections are narrow to only cover what you have in the environment.

With the above, make sure your server update settings are to download and notify as to avoid an update being downloaded and installed..........
jpletcher1Author Commented:
When our Windows 2008 R2 clients see that the WSUS server that they get their client updates from, they have high CPU for say 5-10 minutes.  This goes on many times a day for each server and I get alerts.  It's not impacting the network, just the clients, and only Windows 2008 R2 clients.  And it goes on everyday until I actually install the updates, so it's not like just the initial pull or detection.
Double check your GPO pushing windows update settings to make sure it is not setting the clients to check with the WSUS server too frequently.
Usually check every 24 hours or even 12 hours is ok, more frequently could pose this issue that an update is reflected as approved, but the files have not been downloaded.
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

jpletcher1Author Commented:
Just out of curiosity, why would an update that is approved but not downloaded cause the client to have high cpu usage?
It has to be confirmed that the high cpu is actually being caused as you think by the availability of updates versus something else.
My suggestions are based on your conclusion that approved update/cpu on client spikes.

i.e. when wuauclt runs, the cpu spikes as it triggers the BITS service to start. IT gets a listing of available/approved.  IT then tries to download the files..

What is your environment made of? Do you have SCCM in the environment that actually pushes/triggers client updates?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jpletcher1Author Commented:
We do not have SCCM, just WSUS.  I notice when the client machines hit 100% CPU, it's the svhost process that uses the CPU.  If I move the clients back to the old WSUS server, the problem goes away.
Look at the windowsupdatel.log file what is going on.
The assortment of items offered on the old and the new might relate to the system having to check all available on the new as it ...........
Make sure that the systems can actually access the data and are not running into trouble leading to the CPU spike.
jpletcher1Author Commented:
I didn't see anything in the logs that stood out.  Again here is my case just to be clear.

Old WSUS server on Windows 2008 R2.  
New WSUS server on Windows 2012 R2

Windows 2012 R2 clients report to the new WSUS server fine.
Windows 2008 R2 client report to the new WSUS server and experience times of 100% CPU usage WHEN THEY ARE IN A WSUS GROUP THAT HAS UPDATES APPROVED FOR THEM.  If I move them to an empty group on this WSUS server where no updates are approved, there is no issue.

I believe the Windows 7 clients have the same behavior as the Windows 2008 R2 clients.
jpletcher1Author Commented:
Once I installed all the patches to the servers from the new WSUS server the CPU issue went away.  I'm curious as I approve the next month's patches, but don't install them yet, if the issue will surface again.
How frequently are the workstation set via GPO to check for updates?
I've not seen this behavior, though the settings are to check every 24 hours.
jpletcher1Author Commented:
It is set to check every 4 hours.
Why check so frequently?  The issue if it checks that frequently but the updates are unavailable for downloads.
MS does not release updates on that frequency nor do you approve updates for install on that frequency.
Usually, the check is once every 24 hours.  Having it check once every 12 which I often setup to catch my mid-day approval, every 4hours is too frequent and unnecessary.
jpletcher1Author Commented:
I can understand that, but it's always been set to 4 hours and was never a problem until moving to this new Windows 2012 WSUS.  I think the default is 4 hours.  I agree that it could be set to much less frequently, but I think that would mean it would hit 100% CPU less often, not fix my issue.
jpletcher1Author Commented:
Also a FYI - the largest detection frequency you can set is 22 hours.  Anything over that and you are warned and it sets it to 22 hours.
Yes, rechecked 22 is the max.  Time set is plus or minus 4 hours.
example given if you set it to 20 it will be checked between 16 and 20.  setting it to 4 could be interpreted as the detection possibility could be between 0 and 4.  if it selects 0 sequentially it might mean that it is trying to run multiple detection attempts at the same time.

Use less frequent settings and see if the 100% cpu use by svchost .......
jpletcher1Author Commented:
I just approved updates for this month and I am going to let them sit in waiting for a while.  I'll report back in a few days.
jpletcher1Author Commented:
Well the problem seemed to go away now.  I'm not sure if the clients being moved over to the new server just took time to rescan and populate what they already had installed or what.  I'm just glad it's working now.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.