Best Practices for Windows Update Policies
Table of Contents
Before You Begin
Here are some important things to know before you begin setting up your Windows Update Policies.
Multiple Schedules On One Machine
It's technically possible to have multiple update schedules that apply to a Syncro Device. For example, if an update category is Deferred on one policy but Approved on another. This may cause unintended behaviors, so heed the multiple settings warning in the Windows Update Management section of the Policy Builder:
See also: Override Update Schedules.
Reboots
When setting a time for reboots on Weekly and Monthly Schedules, make sure the time set in the “Reboot by” dropdown menu is for the same day that the Windows Update Schedule runs. For example, if updates run Weekly on a Sunday at 11 p.m. and the reboot is specified for 1 a.m., the reboot will not run until the following Sunday at 1 a.m.
IMPORTANT: A misconfiguration here can lead to updates being installed unintentionally or updates being missed unintentionally.
WSUS/GPO Interoperability
Syncro's Windows Update Policies can work alongside WSUS (Windows Server Update Services) which is a part of Windows Server operating systems. WSUS can be configured to monitor and control all aspects of Windows Updates including reboots, schedules, how and when updates are applied, etc.
Granular control is available in WSUS and it has the ability to override Microsoft policies. Syncro Windows Update Policies can invoke starting updates and assist in controlling their cycles. However, Syncro is unable to stop an Asset from rebooting if Microsoft’s update timer expires, and Syncro cannot prevent Microsoft products from downloading their own updates (e.g.: Windows Defender, Office products, etc. This control is provided by WSUS and GPO.
Application Update Cycles
Syncro uses the Windows Update API, which does not have the authority to modify application update cycles. For example, Windows Defender may automatically update definitions without prompting from the Syncro Agent.
This is often the cause when Syncro reports that an update ran at a time that is different than the time scheduled in the Policy. In the following image, the Policy for the Asset is set to update on Sunday mornings and the Asset updated on Monday:
Policy Constraints & Additional Considerations
-
Policy Constraints:
- A Windows Update Policy in Syncro does NOT supersede Microsoft pushed updates.
- Syncro's Windows Update Policy will yield update control to GPO Policies applied to the Asset(s).
- Deferred Patch Time Periods: These begin on the release date of the update, NOT on the scheduled Windows Update Policy date.
- Performance: If you check the “If offline, run at next boot” box, this may cause system slowdown due to the updates being downloaded and installed during business hours.
Best Practices
Tip: Be sure to also review our Examples of Windows Update Policies.
Test Windows Updates
Test your Windows Updates before deploying them to your production environments. Having a test device(s) with daily updates in the morning and evening of the same day can help catch problematic updates. Mimicking client environments can help ensure that tests are reflective of real-world deployments.
Enforce Scheduled Reboots
A Windows machine pending a reboot for any reason can block the install of new updates.
To help enforce scheduled reboots:
- Check for Devices Requiring Reboots: Despite the automatic reboot set on a Windows Update Policy in Syncro, there may be times when an Asset is pending reboot because of something else. For example, installing a third-party application might require a computer to be rebooted before the installation is complete. Identify Syncro Devices that haven't been rebooted using the "Pending Reboot Assets" Custom Asset Search.
- Give End Users a Heads Up: Warn users that their work should be saved before the end of the day. You can schedule this message for a few hours before the scheduled reboot (or to display several times on that day). You can do this in our Policy Builder using the option “Prompt the user for the reboot with a message” or use a Broadcast Message in a Script.
- Schedule Reboots After Patch Tuesday: Microsoft regularly produces updates every 30 days that require systems to be rebooted to complete the update install. Often this happens on Patch Tuesday. Scheduling reboots after Patch Tuesday can be a great way to prevent subsequent updates from being missed, and prevent an update trying to reboot a system at an unintended time. If you have a machine online with a last boot time 45+ days ago, it's very likely behind on installed updates. (See also: Enforcing Compliance Deadlines for Updates.)
Create Uniform, Manageable Schedules
Two (2) to four (4) schedules is a reasonable number to keep them as manageable and uniform as possible. You can build your schedules based on the Syncro Device type (e.g.: Workstation Daily, Servers Monthly, Laptop Weekly) or based on Update Category (e.g.: Daily Security and Critical, Weekly Updates All Categories).
Ensure Manual Approvals Are Done
When you select “Manual” for any Severity or Category Approvals, you must schedule time for a human to manually review and approve the updates. Otherwise, updates will wait indefinitely and machines will NOT be updated.
Tip: Use the Patching Dashboard, the Vulnerable Systems Report and Missing Patches by KB Report to see what needs approval and manually select the updates for install.
Override Update Schedules
You can use the Policy Inheritance structure to remove or “override” applied update schedules. This is good for one-off cases; it gives you flexibility without having to dramatically changing your policy set up.
Here's an example:
When this policy is assigned directly to an asset (e.g., FIN-DANFINITY), that asset will dis-inherit the “Weekly Saturday” and “Default or Starter" update policies (shown above) that are assigned via the Staging Policy (shown below), leaving only the “Workstation Daily” update policy assigned:
