Kaseya Community

Windows Auto-Update Service and Patching

This question is answered

Hello,

We're a small shop and our servers don't have the Windows Automatic Update service running, nor are they connected to the Internet. Before we had Kaseya, we would manually enable and start the service, add a gateway, run the updates and then stop/disable the service and remove the gateway. My understanding is that it is important to have the Windows Automatic Update service Enabled and set to Automatic so Kaseya can run the Patch Scan even though the servers are not connected to the Internet. Is that correct or do I have the Kaseya Patching totally wrong? If so, is there a way to have a Procedure run Pre Patch Scan automatically? So my hope is to Start the service, run the Patch Scan, Stop the service. I know the Kaseya Automatic Update allows you to have Pre/Post procedures, but was wondering if I could do the same for Patch Scan.

Thank you,
Sau

Verified Answer
  • Sau,

    If you have the Windows Update/Automatic Update service stopped (that would be the Windows Service, not the local GUI for windows/auto update), your patch scan will not be able to complete the scan against Microsoft's internet-based patch repository.  However, if the endpoints don't have access to the internet, you won't be able to complete the scan against Microsoft's internet-based repository, anyway.  Instead, the patch scan will fail to use this primary data source and will, instead roll over to complete the scan using the alternate data source.  The alternate data source is a .cab file stored on the local endpoint that contains a very, very limited group of patches (active Service Packs, security updates).  There's a deeper description of the primary and alternate data sources available in KKB000781.  

    Only those patches that are discovered as Missing and have been approved by policy (listed as "Missing Approved" on the patch status page) will be scheduled for installation during Patch Management > Automatic Update.  That means that if you want to scan for ALL missing patches (not just those that would be contained within the .cab file) you must perform a successful scan against the endpoint during a time when the endpoint has access to the internet and the BITS and Automatic Update/Windows Update services are started.   Generally speaking, there's no need to disable these two services, so I would advise you leave these started at all times.  You would, however, need to allow the endpoint to access the internet (the necessary sites are listed in the previously referenced KB article) during the scan to discover all missing patches. Then, at the time you want to actually install the updates, any patches that can be installed via a single-file executable (has a URL listed in Patch Management > Patch Location) will be downloaded from the internet to the LAN file share or KServer (defined in Patch Management > File Source).  In this scenario, only the LAN file share would need internet access.  The endpoints would get most patches via the LAN file share (those that are internet-based install only will never install if the endpoint does not have access to the internet).  

    In order to determine whether the patches that were scheduled for installation actually installed or if they failed, another patch scan is run after the installation cycle completes.  This scan would require that the endpoint have access to the internet for this scan.  If it does not, the scan will complete against the alternate data source and may mis-report patches as failed.  

    In short, I would recommend:  

    If you want to install ALL patch categories (not just services packs, but also program updates like Office patches), ensure the endpoint can scan against the internet.  Configure a LAN file share as the file source.  With your network open, run a scan against the endpoint, allow patch to complete, reboot the endpoints, and then run a re-scan.  Then re-restrict the network.

    If you are only concerned with getting Service Packs and security updates on the machine, you needn't worry about the endpoint having access to the internet.  These will be discovered and install based on the information held within the .cab file.

  • Sau,

    The .cab file contains the current, active service packs and security updates.  Using your example, if a security update is added to the .cab file in October, you don't patch that month, and then the security pack is replaced by an updated version in November, only the updated version would be discovered during a scan and installed during automatic update in November.  However, if the security update from October is not updated (and therefore still the current, active version of that patch), then the October version would be discovered/install.  The update is only 'removed' from current-active if it is replaced by a newer version (or, in very uncommon instances, Microsoft pulls the update due to a problem with the patch itself).  

