Deployment Policy

Deployment Policy and its Need

A Deployment Policy is an end-to-end customized policy configured by IT administrators to deploy patches according to the enterprise's needs. It helps design a user-specific patching policy, enabling an effective patching system across all endpoints managed by the enterprise, regardless of location.

When deploying software or a patch using Endpoint Central, you can specify various Deployment Settings such as installation timing, user permissions to skip deployments, and reboot policies. These settings can be created as Policies and used when defining configurations or tasks. Any policy can be marked as a default policy, so it applies by default to all subsequent configurations or tasks created.

There are several ways to create deployment policies: Policies can be created from the Deployment Policies page. You can access the Deployment Policies page by Navigating to Threats and Patches -> Deployment -> Deployment Policies

Wake on LAN applies to:

• Windows

Pre-deployment activities apply to:

• Windows
• Linux

Post-deployment Reboot/Shutdown applies to:

• Windows
• macOS
• Linux

Post-deployment Custom Script applies to:

• Windows
• Linux

Deployment Schedule

Each enterprise has unique rules and regulations with a customized working pattern to maximize returns. Patch deployment might sometimes hinder system productivity due to high bandwidth consumption. To avoid this, the admin can customize the deployment schedule.

To do this,

1. Click Create Policy under Deployment Policy.
2. Specify a name for the policy.
3. Preferred week split offers two options: Regular Split and Patch Tuesday.

Patch Tuesday Week Split

Patch Tuesday is the day Microsoft rolls out its scheduled updates, and IT teams generally focus on reviewing, testing, and beginning deployments.

Patch Tuesday falls on the second Tuesday of every month. The week in which it occurs is known as the Patch Tuesday week.

The weeks after Patch Tuesday are then referred to in sequence. 1st Week After Patch Tuesday is the Tuesday to Monday after the Patch Tuesday week. 2nd Week After Patch Tuesday is the Tuesday to Monday after the 1st Week After Patch Tuesday, and this continues until the next Patch Tuesday cycle begins.

For example, in April 2027, Patch Tuesday falls on April 13.

Patch Tuesday split option	Date range
Patch Tuesday week	April 13 — April 19
1st Week After Patch Tuesday	April 20 — April 26
2nd Week After Patch Tuesday	April 27 — May 3
3rd Week After Patch Tuesday	May 4 — May 10
Last Week Before Next Patch Tuesday	May 4 — May 10

Here, Patch Tuesday week starts on Patch Tuesday and continues until the following Monday. The following Tuesday to Monday period is counted as the 1st Week After Patch Tuesday, the next Tuesday to Monday period is counted as the 2nd Week After Patch Tuesday, and so on.

Last Week Before Next Patch Tuesday refers to the final Tuesday to Monday period before the next month’s Patch Tuesday. In this example, the next Patch Tuesday falls on May 11, 2027, so May 4 — May 10 is considered the Last Week Before Next Patch Tuesday.

This structured split helps admins plan patching activities in phases. Teams can review and test updates during Patch Tuesday week, move patches to wider deployment in the following weeks, and complete monitoring or stabilization activities before the next Patch Tuesday cycle starts.



Regular Week Split

In a regular month, weeks are simply counted as Week 1, Week 2, Week 3, and Week 4 depending on the month. This is a straightforward calendar-based split without tying it to any event.

For example, consider April 2027:

Regular split option	Date range
Week 1	April 1 — April 7
Week 2	April 8 — April 14
Week 3	April 15 — April 21
Week 4	April 22 — April 28
Last week	April 24 — April 30

Here, Last week refers to the final week of the selected month. In this example, the last week of April 2027 is April 24 — April 30.

In Regular Week Split, Last week can also act as the 5th week when the month extends beyond four weeks. Depending on how the dates fall in a month, Last week may also overlap with Week 4.

For example, in April 2027, Week 4 is April 22 — April 28, while Last week is April 24 — April 30. This means the dates April 24 — April 28 fall under both Week 4 and Last week.

