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

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..........

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.

Just out of curiosity, why would an update that is approved but not downloaded cause the client to have high cpu usage?

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.

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.

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.

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.

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.

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 .......

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.

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.