Patch Scanning & Deployment Best Practices - Configuring Patch Deployment Templates

Table of Contents

Configuring Patch Deployment Templates

The deployment template in Protect is used to determine what actions will take place during patch deployment. This allows you to define the behavior of patch deployment and reboot functions.

Viewing and Editing Existing Deployment Templates

1) From the main drop-down menu, choose 'Templates'.

2) Within the Templates list, you will see two groupings for Deployment Templates.

• Default Deployment Templates
  • These are the available built-in deployment templates that are always available and cannot be renamed or deleted.
• My Deployment Templates
  • These are the available custom deployment templates that you or another admin have created.

3) To get an idea of what the default settings are within a scan template, try clicking on the 'Standard' deployment template.

• It will pop up the Deployment Template window where you can see the settings of the selected template. For the built-in Deployment Templates everything is grayed out because these templates cannot be modified.
• Below you can see, for example, what the Standard deployment template General settings look like.
• You might find that one of these templates will work fine for what you are trying to accomplish during patch deployment
  • Consider all the settings of the deployment template before going ahead with it - especially reboot settings.
  • All of the built-in deployment templates include the 'Always reboot after deployment' rule.
• Before creating a new template, check to see if one already exists that meets your needs.
• When you click on a template from 'My Deployment Templates' you can edit the template settings. See the steps below on how to edit the settings as it is just the same as creating a new patch scan template.

Creating a New Deployment Template

1) From the main menu of Protect, go to New > Deployment Template.

2) Make sure to name your template. You'll be prompted when trying to save the template if you fail to do so.

3) Editing Settings of the Template

General Tab

The General tab of the Deployment Template is where you will set up general rules for patch deployment.

• General Settings
  • Copy speed
    • Allows you to change how fast Protect will try to force updates to be copied to target machines. If you are attempting to save bandwidth it can help to drag this to the 'Slow' side of the bar.
  • Seconds to wait before retrying - If a patch copy fails, you can specify how long to wait between retries.  Valid values are from 0 to 100 seconds.
  • Hours until post deployment emails are sent - You can specify how long to wait for patches to finish installation before automatic email reports are sent. This forces the e-mail messages to be sent even if the console cannot determine that all the machine deployments completed.
• Deployment Actions
  • Before
    • Shut down SQL Server
  • Shut down IIS Server
    • These services will be automatically shutdown when an SQL or IIS patch (respectively) is applied to a remote machine regardless of this setting. Use this setting to shutdown these services when installing OS or similar hotfixes, particularly if you are planning to reboot the machine after installation.
  • During - These options are all enabled by default and it is best practice to leave them enabled.
    • Backup files for uninstall
      • Files will be backed up for any files that are modified in order to perform an uninstall if something goes wrong.
        
    • Quiet mode
      • Run the updates in quiet mode (no user interaction). If unchecked the user will see updates prompt them for interaction.
        
    • Send Tracker status
      • Deployment is set to send tracker status messages to the Protect console during deployment. The only time you should uncheck this is if you know machines being patched will not be able to communicate with the Protect console at the time of the deployment.
        
  • After
    • Remove temp files
      • Checking this box will set the deployment to automatically delete patch files that were copied to the target system as part of this deployment after installation has completed.
        
• Remote Dialog
  This does not work with agents.
  
  • Show dialog on remote machine during execution - You can have a pop up box show up to notify users with a custom message.
    • Title
      • Set the title of the custom remote dialog pop up.
        
    • Caption
      • Set the caption of the custom remote dialog pop up.

          Above: An example of how the remote dialog message will appear to a user.

Office Tab

The Office tab allows you a method to point to original installation media (for older versions of office that require this).

• Office 2007 and newer shouldn't require any change here.
• More information can be found in the Help Article.

Pre-Deployment Reboot

The Pre-Deployment Reboot tab has all the same functions available as Post-Deploy Reboot, but this tab is to be used if you want a reboot prior to installation of patches.

• This can be beneficial to use in cases where you think software that needs updating might still be running.
• A pre-deployment reboot could help to ensure successful installation of patches.
• Refer to information below in 'Post-Deployment Reboot' for details about the different functions.
  

Post-Deployment Reboot

The Post-Deployment Reboot tab will be configure more often. There are many patches that require a reboot for a fully successful installation. It is best practice to configure a post-deployment reboot of some sort whenever deploying updates to the machine.

The functions configured for reboot will go in this order:

    Main reboot rule -> 'Schedule reboot' rule -> What power action? -> 'If a user is logged on' rules ('User may' rules)

• The available main functions:
  • Never reboot after deployment
    • After patches have run their installation, no reboot will be called. If some patches require reboot to complete installation they may show up missing again in Protect until a reboot has been performed.
      
  • Always reboot after deployment
    • After patches have run installation a reboot will be called regardless if it's required or not.
      
  • Reboot when needed
    • After patches have run installation, a reboot may be called based upon return codes from patch installation.
      
