4

My Organization has a maintenance window between 4-8am every Sunday Morning. We have an OU structure setup to spread our production servers out for reboot during this scheduled time (example Reboot4-5, Reboot5-6, Reboot6-7, etc). We have GPOs on each one of these OUs with the Following settings to take care of the reboot during this time. Here is an example of some of the settings:

Configure Automatic Updates: Enabled 
Configure automatic updating: 4 - Auto download and schedule the install 
Install during automatic maintenance   
Scheduled install day:  1 - Every Sunday 
Scheduled install time: 05:00 

No auto-restart with logged on users for scheduled automatic updates installations: Disabled  
Reschedule Automatic Updates scheduled installations: Enabled  
Wait after system 
startup (minutes):  15 

On all of our 2008R2 to 2012R2 servers this is working perfectly. On our 2016 servers it appears that Updates are being applied, but the servers are not automatically rebooting. They are all pulling updates from a local WSUS server.

When logging in and looking at the Windows Update section of settings it says that the device is scheduled to reboot, but it has not rebooted. A few moments after logging in a message pops up saying that the server will reboot in 15 minutes (which it doesn't if I remain logged in). Even looking at the restart options the section is grayed out with the proper time and noted that theses settings are controlled by your organization.

Sconfig settings show that updates are automatic. Looking at GPO Result on the Servers show that the GPO is being applied and is not overridden by any other GPOs. I tried to look for any depreciated features for this, but I have not found too many similar issues to this one and people are still suggesting this methodology for updating 2016.

Are there any further steps I could take to diagnose this? And are there any known issues with rebooting 2016 at a scheduled time? (I remembering there being an issue with 2012R2 last year).

joshcorr
  • 41
  • 4
  • Just curious: With what user is the task defined to be run? Is it the built-in "System" or some local or domain user? If it's something else than the "system" account, try to change it into that. – ptr2n0 Sep 18 '17 at 13:52
  • This task doesn't 'run' as anyone, it is rather a Group Policy, so I believe it is already running under the 'system' context. – joshcorr Sep 21 '17 at 17:46
  • I wonder if a local group policy setting may be causing the issue? gpedit.msc, right-click administrative templates, Filter Options, Configured=Yes, OK, expand admin templates, click All Settings (under Comp config & User Config) – gregg Dec 15 '22 at 16:37

0 Answers0