This option is useful when admins want to target deployments toward the end of the month, regardless of whether the month has four full weeks, five weeks, or a shorter final week.


4. Specify the Deployment Window, which is the time interval for deployment on the client computer. You can specify an interval between 3 hours and 24 hours. It is recommended to provide a minimum of 3 hours to ensure the agent communicates with the product server at least once during this window to receive inputs for initiating the deployment.
5. The option to enable "Download patches from server to agent" can be configured during the deployment window or when the agent contacts the server.
6. Deployment can be initiated during the system startup or refresh cycle.
   

   Configuring Pre-Deployment Activities

   To deploy configurations to computers that are turned off, enable the "Automatically wake computers before deployment" checkbox. This option allows administrators to deploy configurations to target computers within the network but currently powered off. If the target computers are connected to the corporate LAN/WAN, they will be powered on using the Wake On LAN feature, and the configuration will be deployed. This feature is not applicable to computers outside the corporate LAN/WAN. The Wake On LAN functionality operates based on the local time zone of each computer.

   Pre-Deployment Reboot settings can be configured to suit specific requirements. Administrators can exclude servers from rebooting to minimize system downtime and skip reboots for machines that don't require them. Additionally, users can be notified about upcoming reboots through a customized notification message.

   Custom Script option can be used to perform a set of functions before patch deployment is about to happen. In your organization, in one of your endpoints, if there is a specific application running and you want to close that application right before the deployment is about to happen , you can create a custom script accordingly and then upload the script to the script repository. Then, under this option, you can import the script post which Script Arguments, Dependancy Files and Exit Codes needs to be specified.

   

    

   The Pre-Deployment User Notification settings can be configured as follows:

   1. Provide the "Title of the Message" to be displayed on client computers before deployment begins.
   2. Enter the message content to inform users prior to deployment.
   3. The notification message will appear on client computers based on the duration specified in the Notification Timeout section.
   4. Specify whether users can skip the deployment by selecting the "Allow Users to Skip Deployment" option. If this option is not selected, deployment will proceed without user control.
   5. To display the deployment progress on client computers, enable the "Show deployment progress on the client systems" option.
   6. Define the number of days after which deployment will be forced. This allows users to skip deployment only for the specified period, after which it will automatically proceed.
   7. Set the time limit for deployment to begin if the system remains idle.

   

   Configuring Post-Deployment Activities

   1. As part of post-deployment activities, the Reboot/Shutdown settings for systems can be configured. Administrators can choose between a Force reboot/shutdown or a Delay reboot/shutdown option. Additionally, the reboot/shutdown time can be specified. Users can be notified about the reboot/shutdown through a customized notification message. An option to "Restart and then Shutdown" the systems is also available for configuration. Custom script option is given as a post deployment activity too, which you can use for performing a set of functions post patch deployment such as restarting the applications which were earlier closed using the pre-deployment custom script. Similar to Pre-deployment Custom Script, after importing the necessary script, even here the options such as Script Arguments, Dependancy Files and Exit Codes needs to be specified.
   2. Select Save to apply the changes.

   

   The deployment policy has been successfully created and can be applied to any configuration. To modify or delete the policy, use the Actions button.

   Notification displayed on the End-User's Device

   Windows

   

    

   Mac

   

   Role-based access

   The deployment process can be fine-tuned to meet specific requirements by configuring the deployment settings. Customizing these settings ensures that only authorized users with the necessary roles can modify deployment policies. These policies are linked to various configurations and deployment tasks, and restricting modifications to authorized roles helps maintain consistency in the endpoint deployment process. Roles such as Administrators, Policy Owners, and those with Patch Management Write or Software Deployment Write access are granted the privilege to modify deployment policies. Limiting this capability to authorized users ensures the integrity and reliability of the deployment process.

If you have any further questions, please refer to our Frequently Asked Questions section for more information.