Forum Discussion
Making sure Safeguards are respected
8 Replies
- Dave_BackmanFormer EmployeeHey Cordell Melin.... Thanks for joining us. Happy to go deeper if you want to ping me offline. Have a great day!
- bytebenCopper Contributor
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-devices
- 4cbmelin-workCopper ContributorThank 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).
- bytebenCopper Contributor
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.
- Jason_Sandys
Microsoft
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.
- 4cbmelin-workCopper ContributorThank 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.
- Jason_Sandys
Microsoft
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.