Systems Management

I work at Dickinson College and we put together page that informs users of our update policies. The answers to questions 1, 2, and 3 for all of our scenarios can be found on that page:

https://www.dickinson.edu/info/20198/technology_services/2213/technology_policies_and_best_practices/18

We stop Windows from managing updates via group policy. We are, however, moving towards using Group Policy to control updates in a more granular manner to supplement patches coming from KACE. In particular controlling the Feature Updates and when they are applied. We also use Group Policy to set the Office update channels to establish early adopters/testers and production computers.

We took a lot of time to develop the schedules and their settings and collected feedback from users. Working in a higher education environment makes it more difficult for us to just put policies in place than corporate, but raising the importance of security helped. 

Dickinson is also highly focused on sustainability with a goal of being carbon neutral by 2020, which meant balancing when computers are powered on with our patching requirements. We push BIOS power on settings using Dell CCTK to match when machines should be on for patching and also use energy policies to hibernate machines. The smart labels which push those settings are configured to allow exceptions and only apply where necessary, e.g. we don't set laptops to power on for patching.

I recommend setting up a default patching schedule in this manner:

Create a smart label that includes any machines that don't have a label applied that ends in "Patching" (We call this label "Patch Production")

Create other labels for your patching schedules that end with the word patching, e.g. "Lab Patching", "Admissions Patching" (they're special), "Test Patching", etc. And yes, we even have a "No Patching" label for very special people.

This setup automatically places machines into a default patching schedule and our technicians then add the necessary labels to those machines which require exceptions. Those patching labels can also be smart labels, e.g. computers in the Admissions department are in the Admissions OU, an LDAP label is applied to those machines and a smart label applies the Admissions Patching label to the machines with the Admissions Department ldap label.
 

Every environment needs other patching setups.
In my env I have most of the devices locally and they are avaiable daily. (not every system but most of them)
I have also some systems externally with a very irregluar pattern, when they are online.
The Appliance is open to the public, so no VPN etc nessesary.

1. for the local systems I run a detect every tuesday morning (8:00, start if it comes up later and stop at 14:00) and a deploy every friday before the end of the shift (15:00, and stop at 22:00); for the remote label ones the same daily.
2. I notify them if a reboot is nessesary.
3. I prompt 5 times with a delay of 3hr
4. The KACE has a setting, which can disable that.
5. (your second 4) determine how it fits well in your environment and the work schedules of your colleagues. Since this is different in every env.

Even the kind of patching is different.
I personally don't patch with labels but deny to install software installers with slightly different settings, which works well for me but may be a problem in other envs.
The latest major versions are maintained with MI/Scripts