{"id":282,"date":"2023-10-06T08:36:44","date_gmt":"2023-10-06T14:36:44","guid":{"rendered":"https:\/\/tekweis.com\/?p=282"},"modified":"2024-06-10T06:43:08","modified_gmt":"2024-06-10T12:43:08","slug":"monthly-patching-schedule","status":"publish","type":"post","link":"https:\/\/tekweis.com\/index.php\/2023\/10\/06\/monthly-patching-schedule\/","title":{"rendered":"Monthly patching schedule"},"content":{"rendered":"
\n
\"\"<\/figure>\n<\/div>\n\n\n
\n

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!<\/strong> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

I’ve been using Action1<\/strong><\/a> 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<\/a> configuration I use, but the scheduling will match to my normal overall strategy.<\/p>\n\n\n\n

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.<\/p>\n<\/div><\/div>\n\n\n\n

Workstations – Automated patching. Daily. 6am. No reboot.<\/strong> Low risk to workstation users.<\/p>\n\n\n\n