locked
WSUS - Auto Download and Schedule Install RRS feed

  • Question

  • Hey, so I have a couple questions regarding WSUS:  

    1. Can computers be set to daily check for updates from an internal WSUS server and download them without installing, and then automatically install those updates at a different, scheduled time, whether they are connected or not?  (I see the GPO called "Automatic Updates detection frequency" that I can configured, but it doesn't say whether updates are downloaded during this operation or not) 

    2. Can computers be configured so that they will download updates from an internal WSUS server first and if it's not available, then reach out to Microsoft?



    • Edited by Caleb44 Friday, January 2, 2015 5:10 PM
    Friday, January 2, 2015 4:57 PM

Answers

  • So that would mean the answer to my initial question is No.  I want an option called "Auto download and install at scheduled time".  

    Let me clarify how this all works.

    The Windows Update Agent periodically checks the WSUS server for updates. Updates it finds, it reports state for: Installed, Not Installed, Not Applicable. If a "Not Installed" update is approved and available, the WUA queues the installation files for download if the Configure Automatic Updates policy is set to AUOption '3' or '4'.

    The download occurs via Background Intelligent Transfer Service (BITS) subsequent to the WUA finding the update as available for download.

    When the download of the update is completed, the WUA does one of two things:

    • If the Configure Automatic Updates policy is set to AUOption '4', then the WUA will schedule the update for installation at the scheduled time. This scheduled installation does NOT require access to the WSUS server to be conducted.
    • If the Configure Automatic Updates policy is not set to AUOption '4', then the update will be retained on the client computer until a user launches the Windows Update applet from Control Panel and initiates the installation.

    If the Configure Automatic Updates policy is set to AUOption '2', then the files will not be downloaded, and a logged on user must initiate the download using the Windows Update applet in Control Panel. This setting is typically used for highly mobile computers that have only sporadic connections to the network servicing the WSUS server.

    The downloading of files using BITS can be controlled using the BITS download policies in Group Policy. You can restrict the bandwidth used for downloads (per client) and/or restrict when those downloads are performed. Ergo, if you want downloads to occur at 8pm each night, simply block the ability to download files prior to 8pm.

    Please note, however, that the files MUST be completely downloaded BEFORE a scheduled installation event for the updates to be installed at that event, and the amount of time required to complete those downloads is highly unpredictable and will change from month to month and client to client.

    Finally, there is one last possible methodology, but this one is fraught with much risk. You can configure clients with AUOption '2', so they do not automatically download update files upon discovery. Then configure an Approval Deadline at the time you want those updates to be installed. In this scenario, and ONLY this scenario, when the client reaches the Approval Deadline, it will automatically download -and- install the updates that have deadlines configured. In addition, this methodology also gives you some capability to configure the *DAY* that updates are installed, not just the time. However, as several threads in this forum will attest, there are MANY opportunities using deadlines for things to go sideways. Be sure to anticipate ALL POSSIBLE scenarios before initiating the use of Approval Deadlines, and more importantly! TEST! TEST! TEST! prior to implementing this methodology throughout the entire organization.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Caleb44 Tuesday, January 13, 2015 11:38 PM
    Monday, January 5, 2015 6:25 PM
  • Also, it appears that clients download windows updates via port 80/443 and not directly from a file server.
    Correct. Specifically only port 80 is used by a client unless you've explicitly implemented the use of SSL, and even then, only the *detection* and *reporting* portions of the task are done via SSL. File transfers are always done via unsecured HTTP on port 80.
    If this is accurate, it would lead me to understand that, in branch offices, we would need to setup both DFSR and a downstream Windows update server in order for those clients to receive updates from the local server.
    You do not need DFSR. The WSUS infrastructure handles its own file replication services. In fact, a downstream WSUS server downloads files from an upstream WSUS server in exactly the same manner that a client does -- using HTTP via port 80.
    It is possible for clients to download updates directly from a file share or must they download them from a WSUS server?
    It is NOT possible to use a file share; clients MUST obtain files from either their assigned WSUS server, or alternatively there is a provision to allow clients to download direct from Microsoft. This configuration would typically be used with a centralized WSUS server supporting a Very Small Site (i.e. only a few clients), where that site has a bigger Internet pipe than it does a corporate WAN link.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Caleb44 Tuesday, January 13, 2015 11:38 PM
    Wednesday, January 7, 2015 4:06 AM
  • How can I configure clients to talk with WSUS but download from Microsoft?

    This is done by NOT configuring a content store on the assigned WSUS server. As noted in the previous reply, typically this configuration is used to support Very Small Sites that do not have onsite WSUS servers. A *replica* server is deployed in the central office that does not contain a content store. The absence of the availability of content on the replica WSUS server forces the clients to obtain those files from Microsoft.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Caleb44 Tuesday, January 13, 2015 11:38 PM
    Wednesday, January 7, 2015 4:08 AM

All replies

  • Yes this is standard setting with the use of GPO. Consult WSUS guides for proper configuration. Take into account that normal function (equilibrium) may take some time (day or two).

    I set installing updates in late evening, say in 22:00. Waik computers from BIOS and shutdown computers with shutdown script . It is easy for desktop computers. If updates are not installed at the prescribed time, there is another attempt next day.

    Do not complicate your situation by configuring nonstandard update procedures. Also remember that updates for WSUS are packed specifically for this purpose.

    Regards

    Milos

    Friday, January 2, 2015 6:54 PM
  • 2. Can computers be configured so that they will download updates from an internal WSUS server first and if it's not available, then reach out to Microsoft?

    No.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Saturday, January 3, 2015 2:21 PM
  • Milos, I need you to clarify.  Are you saying that the operation of checking for updates that is set via the "Automatic Updates detection frequency" GPO, will both check and download updates (not install)?
    Monday, January 5, 2015 4:57 PM
  • Milos, I need you to clarify.  Are you saying that the operation of checking for updates that is set via the "Automatic Updates detection frequency" GPO, will both check and download updates (not install)?

    You want to set the "Auto download and notify for install" option under "Configure Automatic Updates" in Group Policy. After the client has detected that it needs updates and downloads then, you do not need a connection to the WSUS server for them to be installed.
    Monday, January 5, 2015 5:27 PM
  • So that would mean the answer to my initial question is No.  I want an option called "Auto download and install at scheduled time".  
    Monday, January 5, 2015 5:59 PM
  • So that would mean the answer to my initial question is No.  I want an option called "Auto download and install at scheduled time".  

    Let me clarify how this all works.

    The Windows Update Agent periodically checks the WSUS server for updates. Updates it finds, it reports state for: Installed, Not Installed, Not Applicable. If a "Not Installed" update is approved and available, the WUA queues the installation files for download if the Configure Automatic Updates policy is set to AUOption '3' or '4'.

    The download occurs via Background Intelligent Transfer Service (BITS) subsequent to the WUA finding the update as available for download.

    When the download of the update is completed, the WUA does one of two things:

    • If the Configure Automatic Updates policy is set to AUOption '4', then the WUA will schedule the update for installation at the scheduled time. This scheduled installation does NOT require access to the WSUS server to be conducted.
    • If the Configure Automatic Updates policy is not set to AUOption '4', then the update will be retained on the client computer until a user launches the Windows Update applet from Control Panel and initiates the installation.

    If the Configure Automatic Updates policy is set to AUOption '2', then the files will not be downloaded, and a logged on user must initiate the download using the Windows Update applet in Control Panel. This setting is typically used for highly mobile computers that have only sporadic connections to the network servicing the WSUS server.

    The downloading of files using BITS can be controlled using the BITS download policies in Group Policy. You can restrict the bandwidth used for downloads (per client) and/or restrict when those downloads are performed. Ergo, if you want downloads to occur at 8pm each night, simply block the ability to download files prior to 8pm.

    Please note, however, that the files MUST be completely downloaded BEFORE a scheduled installation event for the updates to be installed at that event, and the amount of time required to complete those downloads is highly unpredictable and will change from month to month and client to client.

    Finally, there is one last possible methodology, but this one is fraught with much risk. You can configure clients with AUOption '2', so they do not automatically download update files upon discovery. Then configure an Approval Deadline at the time you want those updates to be installed. In this scenario, and ONLY this scenario, when the client reaches the Approval Deadline, it will automatically download -and- install the updates that have deadlines configured. In addition, this methodology also gives you some capability to configure the *DAY* that updates are installed, not just the time. However, as several threads in this forum will attest, there are MANY opportunities using deadlines for things to go sideways. Be sure to anticipate ALL POSSIBLE scenarios before initiating the use of Approval Deadlines, and more importantly! TEST! TEST! TEST! prior to implementing this methodology throughout the entire organization.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Caleb44 Tuesday, January 13, 2015 11:38 PM
    Monday, January 5, 2015 6:25 PM
  • Thank you for the detailed explanation Lawrence.  Let me see if I understand this correctly.  Please let me know if I'm right or wrong about this.

    1. Windows Update Agent Checks for updates (The frequency that it checks is determined by the GPO called "Automatic Updates Frequency")

    1a. Immediately after WUA checks for updates, if option "4 - Auto download and schedule the install" is set under "Configure Automatic Updates", then the updates will be downloaded immediately, but installed at the scheduled time set in that is set the "Configure Automatic Updates" GPO.  

    Monday, January 5, 2015 7:31 PM
  • Also, it appears that clients download windows updates via port 80/443 and not directly from a file server.  If this is accurate, it would lead me to understand that, in branch offices, we would need to setup both DFSR and a downstream Windows update server in order for those clients to receive updates from the local server.  Is this accurate?  It is possible for clients to download updates directly from a file share or must they download them from a WSUS server?
    Monday, January 5, 2015 8:20 PM
  • You do not have to setup a downstream WSUS server but if you have many clients in that office then you might want to do so for bandwidth reasons. This would then be set to synchronise it's configuration from the master WSUS server. If you setup downstream WSUS servers then you will need to get the clients in those branch offices to connect to the local server so you are looking at more GPO's, maybe site based GPO's.

    There is no file share as such you can get updates from.

    The WSUS server controls which updates get installed etc but they do not need to come from a WSUS server. If you only have a handful of clients at a remote office you can instruct the clients to individually download the updates via windows update instead of a WSUS server.

    Tuesday, January 6, 2015 10:40 AM
  • The WSUS server controls which updates get installed etc but they do not need to come from a WSUS server. If you only have a handful of clients at a remote office you can instruct the clients to individually download the updates via windows update instead of a WSUS server.

    How can I configure clients to talk with WSUS but download from Microsoft?

    Additionally, can hot-fixes be deployed via WSUS?

    Tuesday, January 6, 2015 5:37 PM
  • Thank you for the detailed explanation Lawrence.  Let me see if I understand this correctly.  Please let me know if I'm right or wrong about this.

    1. Windows Update Agent Checks for updates (The frequency that it checks is determined by the GPO called "Automatic Updates Frequency")

    1a. Immediately after WUA checks for updates, if option "4 - Auto download and schedule the install" is set under "Configure Automatic Updates", then the updates will be downloaded immediately, but installed at the scheduled time set in that is set the "Configure Automatic Updates" GPO.  

    This is 100% correct. :)

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, January 7, 2015 4:03 AM
  • Also, it appears that clients download windows updates via port 80/443 and not directly from a file server.
    Correct. Specifically only port 80 is used by a client unless you've explicitly implemented the use of SSL, and even then, only the *detection* and *reporting* portions of the task are done via SSL. File transfers are always done via unsecured HTTP on port 80.
    If this is accurate, it would lead me to understand that, in branch offices, we would need to setup both DFSR and a downstream Windows update server in order for those clients to receive updates from the local server.
    You do not need DFSR. The WSUS infrastructure handles its own file replication services. In fact, a downstream WSUS server downloads files from an upstream WSUS server in exactly the same manner that a client does -- using HTTP via port 80.
    It is possible for clients to download updates directly from a file share or must they download them from a WSUS server?
    It is NOT possible to use a file share; clients MUST obtain files from either their assigned WSUS server, or alternatively there is a provision to allow clients to download direct from Microsoft. This configuration would typically be used with a centralized WSUS server supporting a Very Small Site (i.e. only a few clients), where that site has a bigger Internet pipe than it does a corporate WAN link.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Caleb44 Tuesday, January 13, 2015 11:38 PM
    Wednesday, January 7, 2015 4:06 AM
  • How can I configure clients to talk with WSUS but download from Microsoft?

    This is done by NOT configuring a content store on the assigned WSUS server. As noted in the previous reply, typically this configuration is used to support Very Small Sites that do not have onsite WSUS servers. A *replica* server is deployed in the central office that does not contain a content store. The absence of the availability of content on the replica WSUS server forces the clients to obtain those files from Microsoft.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Caleb44 Tuesday, January 13, 2015 11:38 PM
    Wednesday, January 7, 2015 4:08 AM
  • Your answers have been extremely helpful!  thank you Lawrence.  I think i have one two last questions for you.  

    Microsoft occasionally releases optional updates.  Can these "optional" updates be configured as mandatory/recommended updates for the clients to insure they get installed?  Additionally, can hot fixes that Microsoft releases be installed via WSUS?

    Wednesday, January 7, 2015 7:30 PM
  • Microsoft occasionally releases optional updates.

    "Optional Updates" are a contrivance of the UI in the Windows Update applet for the benefit of consumers. They have no significance in the realm of WSUS. Those updates will be classified in one of the predefined WSUS update classifications, and totally subject to being approved or not being approved.

    Additionally, can hot fixes that Microsoft releases be installed via WSUS?

    Generally speaking, No. HOTFIXES were designed with a totally separate installation mechanism because Microsoft DOES want those HOTFIXES to installed as a one-off event on machines that expressly demonstrate the symptoms that indicate the appropriateness of the hotfix. As such, hotfixes cannot be mass-deployed using WSUS.

    You can, however, extract the installer from the Microsoft-published hotfix bundle, and build a custom package which can be injected into the WSUS server using Local Publishing. Doing this is tantamount to a programming exercise, so it's not something intended for the novice, or the faint of heart. :-)


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, January 7, 2015 10:06 PM
  • Again, I really appreciate your answers.  If we do this alternative way of publishing hotfixes, is there an easy way to target the OS version/architecture it will install on?
    Wednesday, January 7, 2015 10:11 PM
  • If we do this alternative way of publishing hotfixes, is there an easy way to target the OS version/architecture it will install on?

    That would be part of the package definition process.

    Of course, one also assumes you have a special group for only those machines that should get the hotfix, so where the update is approved is also a key control point.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Thursday, January 8, 2015 1:42 AM
  • Of course, one also assumes you have a special group for only those machines that should get the hotfix, so where the update is approved is also a key control point.

    I'm not sure what you mean here.  Is it necessary to set the package definition and have those computers in a specific group?  Or is having those computers in a specific group an alternative way to target them?
    Thursday, January 8, 2015 1:57 AM
  • Of course, one also assumes you have a special group for only those machines that should get the hotfix, so where the update is approved is also a key control point.

    I'm not sure what you mean here.  Is it necessary to set the package definition and have those computers in a specific group?  Or is having those computers in a specific group an alternative way to target them?

    Since the precept of a hotfix is that it only goes to the machines that are actually demonstrating symptoms that will be fixed by the hotfix -- and understanding that since the hotfix is not regression tested it may well introduce additional issues -- the appropriate way to handle that scenario is to create a custom Target Group containing only those machines that should get the hotfix and approving the hotfix for only that one Target Group.

    You should do both. The Package Definition should include any classes of computer that the hotfix is applicable for. This might be one OS on one architecture, or it might be one OS with all architectures, or it might be multiple OSes and multiple architectures. The package defines eligibility without any regard for what is actually in any given environment.

    The Target Group is how you manage that package's behavior in YOUR environment.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Thursday, January 8, 2015 9:46 PM
  • Since the precept of a hotfix is that it only goes to the machines that are actually demonstrating symptoms that will be fixed by the hotfix -- and understanding that since the hotfix is not regression tested it may well introduce additional issues -- the appropriate way to handle that scenario is to create a custom Target Group containing only those machines that should get the hotfix and approving the hotfix for only that one Target Group.
    Also, remember that a client can belong to more than one WSUS target group, and that groups can be nested.  If the clients needing a hotfix are already assigned to a larger group, you can still create a HotfixKBnnnn group containing just those clients.
    Friday, January 9, 2015 12:24 AM
  • Thanks for all you help Lawrence!  I really appreciate it!
    Tuesday, January 13, 2015 11:37 PM