I am often asked how I perform security and third-party patching for an entire company. Below, I have outlined the basic strategy I use, and this has not varied much in the past 15 years from every company where I have been responsible for maintaining the patching in regard to Windows servers and workstations. First off, I always test patching before roll-out. Period! I never assume every update installs without issue. Patching processes these days are much more reliable than they used to be, but sometimes a patch or an updated application can cause issues. Testing first doesn’t hurt anything and ensures the patching doesn’t have any conflicts with applications and operations, which could save you a major headaches in the long run.
To explain my reason for testing is to ensure no disruption to business. For example, if many of the endpoints that you are patching are located in restaurants, such as the point-of-sale system or other critical machines required for business to operate, you will want to make sure those endpoints are always available, and that a patch or update does not cause problems for those devices to operate. If those endpoints are not running, that can cause an immediate loss of business to a location(s) financially. You don’t want to find out a patch or an updated application doesn’t play nice until too late.
I’ve been using Action1 as my patching platform for the past couple of years and have been impressed with the flexibility and ease of keeping the entire company up to date. The below details will be shown from the Action1 configuration I use, but the scheduling will match to my normal overall strategy.
With all that I mentioned about testing updates before deployment, I do have a small handful of application updates that I will deploy as soon as they are available. These are mostly workstation applications for users and not OS security or production applications for business-critical needs.
Workstations – Automated patching. Daily. 6am. No reboot. Low risk to workstation users.
- 1Password
- Adobe Acrobat Reader*
- Microsoft Edge*
- Microsoft Teams*
- Teams Machine-Wide Installer*
- VLC*
- *Webex*
- XNView*
- Zoom*
Workstations and Servers – Automated patching. Daily. 6:15am. No reboot.
- *Defender Antivirus*
- Windows Malicious Software Removal Tool*
Monthly Patching – Servers and workstations.
All updates are manually approved. Reboots allowed. Patching is done manually, no automated schedules.
- Updates deployed to lab/dev/qa system endpoints first. Verify no issues with functionality for 24 hours.
- If no issues from lab endpoint patching. Update to pilot group of live sites for 24 hours. Pilot workstation group includes IT department workstations.
- If no issues from pilot group. Deploy to all workstation endpoints.
- If multiple endpoints at remote sites, do not deploy to all endpoints, break up patching into groups to ensure not all endpoints will be affected at same time during patching/reboots.
Server considerations
- Do not deploy to a master domain controller first. Apply to a secondary domain controllers, then patch master domain controller on following day.
- Server patching done outside business hours. Must have IT staff monitoring patching to ensure all servers operational after patching.
- Snapshot all VM’s before patching or patch after backup routines to ensure quick rollback if needed.
I hope this provides some visibility into my patching strategy and helps you with coming up with your own patching cycle. Every patching cycle should be strict and consistent to minimize risk to any organization, but yet flexible to work around business needs.