Windows Update GPO

%3CLINGO-SUB%20id%3D%22lingo-sub-1225572%22%20slang%3D%22en-US%22%3EWindows%20Update%20GPO%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1225572%22%20slang%3D%22en-US%22%3E%3CP%3EWe%E2%80%99re%20in%20the%20process%20of%20switching%20patching%20policies%20away%20from%20our%20RMM%20product%20to%20group%20policies.%20While%20the%20patching%20seems%20to%20be%20working%20pretty%20effectively%20we%E2%80%99ve%20had%20mixed%20results%20in%20regards%20to%20reboot%20actions.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIdeally%20we'd%20like%20to%20be%20able%20to%20reboot%20at%20a%20fixed%20time%20but%20it%20doesn't%20look%20like%20this%20behavior%20can%20be%20controlled%20via%20GPO.%20We%20also%20would%20like%20to%20be%20able%20to%20manage%20this%20via%20single%20GPO%20for%20all%20workstations%2C%20whether%207%20or%2010%20(and%20different%2010%20builds).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETarget%20systems%3A%20workstations%20only%3B%20Windows%2010%20and%20Windows%207%20for%20the%20most%20part.%20We%20also%20still%20have%20a%20large%20number%20of%20Windows%2010%20endpoints%20are%20still%20running%201803%20or%20below.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBusiness%20hours%3A%205am-11pm%20hours%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECritical%20component%3A%20reboot%20actions%20%E2%80%93%20ideally%20rebooting%20ONLY%20outside%20of%20business%20hours%20automatically%2C%20but%20give%20users%20the%20option%20to%20schedule%20it%20(and%20more%20importantly%20to%20provide%20them%20visibility%20when%20the%20endpoint%20is%20going%20to%20be%20rebooted)%2C%20then%20IF%20a%20deadline%20(few%20days)%20has%20been%20reached%20to%20reboot%20the%20endpoint%20to%20finish%20applying%20the%20patches.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAdmin%20templates%20for%201909%20are%20in%20place.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20biggest%20question%20at%20this%20stage%20is%20the%20behavior%20when%20several%20patches%20are%20older%20than%20the%20deferral%20period.%20Especially%20for%20feature%20updates.%3CBR%20%2F%3EAs%20previously%20mentioned%20we%20have%20a%20significant%20portion%20of%20endpoints%20still%20below%201803%20which%20is%20well%20over%20365%20days%20deferral%20we%20have%20setup%20for%20feature%20updates.%3C%2FP%3E%3CP%3EWe%E2%80%99ve%20seen%20some%20users%20report%20their%20system%20simply%20reboot%20w%2Fo%20any%20warning%20(looking%20at%20the%20logs%2C%20it%20appear%20that%20feature%20updates%20were%20the%20culprit).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20tried%20to%20leverage%20the%20following%20GP%20components%20and%20are%20questioning%20the%20way%20they%20apply%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%E2%80%9CSpecify%20Engaged%20restart%20transition%20and%20notification%20schedule%20for%20updates%E2%80%9D%3A%3CBR%20%2F%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20the%20way%20we%20understand%20this%20is%20that%20by%20specifying%200%20days%20transition%2C%20we%20flip%20to%20%E2%80%9Cengage%20restart%E2%80%9D%20which%20would%20prompt%20the%20user%20to%20reboot.%3CBR%20%2F%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3BAfter%205%20days%20(with%201%20day%20snooze%20period)%20the%20machine%20would%20be%20restarted%20IF%20the%20user%20has%20not%20taken%20any%20actions.%3CP%3E%26nbsp%3B%3C%2FP%3E%E2%80%9CSpecify%20deadlines%20for%20automatic%20updates%20and%20restarts%E2%80%9D%20(only%20applies%20to%20Win10%201903%20and%20above)%3A%3CBR%20%2F%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3Bwill%20override%20the%20Engaged%20Restart%20policy%E2%80%A6%20does%20this%20apply%20to%20all%20endpoints%20of%20only%20on%20machines%201903%20and%20above%20(can%20both%20be%20used%20together)%3F%3CBR%20%2F%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3BHow%20are%20the%20deadlines%20determined%20(patch%20release%20date%20or%20wu%20scan%20and%20will%20it%20take%20into%20account%20the%20deferral%20policy)%3F%3CP%3E%26nbsp%3B%3C%2FP%3E%20%20%26nbsp%3B%E2%80%9CTurn%20off%20auto-restart%20for%20updates%20during%20active%20hours%22%3A%3CBR%20%2F%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3Bthe%20idea%20would%20be%20to%20prevent%20reboot%20between%205am%20and%2011pm%20but%20doesn't%20appear%20to%20be%20respected%20all%20the%20time.%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1225572%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EActive%20Directory%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWindows%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Occasional Visitor

We’re in the process of switching patching policies away from our RMM product to group policies. While the patching seems to be working pretty effectively we’ve had mixed results in regards to reboot actions.

 

Ideally we'd like to be able to reboot at a fixed time but it doesn't look like this behavior can be controlled via GPO. We also would like to be able to manage this via single GPO for all workstations, whether 7 or 10 (and different 10 builds).

 

Target systems: workstations only; Windows 10 and Windows 7 for the most part. We also still have a large number of Windows 10 endpoints are still running 1803 or below.

 

Business hours: 5am-11pm hours

 

Critical component: reboot actions – ideally rebooting ONLY outside of business hours automatically, but give users the option to schedule it (and more importantly to provide them visibility when the endpoint is going to be rebooted), then IF a deadline (few days) has been reached to reboot the endpoint to finish applying the patches.

 

Admin templates for 1909 are in place.

 

The biggest question at this stage is the behavior when several patches are older than the deferral period. Especially for feature updates.
As previously mentioned we have a significant portion of endpoints still below 1803 which is well over 365 days deferral we have setup for feature updates.

We’ve seen some users report their system simply reboot w/o any warning (looking at the logs, it appear that feature updates were the culprit).

 

We tried to leverage the following GP components and are questioning the way they apply:

 

  • “Specify Engaged restart transition and notification schedule for updates”:
              the way we understand this is that by specifying 0 days transition, we flip to “engage restart” which would prompt the user to reboot.
               After 5 days (with 1 day snooze period) the machine would be restarted IF the user has not taken any actions.

 

  • “Specify deadlines for automatic updates and restarts” (only applies to Win10 1903 and above):
         will override the Engaged Restart policy… does this apply to all endpoints of only on machines 1903 and above (can both be used together)?
         How are the deadlines determined (patch release date or wu scan and will it take into account the deferral policy)?

 

  •  “Turn off auto-restart for updates during active hours":
         the idea would be to prevent reboot between 5am and 11pm but doesn't appear to be respected all the time.
0 Replies