This may be more of a sanity check here so please bear with me. So my boss has decided that for our company of about 675 workstation endpoints we're going to go fully on manually approving Windows patches. I know, it sort of defeats the point of automation. ¯\_(ツ)_/¯
So my plan is to have all of my workstations set on approval only for all of the patching, run a monthly scan at the beginning of the month so the list of available patches gets updated, we have our review of the patches and such and manually approve the ones we want to deploy and then have a 2nd scan later in the month that actually deploys the updated approved patch list. In our case it'd probably be a scan for a specific group a week after we meet as a POC that it doesn't break anything, then a third scheduled scan for the rest of the endpoints that'll deploy to everyone else.
Don't get me started on us "working" on the plan for the servers.
gbarnas, Oh I'm 100% with you with the Patch Policies. I originally had them set for mid month for a test group to verify that it wouldn't cause issues with anything and then the rest of the organization at the end of the month. My logic was this way if a bad patch got out I'd be halfway through the month and it'd be removed by then. Servers I'm not in charge of so the server admin asked that I put everything in Approval mode until we could come up with a patch policy.
My boss on the other hand wants to be more conservative with this. Although the good news is myself and the server admin are two thirds of the security group and we're the ones coming up with the policies for approval by our boss and the director. We've basically got them convinced that patch policy is a good thing although we're still working out the alpha group for the first pass test and the schedule for the times.
So basically I'm going to have two sets of scan schedules, one for my test group of about 12 and one for the rest of the company.
Trevor - I'm withholding comments regarding sanity of this approach. :)
Leverage patch policies! Here's the general process:
Baseline - auto-approve EVERYTHING EXCEPT things you never want to deploy like add-on software (Zune!) - these are auto-deny.
Workstations - Auto-approve all security, critical, and important updates, set others to Pending so they can be reviewed. These are usually the ones that cause issues anyway.
Servers - same as above
Now you just review the Pending items and review/approve. There are a couple of ideas here, but if you want to be cautious, only review/approve updates 30+ days old by using the filter. Check the patch discussion sites for problems, consider denying those. Once you've denied what you don't want, approve the rest (keep the 30+ days filter on for that step!)
This fits 97% of the requirements for workstations and servers. There's no need to have separate policies for different O/S - the patching software is smart enough to apply things correctly. Don't work harder than you have to.
Next, you handle the exceptions/exclusions. If a customer is affected by dotNET or IE updates, you create a BLOCK policy and apply it to those specific orgs. These are (usually) easy - auto approve every category except where the updates appear. For IE or dotNET, they are in the Optional Software category. Win-10 updates can be anywhere - these are a PITA for that reason. Simply filter the Pending categories for the product name, select all updates and deny them. Remove the product filter, select all and approve. We have 10 such BLOCKING patch policies internally, and most of our MSPs use the same. Currently, only 4 of those 10 are applied to clients.
This method allows us to review and manage patching once each month in 45 minutes or less. We associate the two core policies (baseline and platform-type) to the org root via system policy, then create additional policies to add the other patch policies - these get linked to specific customer or site groups.
Workstations are a challenge because they aren't always on. We patch them weekly on Thursdays, display a reminder message from our Maintenance tool on Wednesday. We don't generate alerts for failed patches on workstations because they're usually for missed dependencies that are resolved the following week. We have three patch cycles with three patch windows for servers - week 3, 4, then 1. We deploy in least to most critical platform sequence, and group application sets into the same change window, and assign reboot/patch/reboot schedules based on the application boot order requirements. We have 9 or 12 time schedules per change window.
Finally, if we don't want patching at all, we have a specific SYSTEM policy to never schedule updates - we don't use a PATCH policy for no patching.
We'll be covering this in more detail in a free public seminar on Nov.15th - See Products/Training/Seminars menu on our website for info and registration. We see so many MSPs struggle with patching so we're making this available to the community.