Best practices for Patch Management

As of December 2016, a Security-only Quality Update is not offered on a PC where a Monthly or Preview Rollup from the same month or later is already installed. For example, if a PC attempts to install the February 2017 Security-only Update and the February 2017 or later Monthly or Preview Rollup is already installed, the Windows Update client will report the Security-only Update as not applicable.

NOTE  This affects WSUS users only, as Security-only Updates are not offered on Windows Update.

As of February 2017, the Security-only Update does not include updates for Internet Explorer (IE); the IE update is available as a separate update. Again, this affects WSUS users only, as Security-only Updates are not offered on Windows Update. The Monthly Rollup includes updates for IE as a single additive update that provides all security and reliability fixes since the beginning of the new servicing model in October 2016. Users of the Monthly Rollup will not need to install the separate IE update. To simplify installation for Monthly Rollup users, the new IE update leverages the same installation applicability definition as the Security-only Update, meaning that it will not install on a PC that has already installed the Monthly or Preview Rollup from the same or later month. Months with no new Windows security or reliability fixes will not have a Security-only or Monthly Rollup release. For example, January 2017 for Windows 8.1, Windows Server 2012, and 2012 R2.

The following are some guidelines to consider when creating your Patch Management policy rules. Each customer is different, and some of these recommendations may not apply to your specific scenario.

• Decide on a schedule and reboot strategy that suits your customer's requirements.
• Identify servers that cannot be automatically rebooted and log a reboot ticket for a manual restart (this can be monitored using the Reboot Required Monitor component).
• Approve only patches that contain criteria that cover the patches required in the title, such as Rollup or Security, and deny any patches that include the word Preview.
• Remove all your individual approval rules based on severity, classification, KB number, and so forth as they are no longer applicable.
• Identify KBs that should not be installed for various customers (possible 3rd party software issues).
• Keep any Do Not Approve rules you may have in place, as individual patches released prior to October 2016 are still available, although they will be removed over time.
• Do not approve anything else until you have rolled out the latest Monthly Rollup. Remember that subsequent Monthly Rollups are cumulative and supersede the previous one, so there will only ever be the latest Monthly Rollup available.
• Create one policy for desktops and one for servers at the account level and, if needed, implement overrides at the site level.
• Keep it simple by targeting Operating Systems for policies. If further granularity is needed, enter the word Patch in one of the device User Defined Fields (UDFs) and target a policy by filtering on this word. You may need separate Legacy Desktop and Legacy Server policies if you still have XP or Windows Server 2003.

• Once you have rolled out the latest Monthly Rollup, consider also approving Critical patches. This will install any pre-October 2016 Critical patches missing from any of your devices.
• Set the start of your patch window at a time when you would expect devices to be online; so long as the device comes online anytime in the patch window, the Patch Management policy will run. Consider a daily desktop and laptop schedule to ensure patches roll out quickly until you get all of your devices up to speed. Even though the schedule is daily, devices will still only install once. Set a reboot reminder if necessary.
• Make your patch window at least four hours long, as some devices are slow.
• If you have Microsoft Office in your environment, you'll need to add a rule to approve anything with the word Office in the title. If you do this, consider adding an explicit Driver denial rule to prevent HP Officejet driver updates from being deployed unexpectedly.
• Remember to check the Reboot Required filter for devices that may have escaped the reboot process. A shutdown at the end of the day and startup in the morning is not a reboot, and patches will not install even though users may think they do. Windows must be explicitly rebooted for this to happen. If you have user devices requiring reboots, consider sending a message using the message feature in the Action Bar.
• You have the option of delaying updates. If you have concerns that Microsoft may release a bad patch, it may be a good idea to set a delay in the Patch Management policy. To receive necessary patches, ensure the delay you set does not exceed the release cycle for patches.

• Installing drivers via Patch Management is not recommended, as some drivers may fail to install if user interaction is required during the installation process.
• Due to the Windows requirement that some drivers must be installed as 'current user', it is not possible to install drivers via Patch Management on Windows 7 machines.
• It is recommended to deny driver installations in Patch Management policies, as the driver types can include network and display drivers, which could render a device unusable if an installation fails.

NOTE  For some devices, such as Microsoft Surface devices, drivers can only be installed via Windows Update. In such cases, we recommend setting up a separate Patch Management policy in which you specify the installation of drivers. This will avoid conflicts with other devices and drivers being installed incorrectly.

NOTE  Driver patches may show as available to devices but they do not show as installed in the patch information once deployed. This is because patch audits echo what is presented by the Windows Update API, which typically displays available driver updates for convenience but does not show them in the installed group after they have been applied.