1 Reply Latest reply on Aug 11, 2016 9:40 AM by brett.chadwick

    How to setup automated Windows-Update installations for Endpoints?

    bmueller87 Rookie

      Hi there,

       

      we're using HEAT EMSS with version 8.3.0.10 with about 250 clients.

      Actually, we're using EMSS with our clients to deactivate the local windows updates. Yes, no installations of any sort. That's now my part..

      I've read the helpfile and searched a little bit in web, but haven't found anything relating the regulary and automated installation of Windows-updates.

       

      I've setup some groups, added some testclients to that groups and played a little bit with delivering IE11 for Win7x64 with the mandatory baseline: works.

      Also, i've viewed the vulnerabilities of these groups, selected the issues manually and deployed them: works too.

       

      Now my question is: I can schedule a Deploytask. But.. EMMS showed me for example 100 pending updates for one Client. I've installed them - after some reboots i've checked the vulnerabilities of the same client, and there were some new updates left (~50). So i've installed them.

      If i setup a deployment task, he only installs the updates i initially selected - is that correct?

       

      Maybe, there's a walktrough or something, that could help me to figure this out? I don't want to check and test updates - i only want the clients to be up-to-date on the microsoft-side (we're using citrix - so the client doesn't matter).

       

      Thanks for you help,

      Bastian

        • 1. Re: How to setup automated Windows-Update installations for Endpoints?
          brett.chadwick Apprentice

          Great question, the EMSS suite has been designed from the ground up as one of the most advanced and accurate patch detection and delivery mechanisms available. The approach that our customers have always looked for was more control over the update process, automating this process of selecting vulnerabilities and automatically deploying everything is generally not the best approach. Most environments test, or at least ensure a basic level of sanity for deployments before scheduling them and this would be the intention of the product design.

           

          The reasons are numerous for this as you may break the endpoints, break services running on servers, change versions of Java, .Net that applications rely on, upgrade browser versions not supported by web apps just as a few examples. I can understand your enviroment and the lack of full testing on virtual disposable endpoints but we still find this process is the best to ensure reliable endpoints, applications and user experiences. We have observed this in customer environments in the past where the automation resulted in some or all of the above mentioned issues.

           

          You have a couple of methods to simplify the patching process and reduce the workload.

           

          The design  of the product flows around patching through groups bringing all machines up to date and in regards to Microsoft releases patching only on the patch Tuesday cycles sending out the small number of Critical patches that are released on a monthly basis after the initial update.

           

          This will require you at one stage to bring all machines as up-to date as possible. From what you have described in your enviroment this sounds like it should be fairly straight forward in that you can look at all the outstanding vulnerabilities from the Vulnerabilities view in the interface and deploy these to all your endpoints.

           

          Screen Shot 2016-08-11 at 8.23.15 AM.png

           

           

          Once all endpoints have been patched you will only need to login to the interface and schedule the patch Tuesday patches once a month. You can even create a custom patch list with these and simply deploy this custom patch list to all your endpoint groups. You will be able to track the deployment as it progresses and in addition you can report on compliance after the patching, trending using enhanced reporting to show your progress in the enviroment.

           

          Another option as you mentioned is the mandatory baseline which allows you to add patches into a baseline for installation. This is helpful for applications or patches that must exist on all endpoints. We normally would advise using the custom patch list as displayed below in place of the baseline for all patches as baseline can become very large over time and won't provide the same level of performance as the custom patch list deployments which leverage our vulnerability intelligence.

           

           

          Screen Shot 2016-08-11 at 8.37.19 AM.png

           

           

          In a simple enviroment without any testing framework or change controls the patching process is very straight forward. Login as you do and patch via a high level group like Windows or My Groups at the most basic level and send out all the outstanding Critical (New) content. Job done. This process in a simple enviroment should take easily less than 5 minutes.

           

          A second option from the more controlled approach that some customers use is to enable Windows Automatic Updates and allow clients to update themselves through other means in addition to scheduled patching or in place of scheduled patching. This ensures updates are applied you have reporting, vulnerability detection through the EMSS suite to have a view into this and ensure compliance. We have a package built into the interface that can be leveraged to enable and disable the Windows Update service. Many times this approach would be used for clients that are not on the network, VPN and still  need to update from coffee shop Wifi or hotel connections although you can use it for network connected machines.