Related Articles

Increase the efficiency of patching ten-fold with fully customizable deployment policies

The ever-changing work environment requires a solution that is equally capable of adapting and catering to all your patching requirements. For a controlled patching experience, you need a solution that will allow you to tailor deployment policies according to your enterprise needs.

Patch Manager Plus' flexible deployment policies come with a range of settings that will let you completely configure a deployment policy along with what happens before and after patch deployment. What's more, these policies can be deployed across all your enterprise endpoints to enable patching, irrespective of them being mobile, remote, or asleep.

This deployment workflow is available from build version 10.1.2121.1. To upgrade to the latest build version, download the latest service pack.

  • Configure a deployment policy for your enterprise requirements
  • Creating a deployment policy
  • Role-based access
  • Configure a deployment policy for your enterprise requirements

    Patch Manger Plus caters to the needs of a wide variety of industries and enterprises. Hence, the deployment policies are created after careful consideration of real-time requirements and are flexible enough to accommodate most patching needs

    Deployment windows are scheduled and executed based on the time zone of the agent.

    Creating a deployment policy:

    To create a new policy, click on Deployment > Deployment policies > +Create Policy. The new policy creation process has four steps

    1. Deployment schedule
    2. Pre-deployment activities
    3. Pre-deployment user notification
    4. Post-deployment activities

    patch deployment policies

    Step 1: Deployment schedule:

    In this step, we need to create a schedule for the deployment policy. The deployment policy is initiated and run according to this schedule. You have complete autonomy to choose the weeks and days on which you need this deployment policy to be performed.

    Regular split: The weeks are marked as found in a regular calendar. Eg: The first week refers to the first seven days in the month. The Regular split can efficiently be leveraged to set the deployment at the week(s) and day(s) of your convenience, however if your patching schedule depends on Patch Tuesday, then it is efficient to go with the Patch Tuesday split.

    patch deployment policies

    Patch Tuesday split: The Regular split might not be suitable if your patching schedule depends on the Patch Tuesday, here is an example demonstrating one of the problems you might face. Eg: Say you choose to patch the weekend after Patch Tuesday, with the Regular split you will have to choose the 2nd week and the days - Saturday and Sunday. But if the week looks like the one in the picture above, the weekend after Patch Tuesday (13th) falls in the 3rd week. So choosing the 2nd week in the Regular split, in this case, causes your deployment to happen before Patch Tuesday.

    It is precisely to avoid confusions like this, we have the Patch Tuesday split. In the Patch Tuesday split, the weeks are marked with respect to Patch Tuesday. Eg: Patch Tuesday week starts from the 2nd Tuesday of every month and the successive weeks are numbered increasingly. This setting is for organizations that wish to align their patch deployment cycles after Microsoft's Patch Tuesday updates are released. Once you have chosen the weeks, you can choose the days on which you need the deployment to happen.

    patch deployment policies

    Deployment window: The deployment window allows you to select the time frame of deployment. Based on the size of your target group and requirement, specify the start and end time in 'Deployment window.' Deployment will happen within the time limit specified here. If deployment is not completed, it will be continued during subsequent deployment window. You can also have multiple deployment windows for the same deployment policy by selecting "Add more schedules".

    This creates an additional deployment window and will come in handy in scenarios where a single deployment window won't suffice. For example, as an IT administrator, you can choose to have one deployment window post 8 pm on weekdays, and a second deployment window throughout the day on weekends.

    patch deployment policies

    Patch download: You can further decide when you want the patches to be downloaded from the server to the agent. For instance, if you have a small deployment window and want only the deployment process to occur during the deployment window, you can choose the patch download to happen 'Any time agent contacts the server'. Eg: Selecting the 'Any time agent contacts the server' option will allow you to have a deployment window as short as 1 hour as the patches will be downloaded in the agent before the deployment window.

    For instance, say a deployment policy has been initiated at 2pm, and the deployment window is from 4pm to 10pm. The missing patches are downloaded during the subsequent refresh cycle, which is at 3:30pm. This makes patches ready to be installed in client machines when the deployment window starts at 4pm. Alternately you can also choose to download the patches during the deployment window by selecting the 'Only at deployment window' option.

    patch deployment policy

    Initiate deployment: You can choose for the deployment process to start either at system startup or the refresh cycle or whichever happens first in the deployment window.

    patch deployment policy

    Step 2: Pre-deployment activities:

    The option to configure pre-deployment activities takes personalization to the next level. Want to wake up computers for deployment? Want to stop a process before proceeding with deployment? You can do it all.

    Wake on LAN: Drag and drop this pre-defined activity to wake the computers which the deployment policy targets. Computers within the same subnet of the server installed network or different subnets can be woken up. When this task to wake up a computer is initiated in the same subnet, the server initiates the task. If you are trying to wake up a computer which belongs to a different subnet, then at least one of the computers in the specified subnet should have a live Patch Manager Pus agent to perform the wake up task.

    patch deployment policy

    If you try to wake a computer which belongs to a remote office, then one of the following criteria should be met:

    • IP redirected broadcast should be enabled on the router.
    • One of the computers with Patch Manager Plus agent should be live in the same subnet, to perform the task.

    deployment policy

    Pre-deployment reboot: It is generally advisable to reboot your systems before initiating a patch task for any previous pending changes to occur before the new patch deployment occurs. For organizations that follow this as a golden rule and include pre-deployment reboot as a requirement before their patch tasks, you can now drag and drop the Pre-deployment reboot to your curated sequence of pre-deployment activities. Now some of you might not want to reboot all your machines before deployment, in that case all you have to do is drag and drop the Pre-deployment reboot and while configuring it, click on the option to Skip reboot for machines that do not require reboot.

    patch deployment policies

    Custom scripts: You know what's best for your environment, we leave the choice to create a process that suits your work environment, to you. Create scripts to perform unique and environment-specific pre-deployment activities. For instance, patching servers has always been challenging. With the option to add custom scripts before patch deployment, you can go ahead and write dedicated scripts to stop certain processes on servers before deployment, or perform sequential/cluster patching on servers.

    Some popular use cases of custom scripts are, to take snapshots of the machines before running a patch task, to check if any other service is running (validation purposes) and stop it, if it needs to be stopped before a patch task, to check if the backup server is ready before shutting down the primary server for patch deployment, the use cases are endless.

    Dependency file(s): If your scripts require additional files for execution, you can upload those additional files, in the Dependency file(s) section.

    patch deployment policies

    Step 3: Pre-deployment user notification:

    However meticulously we plan our patching schedule, we cannot rule out the factor that employees might choose to work beyond the set business hours or the possibility of a highly critical patch that needs to be installed during business hours. In such cases, it is always prudent to keep employees informed about patch deployment activities and allow them the liberty to skip deployment if they are held up in some business critical activity. In case of critical patch deployments, you also have the option to force deployment after 'x' days from which the user skipped deployment, thereby striking a perfect balance between security and user convenience.

    By configuring the Pre-deployment user notification, you have the flexibility to include end-user convenience in your patch deployment tasks. Further, you can click and drag the pre-deployment user notification and put it after the activity of your preference. For instance, you can configure user notification to show after executing a custom script or before pre-deployment reboot and so on.

    Notifications can be configured for Windows and Linux endpoints. This feature was introduced in the Linux machines from build 10.1.2136.1

    patch deployment policy

    Step 4: Post-deployment activities:

    Once you have adequately configured how your deployment should take place, the next step is to configure what happens after patch deployment.

    deployment policy

    Custom scripts: You know what's best for your environment, we leave the choice to create a process that suits your work environment, to you. Create scripts to perform unique and environment-specific pre-deployment activities. For instance, patching servers has always been challenging, but with the option to add custom scripts before patch deployment, you can go ahead and write dedicated scripts to stop certain processes on servers before deployment, or perform sequential/cluster patching on servers.

    Some popular use cases of custom scripts are, to take snapshots of the machines before running a patch task, to check if any other service is running (validation purposes) and stop it, if it needs to be stopped before a patch task, to check if the backup server is ready before shutting down the primary server for patch deployment, the use cases are endless.

    Dependency file(s): If your scripts require additional files for execution, you can upload those additional files, in the Dependency file(s) section.

    deployment policy

    Post-deployment reboot/shutdown: Deployment of certain patches that are related to OS components, may force an immediate reboot; a critical operation for many environments especially when production servers are involved. Business-critical computers may have specific times at which changes and computer restarts are permitted. Here, the deployment of a software patch or any system restarts that are required should be scheduled. Patch Manager Plus lets you customize reboot policies post deployment.

    patch deployment policy

    Bearing in mind how essential rebooting a system is , there’s always a pressure on the sysadmins to ensure the reboot occurs successfully but also during the most convenient time thus not interrupting the enterprise’s productivity. Patch Manager plus’s flexible reboot policy helps achieve this by offering the following options for reboot:

    Force Reboot/Shutdown:

    Reboot/shutdown Immediately after deployment(within deployment window): If you want your system to reboot immediately after the deployment, you may enable 'Reboot Immediately after deployment'. On enabling this, the end user will receive a force reboot notification. Once the notification times out, the system reboots immediately. Hence, a system that's been configured to force reboot at 12PM with a notification time out of 5 mins, will receive the prompt for the same at 12PM and hence reboot at 12.05PM. If rebooting system during business hours is not your choice or if you want to be more specific about the reboot timings, you may schedule the force reboot timings in the reboot window (Reboot happens outside the deployment window).

    patch deployment policies

    patch deployment policies

    Specify Force Reboot Timings:

    • Specify reboot timings works exactly same as the reboot immediately after the deployment except for the fact that you can decide the timing for reboot as per your choice.
    • The reboot window allows you to choose the day(s) and the start and the end time within which you want the force reboot to take place. Sometimes, your system might miss a reboot as it might accidentally go into sleep/hibernate mode within the reboot window. Enabling the ' Immediately Reboot System When Next Active' allows your system to reboot immediately after it is awake. Else, the system waits for the next reboot window.
    • Hence, a system that's been configured to force reboot at 12PM with a notification time out of 5mins, will receive the prompt for the same at 12PM and hence reboot only at 12.05PM. (separate window for force reboot).

    patch deployment policy

    Delay Reboot/shutdown:

    • As an admin you may want to leave it to the end users as to when their respective systems should reboot. Delay reboot allows the end user to postpone the reboot until a specific time.
    • You can simply specify the day(s) and time after which you want to show the first reboot prompt to the end user.
    • As the end user receives the first reboot prompt he may either want to reboot at the moment or postpone the reboot according to his convenience. Hence, on choosing the postpone option, the end user can select one of the time intervals that appear on the agent window.
    • Based on the chosen timing, the reboot prompt reappears. For example, if the end user chooses 15 minutes, he will receive a reboot prompt again after 15mins from when he received the first reboot prompt.
    • Apart from the default time intervals shown on the server side window, you can also allow the end user to specify their time of convenience for reboot by enabling the 'end user defined time'.
    • You can configure the reboot in such a way that if the reboot prompt is left unnoticed for 'x' mins since it appeared, the system will automatically reboot once the notification times out.

    Reboot notifications are available on Windows and Linux machines. This feature was introduced in the Linux machines from build 10.1.2136.1

    patch deployment policy

    patch deployment policies

    Note : The customization in postpone time intervals is available only in Windows and Linux. For macOS, the postpone time intervals are set to 15 minutes, 1 hour, 2 hours and 4 hours by default. Also, the user alert before a force reboot is by default set to 5 mins for macOS, this customization is also allowed only in Windows.

    The postpone time intervals that are shown to the end user is dependent upon the force reboot timing (if configured by you). For eg. If you have configured force reboot on a system after 4 hours from when the first reboot prompt was shown, then, the end user will be shown options to postpone lesser than 4 hours.

    Configuring Force Reboot ensures that your system is rebooted even if the end user fails to do so. The force reboot prompt appears exactly after 'x' hours from when the first reboot was shown and the system reboots immediately after the notification times out. Reflecting the correct status of the patches (post patching) is important. If you choose to shutdown your system post patching, you may enable the 'restart and shutdown' option. This ensures that your system reboots in order to reflect the exact status of the patches before the system shuts down.

    Role-based access

    You can further fine-tune the deployment process to align with your specific needs by configuring the deployment settings. By customizing this setting, you can ensure that only authorized users with the necessary roles can modify the deployment policies. The deployment policies are associated with various configurations and tasks related to the deployment process and modifying these policies should be limited only to authorized users with the necessary roles and permissions. Users with the appropriate roles such as Administrators, Policy owners and Patch Management Write access are granted the privilege to modify deployment policies. The ability for only authorized users to modify the deployment policies helps in maintaining the consistency of the endpoint's deployment process.

    patch deployment settings

    FAQs

    1) Why did the deployment task fail to run during the deployment window?

    If the system wasn't active or in sleep/hibernate mode during the deployment window, no tasks or policies will executed. Ensure that the machine is live during the deployment window.

    2) Why are only certain selected postpone intervals for the Delay reboot/Delay shutdown prompt being shown, while the others are not?

    Only postpone intervals less than the duration of the force reboot/shutdown will be displayed if Display the force reboot/shutdown window after x hours option has been enabled.

    3) What is the reason behind multiple prompts to reboot/shutdown the machine?

    Ensure that the option Execute this post-deployment activity even when patch / Software deployment fails is disabled in your Post-deployment Activities. If enabled, a reboot / shutdown will be triggered at every patch/software installation attempts.

    4) Why wasn't the machine rebooted, even though the patches were installed on it and the reboot policy was configured?

    Verify if the Skip reboot, for machines that do not require a reboot option is enabled. If enabled, machines will only be rebooted when at least one patch that has been installed and is marked as Reboot required.

    5) After the machine was rebooted, how to check which task/deployment policy triggered the reboot?

    The details of the task/deployment policy responsible for the latest machine reboot can be found in rbtHist.json file stored in the logs folder.

    Note: Reboots triggered via the Tools tab will not be recorded by this JSON.

    6) How do I check all the pre-deployment and post-deployment activities that have been executed on the machine?

    The list of activities executed can be found in dcprepostaccess.csv file stored in the logs folder.

    7) Why did a prompt appear while initiating machine shutdown/reboot, despite not having any notifications/prompt configured?

    If a task is being processed by the agent, any attempt to initiate shutdown/reboot will be blocked and a prompt will be displayed.