Making sure Safeguards are respected

Copper Contributor
Moving devices from ConfigMgr SW Updates to WUfB, some will get the latest Feature Update before Compatibility Appraisal is done, thus, before any knowledge of Safeguards. How can I best ensure that the Compatibility Appraisal is done before enabling Windows Updates? Collection based on reg key under AppCompatFlags? Something else? Thanks.
8 Replies

Hi @Cordell Melin,

 

Sorry, I'm not entirely sure what you are asking here. SafeGuard holds are always respected when (and only when) you use Windows Update (which includes WUfB) -- this is by definition of what a SafeGuard hold is. The only exception here is if you've explicitly bypassed them on a specific system by configuring the appropriate registry value (we don't generally recommend bypassing SafeGuard holds as this will most likely result in a failure or upgrade issue at some point which is why the SafeGuard exists in the first place). There is no direct way to enable or disable SafeGuard holds using ConfigMgr. SafeGuard. See Safeguard holds - Windows Deployment | Microsoft Docs for complete details. 

 

Don't confuse SafeGuard Holds with Windows setup based compatibility checks though. Compatibility of multiple items including drivers and applications are checked during this phase. As implied though, these Setup-based compatibility checks happen during Windows Setup itself before the actual upgrade process begins. This is in contrast to SafeGuard holds which prevent a system from ever knowing about a Feature Update at the Windows Update service level. 

 

There is some overlap between the issues that SafeGuard Holds prevent and the issues that Windows setup compatibility checks detect, but there isn't complete parity if that is what you are expecting. SafeGuard holds are not comprehensive and don't include most application compatibility issues. If you are looking to evaluate application compatibility as part of your Feature Update rollout process, I suggest you take a look at Desktop Analytics: Compatibility assessment - Configuration Manager | Microsoft Docs.

 
 

@Cordell Melin There is a known limitation where feature update policies may not take immediate effect when moving the Updates workload from ConfigMgr to Intune. This may result in unexpected FU being made available to the client. If this is what you mean, follow this article to understand how to use a CSP to prevent this behaviour. The policy won't override a safeguard hold. https://docs.microsoft.com/en-us/troubleshoot/mem/intune/create-feature-update-hold-co-managed-devic...

Hey @Cordell Melin.... Thanks for joining us. Happy to go deeper if you want to ping me offline. Have a great day!
Thank you. Since we are not yet able to take advantage of Intune, we applied the WUfB GPO Select the target Feature Update version. Thing is, we would like to let them go to latest FU offered by WU, as long as it respects any Known Issues (Safeguards).
Intune plays no part here. As noted, SafeGuard Holds are part of the Windows Update service itself (which includes WUfB); Intune as well as GPOs merely set policies for WUfB. Thus, any system using Windows Updates (including WUfB) for updates is subject to the defined SafeGuard Holds (unless as noted the registry value is present on the device to disable this which we don't recommend and is not default).

If you want to explicitly track and report on update compliance and SafeGuard hold applicability to your devices (and why wouldn't you), you should deploy the Update Compliance solution: https://docs.microsoft.com/en-us/windows/deployment/update/update-compliance-get-started. See https://techcommunity.microsoft.com/t5/windows-it-pro-blog/access-safeguard-hold-details-with-update... for details on tracking SafeGuard Holds with Update Compliance.
Thank you, Jason. During our WUfB PoC, we had a few devices get offered, and attempted to install, 20H2 from WU, although they had the Conexant ISST Audio driver Known Issue (Safeguard ID 25178825). When we checked the devices, they had run the Microsoft Compatibility Appraiser task but there were no C:\Windows\appcompat\appraiser\*.bin files and no information in the registry for Safeguards (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Appraiser\GWX SdbEntries). Everything else with WU is working great, we just want to avoid some devices (maybe sick ones :) ) fly under the Safeguard radar.
I can't comment specifically as to why or how this Safeguard was bypassed as to my knowledge, this shouldn't happen. I suggest you open a support case to investigate further.

Hey @4cbmelin-work 

Forgive me. I misunderstood the context of your question and offered advice that wasn't pertinent to your issue. I have co-management on the brain today :) Regards, Ben.