I am often asked how I perform security and third-party patching for an entire company. Below is the basic outline I am currently using, and this has not varied very much in over 15 years from any other company I have maintained 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 still, testing first, doesn’t hurt and could save you a major headache in the long run.
The reason for testing is to ensure no disruption to any business. For example, if many of the endpoints are located in restaurants and patching the point-of-sale system and other critical machines required for the business to operate, you will want to make sure those endpoints are always available. If those endpoints are not running, that can cause an immediate loss of business to a location(s) financially.
Workstations Automated patching. Daily. No reboot. Low risk to workstation users.
- Microsoft Teams
- Webex
- Zoom
The above is set to run daily at 3:30am. Catch up with missed endpoints set to 24 hours.
Workstations and Servers Automated patching. Daily. No reboot.
- Defender Antivirus – Definition Updates
- Windows Malicious Software Removal Tool* – Update Rollups
Monthly Patching Servers and workstations.
- All updates are manually approved. Reboots allowed.
- 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 down at same time during patching/reboots.
Server considerations
- Do not deploy to 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 to ensure quick rollback if needed.
The above is my outline for patching an organization regardless of size. I hope this helps when 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.