Patch Scanning & Deployment Best Practices - Successfully Running Agentless Patch Scans & Deployments

Version 1

    Table of Contents


    Successfully Running Agentless Patch Scans & Deployments


    The main function of Shavlik Protect is to scan machines for updates that are needed, and to be able to install those updates. This section should help provide you some resources to make sure you can successfully perform and understand these tasks.


    Patch Scanning


    Overview of Patch Scan Process

    An agentless scan in Protect works by doing the following:

    1. [As long as console is not set in disconnected mode] Performs a check for new patch definitions, then downloads and imports new definitions if needed.
    2. Resolves the machines that have been selected to scan. If the machine cannot be found or resolved, the scan will fail.
    3. Once a machine has been resolved, Protect will connect to the machine with the provided credentials. If no credentials have been provided for the machine or machine group Protect will attempt to use the currently logged on credentials to gain access. If no valid credentials are provided, the scan will fail.
    4. Protect will connect to the remote machine's registry and file system, and it will read the values of files and registry keys based upon detection logic defined within Protect's patch definitions. This is how Protect will determine the products that are installed on a machine and what updates are considered missing, installed, and effectively installed.
      • It is worth noting that Protect will make a separate connection for each check that is performed. Because of this, high latency and slow connections can cause the scan to take an exponentially long amount of time to complete. More information here.
      • If Protect cannot gain access to read the remote machine's registry or file system, the scan will fail.
    5. A scan result file is created within one of the sub-directories under C:\ProgramData\LANDESK\Shavlik Protect\Console\Arrivals.
    6. The information of the scan result is then imported to the Protect database, and the temporary file from "Arrivals" is deleted.
      [File is not deleted if 'Keep imported files' is enabled in Tools > Options]
    7. Scan results are then view-able within the Protect console, can be used for deployment, or can have reports run against them.


    Requirements for Agentless Patch Scanning

    The requirements to be able to successfully perform patch scans can be found here:


    Running a Patch Scan

    All patch scans are performed as background tasks using the services of the Operations Monitor. This means you can initiate a scan and then move on to other concurrent work within Shavlik Protect without having to wait for the scan to complete. This also means you can have multiple patch scans active at the same time.

    There are a few methods to initiate a patch scan:

    • From the Home page of Protect
    • From a Machine Group
    • From a Favorite
    • From Machine View


    For full details on how to initiate patch scans, see the Protect Help Article - How to Initiate a Patch Scan.


    Troubleshooting Patch Scan Failures

    If Protect is unable to scan a machine it will be placed in the 'Machines not scanned' section of a scan result, and there should be an error code and brief message provided. Generally an error indicates that one or more of the scanning requirements is not met, however, a full listing of the error codes and how to troubleshoot and fix each error is listed in this document:

    Troubleshooting Shavlik Protect patch scan error messages


    Patch Deployment


    Overview of Patch Deployment Process

    An agentless deployment in Protect works by doing the following:

    1. List of patches to deploy is either automatically generated (scan & auto-deploy) or manually generated based on choice of patches to deploy from a scan result.
    2. The patch installer files are downloaded, and the digital signatures of those files are verified.
    3. Deployment files are created for each machine (.bat & .cfg files), based on what patches are chosen to install as well as the settings in the chosen deployment template.
    4. Deployment files and patch installer files are pushed to target machines, copied into C:\Windows\Propatches and sub-directories by default.
    5. Scheduling is set up for patch installation.
      These actions take place for scheduling with the default (Shavlik Scheduler):
      1. Install scheduler if it's not present or re-install scheduler if in need of an update or other issue detected.
      2. The deployment job is scheduled to take place based on the time specified by the admin who set up deployment.
        1. If "Deploy now" was chose, the scheduler immediately runs the deployment job.
        2. If a later time is set, the scheduler waits until the specified date/time occurs on the target machine, and then runs the deployment job.
      3. Once run, it's actually the commands within the .bat file created for deployment that calls for patch installation and performs the deployment of patches based upon settings that were chosen within the deployment template. By default, deployment tracker results will be sent to the console throughout the patch deployment process.
      4. If set to do so, a reboot will occur. The .bat file running deployment renames itself to a .HIS after completion.
      5. An automatic re-scan will be performed to verify successful installation of patches.
      6. Deployment of patches will be reported back to the console as 'Successfully installed'.


    Patch Deployment Prerequisites

    The prerequisites to be able to successfully deploy patches to remote machines can be found here:


    Running Patch Deployment

    All patch deployments are performed as background tasks, regardless of how they are initiated. In other words, the deployment is launched as its own separate Windows task. This means you can initiate a patch deployment and then move on to other concurrent work within Shavlik Protect without having to wait for the deployment to complete. This also means you can have multiple patch deployments active at the same time.


    These Help articles cover certain aspects of how to deploy patches:


    Deploying Service Packs

    It is generally considered best practice to deploy service packs prior to deploying patches. This is because service packs often include fixes of many patches, and once a service pack is applied there may be new updates that are required only when that service pack is installed. In the long run you are saving time by deploying the service packs first, although, they can generally be a bit more of a pain to deal with initially.


    The information referenced here should help make deploying service packs understandable and easier to manage:


    Deploying to Hosted Virtual Machines and Templates

    The process of how deploying to Hosted VMs and Templates works off the same basic functionality as the above described process for patch deployment, however, there are additional steps taking place as well as additional requirements.


    Refer to the following pieces of information to help with requirements for deploying to hosted VMs & Templates:


    Troubleshooting Deployment Failures

    Troubleshooting deployment failures can be quite a bit more in-depth than troubleshooting a scan failure. Consider these questions:

    • Is there an immediate failure?
    • What is the error message, if any is given?
    • If the failure is only with a certain patch or specific group of patches - what is the correlation between them if any?
    • Often the problem starts with the scan if patches are failing to install. Is the scan using the latest patch definitions? What scan template was used to run the scan?
    • Refer to the following resources for any self-help with deployment failures:
    • If you can't figure out a resolution, contact support with any of the above information as well as any program logs you can provide.


    Automation of Patch Scanning and Deployment


    Protect can automate patch scanning and deployment by using the scheduling features that are built in. This is where filtering set up within the patch scan template that you use can become a big factor. If you plan to automate scan and deployment you need to consider what updates you intend to allow (filtering), what time you can accomplish the installation of patches, and what the best method for you to accomplish this might be. With Protect there can be variations of how you can automate your patch scanning and deployment.


    Here are a few options:

    • Recurring scheduled scan with auto-deployment
      • Less control, but this is the fully automated.
    • Recurring scheduled scan, manual scheduling of deployment.
      • Still somewhat automated, but you will need to look at scan results and schedule deployments after scans have already completed.
    • Recurring scheduled scan, auto-deploy enabled with 'Copy Patches only' feature. Manual scheduling of actual deployment.
      • Allows you to perform scans and have patches automatically downloaded and copied to target systems. You will need to look at scan results and schedule another deployment later that will actually run the installation of the patches. This option could help if you want to make sure you have everything ready to go for a maintenance window that limits how much time is available for the whole process to take place.


    An example of a fully automated scheduling of patch scanning and deployment:



    If you ever need to delete a scheduled scan of any kind (even with auto-deploy) just go into Manage > Scheduled Tasks and locate your console system in the list. The job will be listed under the console system's scheduled jobs and can be deleted from here. Note that if you are using the Microsoft Task Scheduler, you would need to check the Microsoft Task scheduler list for this instead.


    Additional Information about setting up scheduled scans, deployments, and automated tasks can be found in these resources:



    Back to Patch Scanning and Deployment Best Practices Guide (Agentless)