locked
Check for updates takes 30 minutes on Windows 2008 R2 SP1 servers RRS feed

  • Question

  • We patch every month our servers as soon as they come out. In our environment we have Windows 2003, Windows 2008 R2 Sp1 and Windows 2012 servers. The problem is only present on Windows 2008 servers and the problem is that checking for updates takes a long time (20 to 40 minutes). When it happens the svchost (netsvcs) process is using 1 CPU, has high mem usage and according to windowsupdates.log is in its "PT: Synchronizing extended update info" phase. We used procmon to analyse what the process is doing, but it doesn't seem to do a lot. We have tight patching windows so these long times cause problems for us. Any advise on how to speed this process up (e.g back to 2, 3 minutes what it used to be and what it is on Windows 2012)?

    Friday, August 14, 2015 8:24 AM

Answers

  • We've figured out the issue. 

    This month patches for Windows 2008 contained patches that supersede many, many other patches. So there is nothing wrong with the WSUS server or Windows Update agent. It just takes long because it checks all the superseded patches. 

    Our engineers regularly run the WSUS cleanup wizard but that only cleans superseded EXPIRED patches. First we had to decline all those patches that were superseded manually and then run the WSUS cleanup wizard. 

    This article pointed me in the right direction: https://thwack.solarwinds.com/community/application-and-server_tht/patchzone/blog/2013/01/21/wsus-timeout-errors--removing-unneeded-update-approvals

    After that had been executed, checking for updates was within 2 minutes again.



    • Edited by Marcel Campo Tuesday, August 18, 2015 7:34 AM
    • Marked as answer by Marcel Campo Tuesday, August 18, 2015 7:34 AM
    Tuesday, August 18, 2015 7:33 AM

All replies

  • you're using WSUS or going out to the internet for the updates?

    older OSes will just simply take longer to check for updates as they have a lot of component updates to sort through locally, then against the wsus server in order to determine what needs to be updated. take into account updates for each role/feature you have installed, updates for IE, updates for .NET and so on.

    2012 doesn't have that issue right now because it's a fairly new OS and I also believe it has a more intuitive client update agent code compared to the older OSes

    2003 barely gets any new updates anymore so it doesn't have a whole lot to check

    the more cpu, memory, disk performance and network bandwidth you have between the client/server, the faster the process will complete. I have really beefy 2008 R2 servers (128GB RAM) and they can check within 5mins vs. servers running on much slower disk and CPU with less RAM (8GB) and they take around 30mins like you mentioned

    the only thing you can do is ensure you have the latest SP installed but unfortunately MS has not been releasing a lot of SPs for Windows lately as they're trying to move away from that update model

    if you're using WSUS, you can patch it to the latest version which will push down the latest windows update agent to all the endpoints and that may help a bit. if you're using the internet to pull down updates then you know it's going to be slow even during the checking phase

    I understand you want updates to go out quickly after they're released but checking updates may not need to be part of your update window.  you can set intervals on how often servers check for updates or use a remote script to trigger the update checking procedure a few hours before your patching window using wuauclt /detectnow command

    Friday, August 14, 2015 1:56 PM
  • We use WSUS.

    I understand that different OS versions will have different results. The delays we have we see only with our Windows 2008 R2 SP1 clients. The delays are so long that it causes problems for us and I believe the delays were not that long in our previous patch rounds. Because we patch every month our systems do have the latest patches.

    We have our internal developped scripts that manage the patching. Sometimes WSUS patches need reboots before all patches can be installed and therefore we are using /detectnow  in our scripts. Next to that the scripts do failover actions before and after the patching. So we need the /detectnow to take only a few minutes max, not 30 minutes or more.

    So it didn't use to take that long and now it does. So I am now considering a support ticket to have Microsoft investigate if there is something particular in our environment that causes this issue or if it still 'works-as-designed', which imho is not acceptable.

    Monday, August 17, 2015 6:46 AM
  • Hi,

    We noticed the exact same issue during the weekend.   Search for updates now takes 40 minutes when the same server took around 2 minutes during previous months.   It is not related to number of patches as previous month was 9 patches versus 10 this month.

    This appears to be limited to pre 2012 servers.

    I'm currently in the process of gathering evidence on this problem.   I suspect one of the updates rolled out in August has caused the issue.  I have noticed updates were applied to our WSUS server prior to our patching weekend so I'm starting there.

    Best regards,

    Blair.

    Monday, August 17, 2015 7:20 AM
  • May be related to: https://social.technet.microsoft.com/Forums/windowsserver/en-US/de146464-6e97-43d4-a86a-e2bb34398c3f/august-update-partially-breaks-wsus?forum=winserverwsus
    Monday, August 17, 2015 7:26 AM
  • what version of WSUS are you running?

    if it's 3.0 SP2, install the following patches on the WSUS server:

    https://support.microsoft.com/en-us/kb/2734608

    https://support.microsoft.com/en-au/kb/2938066

    if it's 6.2/6.3, install just this one:

    https://support.microsoft.com/en-au/kb/2938066

    Monday, August 17, 2015 12:29 PM
  • We've figured out the issue. 

    This month patches for Windows 2008 contained patches that supersede many, many other patches. So there is nothing wrong with the WSUS server or Windows Update agent. It just takes long because it checks all the superseded patches. 

    Our engineers regularly run the WSUS cleanup wizard but that only cleans superseded EXPIRED patches. First we had to decline all those patches that were superseded manually and then run the WSUS cleanup wizard. 

    This article pointed me in the right direction: https://thwack.solarwinds.com/community/application-and-server_tht/patchzone/blog/2013/01/21/wsus-timeout-errors--removing-unneeded-update-approvals

    After that had been executed, checking for updates was within 2 minutes again.



    • Edited by Marcel Campo Tuesday, August 18, 2015 7:34 AM
    • Marked as answer by Marcel Campo Tuesday, August 18, 2015 7:34 AM
    Tuesday, August 18, 2015 7:33 AM
  • Thank-you for posting your findings Marcel.  I suspect I have the same issue in my environment.  I'm going to work through this today and will confirm the result.
    Tuesday, August 18, 2015 11:17 AM
  • This hasn't worked for us.   Did you also decline superseded updates that were still needed?  From what I've read doing so would go against Microsoft best practice.
    Wednesday, August 19, 2015 4:53 PM
  • After working with Microsoft support and further clearing out superseded updates (declining them) we were able to resolve the issue.  Average search time went down from ~40 minutes to less than 1 minute.
    Wednesday, August 26, 2015 12:17 PM