If you are backing up Windows Domain Controllers with Veeam and hitting VSS snapshot failures, and you happen to be running SentinelOne (S1), you’ve run into a specific “Anti-Tamper” block.
Here is the direct technical breakdown of why it breaks and the specific command to fix it without gutting your security posture.
The Problem: BCD Tamper Protection
When Veeam backs up a Domain Controller using Application-Aware Processing, it attempts to modify the Boot Configuration Data (BCD). It does this to set the safeboot dsrepair flag, ensuring that if you ever perform an authoritative restore, the DC boots correctly into Directory Services Restore Mode (DSRM).
SentinelOne (specifically versions 23.2+) sees an application programmatically touching the BCD as a massive red flag. Why? Because ransomware often tries to force machines into Safe Mode to bypass security drivers. S1’s Anti-Tamper module blocks this operation, causing the Veeam VSS writer to fail with a COM error: Code: 0xd0000022.
The Fix
You need to tell the S1 agent that it’s okay for “known and verified” apps (like Veeam) to touch those boot flags. Run this via an administrative command prompt on the affected DC:
sentinelctl config antiTamperingConfig.allowSignedKnownAndVerifiedToSafeBoot true -k "YOUR_PASSPHRASE"