All Replies
  • The following services should never be disabled:

    1. Automatic Updates (XP)

    2. Windows Update (Vista, 7)

    3. Background Intelligent Transfer Service

    You need these no matter how you go about doing your patching and you don't gain anything by disabling them. If you are only trying to stop Windows from patching itself, then check out the "Windows Auto Update" page in Patch Management.

  • Sau,

    If you have the Windows Update/Automatic Update service stopped (that would be the Windows Service, not the local GUI for windows/auto update), your patch scan will not be able to complete the scan against Microsoft's internet-based patch repository.  However, if the endpoints don't have access to the internet, you won't be able to complete the scan against Microsoft's internet-based repository, anyway.  Instead, the patch scan will fail to use this primary data source and will, instead roll over to complete the scan using the alternate data source.  The alternate data source is a .cab file stored on the local endpoint that contains a very, very limited group of patches (active Service Packs, security updates).  There's a deeper description of the primary and alternate data sources available in KKB000781.  

    Only those patches that are discovered as Missing and have been approved by policy (listed as "Missing Approved" on the patch status page) will be scheduled for installation during Patch Management > Automatic Update.  That means that if you want to scan for ALL missing patches (not just those that would be contained within the .cab file) you must perform a successful scan against the endpoint during a time when the endpoint has access to the internet and the BITS and Automatic Update/Windows Update services are started.   Generally speaking, there's no need to disable these two services, so I would advise you leave these started at all times.  You would, however, need to allow the endpoint to access the internet (the necessary sites are listed in the previously referenced KB article) during the scan to discover all missing patches. Then, at the time you want to actually install the updates, any patches that can be installed via a single-file executable (has a URL listed in Patch Management > Patch Location) will be downloaded from the internet to the LAN file share or KServer (defined in Patch Management > File Source).  In this scenario, only the LAN file share would need internet access.  The endpoints would get most patches via the LAN file share (those that are internet-based install only will never install if the endpoint does not have access to the internet).  

    In order to determine whether the patches that were scheduled for installation actually installed or if they failed, another patch scan is run after the installation cycle completes.  This scan would require that the endpoint have access to the internet for this scan.  If it does not, the scan will complete against the alternate data source and may mis-report patches as failed.  

    In short, I would recommend:  

    If you want to install ALL patch categories (not just services packs, but also program updates like Office patches), ensure the endpoint can scan against the internet.  Configure a LAN file share as the file source.  With your network open, run a scan against the endpoint, allow patch to complete, reboot the endpoints, and then run a re-scan.  Then re-restrict the network.

    If you are only concerned with getting Service Packs and security updates on the machine, you needn't worry about the endpoint having access to the internet.  These will be discovered and install based on the information held within the .cab file.

  • A bit off topic here, but as noted above it is best to allow internet access to the machines so they can be fully patched. I would reccomend using a firewall or content filter to restrict or completly block web browsing, and only allow access to the Windows update sites/ports. The Windows Update server IP's change, so you need to be able to allow a host name and not just IP.

  • @sau,

    I think Brenden has already detailed all the things.

    More-ever you can look for Best practices on forum

  • Thank you so much for this detailed explanation. That really helps. We have to adhere to some security policies, one of which is that some servers CANNOT touch the Internet. Due to this we don't even have a gateway setup for them. Since we are mainly concerned about getting security updates for the servers, from your explanantion, it seems like the .CAB file would work just fine for us. However, am I also correct to assume the risk that the CAB file will only contain newer updates and not the old ones. So, if I forget to run a Patch Scan on the servers in October, and run it late November, I will only get the updates that came out in November since it would be a November .CAB file?

    Thanks again.

    Sau

  • Sau,

    The .cab file contains the current, active service packs and security updates.  Using your example, if a security update is added to the .cab file in October, you don't patch that month, and then the security pack is replaced by an updated version in November, only the updated version would be discovered during a scan and installed during automatic update in November.  However, if the security update from October is not updated (and therefore still the current, active version of that patch), then the October version would be discovered/install.  The update is only 'removed' from current-active if it is replaced by a newer version (or, in very uncommon instances, Microsoft pulls the update due to a problem with the patch itself).  

  • Ok, that answers my question. Thanks a lot Brande.

    --Sau