• Schedule reboot:
  • Immediately after installation
    • Using this option will force the reboot to take place right after patch installation is done running. Then moves into 'If a user is logged on rules.
      
  • On the next occurrence of specified time
    • Using this option will force the reboot to take place at the next occurrence of the time listed. Then moves into 'If a user is logged on rules.
  • On the next occurrence of specified date and time
    • Using this option will force the reboot to take place at the next occurrence of the date/time listed.. Then moves into 'If a user is logged on rules.
• Power action:
  • You have a few options to choose from for what 'Power action' will be taken. Consider the impact of each of these and which one is best during the time-frame the power action will take place. One of these options must be chosen unless the main rule is set to never reboot. The default is 'Restart'.
    • Restart
    • Restart, then sleep if possible
    • Restart, then hibernate if possible
    • Restart, then shut down
    • Shut down only, do not restart
• If a user is logged on:
  • Alert user, perform action when user logs off
    • Lets the user know a reboot will be performed when they log off
      
  • Force action after (minutes)
    • Lets the user know a reboot is needed and will be performed. Forces the reboot after the number of minutes specified.
      
  • Force action on:
    • Forces the reboot to take place at an exact date and time.
      
  • Show:
    • Countdown time-out (minutes)
      • Allows you to set the countdown timer that the user will see.
      • You can set the language as well.
      • See image below for an example of what the user will see. You can click 'Show sample countdown' in the template to see how yours will look.
        
  • User may:
    • Extend time-out up to the scheduled action time (increment in minutes)
      • Allows the user to postpone the reboot for x number of minutes but will still force the reboot based on the main rule.
    • Cancel time-out (perform action when user logs off)
      • Allows the user to cancel the reboot for the time that they stay logged in on the system. Once they log off, the power action is forced.
    • Cancel action (patch installation will complete at next reboot)
      • Allows the user to cancel the power action altogether. If some patches require reboot to complete installation they may show up missing again in Protect until a reboot has been performed.
        

          Above: Example of the countdown message a user will see when a reboot will take place after Protect deploys patches.

Email Tab

The Email tab allows you set automatic email reports to be sent out during or after deployment (depending on which report is chosen).

• More information can be found in the Help Article.

Custom Actions

Custom Actions give you the ability to push additional files and run scripts along with your patch deployment.

• More information about how to configure and use custom actions can be found in these resources:
  • Help Article
  • Custom Action - How to perform a custom action complete tutorial
  • Custom Action - Using The Null Patch
  • Custom Action - How To Work With Batch Files

Distribution Servers

You can specify in a deployment template if a distribution server should be used for the distribution of patches.

The default option is 'Console push'. Here is a break down of the options available here:

• Console Push (default)
  • The default method of copying patch files to target systems is for the console to "push" the files to each target system.
• Use Distribution Server by IP Range
  • Allows you to have the deployment use a distribution server hosting patch files so target machines will copy any needed files from the associated distribution server rather than having the files pushed to each target machine from the console system.
    • This requires that you have a distribution server and IP ranges for distribution servers configured in Tools > Operations.
    • More information about working with distribution servers can be found in this Help Article.
  • Use backup server - Allows you to choose a specific distribution server as a backup in case one associated by IP range is unavailable.
  • Use vendor as backup source - If a distribution server is unavailable this allows the target machine to try to download needed patches from vendor websites.
  • Distribute scheduled start times (in minutes) - Staggers the amount of target machines attempting to connect to distribution servers and download patches simultaneously.
  • If a patch is not on the Distribution Server, retry:
    • These are the options you can set for target machines to take if a patch was not on the distribution server at the time of deployment.
      • Never
      • After machine Reboots
      • After machine reboots and every 4,8, 12, 24, and 48 hours afterwards.

Hosted VMs/Templates

This tab has functions that are intended only to work with VMware virtual machines and templates hosted by ESXi and vCenter.

To use these features - the systems MUST be added to a machine group via the 'Hosted Virtual Machines' tab.

Here's the break down of the options available:

• Take pre-deployment snapshots
  • If this is checked the deployment process will call for the VMware host to take a snapshot of any VMs being patched, prior to running the deployment.
• Take post-deployment snapshots
  • If this is checked the deployment process will call for the VMware hsot to take a snapshot of any VMs after patch deployment has completed.
• Maximum snapshots Shavlik Protect will manage
  • Sets the maximum number of snapshots that Protect manage, for each VM.
• Delete old snapshots created by Shavlik Protect (age in days)
  • Allows you to set how long to keep snapshots
    Protect does not automatically delete the snapshot on its own after the amount of days is reached. Old snapshots will only be deleted at the next time a deployment occurs using template settings to take snapshots. Because of this it is important to note that once you reach the "Maximum snapshots Shavlik Protect will manage", there will always be that number of snapshots for each VM unless you delete those snapshots outside of Protect's functionality.

Back toPatch Scanning and Deployment Best Practices Guide (Agentless)