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.
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.
To create a new policy, click on Deployment > Deployment policies > +Create Policy. The new policy creation process has four steps
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 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.
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 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.
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.
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.
If you try to wake a computer which belongs to a remote office, then one of the following criteria should be met:
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.
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.
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
Once you have adequately configured how your deployment should take place, the next step is to configure what happens after patch deployment.
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.
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.
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).
Specify Force Reboot Timings:
Delay Reboot/shutdown:
Reboot notifications are available on Windows and Linux machines. This feature was introduced in the Linux machines from build 10.1.2136.1
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.
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.
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.
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.
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.
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.
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.
The list of activities executed can be found in dcprepostaccess.csv file stored in the logs folder.
If a task is being processed by the agent, any attempt to initiate shutdown/reboot will be blocked and a prompt will be displayed.
