I'm building a small PowerShell tool that disables Brave features such as Rewards, Wallet, VPN, Leo, and telemetry through the official enterprise policies. Applying the policies is straightforward, but I want to make sure the tool can't leave someone with a damaged or difficult-to-restore registry.
The current design is conservative: nothing changes unless -Apply is supplied, -WhatIf still works through ShouldProcess, and the existing values are saved to a timestamped backup before anything is written. Undo checks the backup metadata and only restores Brave policy paths, so a malformed or tampered backup can't make the command write arbitrary registry keys. The tool also refuses to disable security features such as Safe Browsing or updates.
I'm still deciding on the backup format. Right now I'm using readable JSON snapshots for each run. Would reg export/.reg files or Export-Clixml be a better choice? I'm particularly interested in preserving registry value types and correctly undoing values that didn't exist before the tool ran.
5 Answers
A .reg export is the most native option and preserves registry types, so restoring DWORDs and strings is less error-prone. The catch is that reg import merges values; it won’t remove policy values that were created after the export. A real undo therefore needs to track whether each value existed, its old type and data, and whether newly created values should be deleted. Once you need that metadata and strict path validation, JSON is a reasonable choice because you can inspect and validate it before restoring.
Another possibility is storing the original values under a clearly reserved backup name in the registry, with a timestamp. That keeps the native types and makes the backups visible, but it also modifies the registry and needs collision handling, cleanup, and protection against someone editing the backup entries. An external, validated snapshot is probably easier to reason about for a tool that may run on other people’s machines.
PowerShell’s registry provider had transaction support in Windows PowerShell 2.0 through 5.1, and registry transactions were intended for applying a group of changes with rollback. They’re not available in PowerShell Core, though, and the feature is uncommon enough that I’d treat it as an optional Windows PowerShell implementation rather than the only recovery mechanism. Explicit backups and scoped restore logic are still valuable.
CSV could work well for simple scalar values: Path, Name, Type, and Value would be enough to pipe imported rows into a restore command. It becomes awkward for policies represented by subkeys or numbered list values, though, so JSON is more flexible for those cases. For prompting, ShouldProcess is still useful because it supports both -WhatIf and -Confirm. ShouldContinue can provide an extra yes/no gate, but it doesn’t integrate with -WhatIf in the same way.
I may use CSV for the flat values and keep JSON for the few list-style policies. I’m also leaning toward retaining ShouldProcess and putting any additional confirmation behind a separate force or interactive option.
Whichever format you use, compare the current value and registry type before writing. A missing value should count as different when the desired policy needs to be created, while an already-correct value can be skipped. Be explicit about types—PowerShell can otherwise create a DWORD-looking value as a string, which the application may silently ignore. A structured backup should include the path, value name, type, data, and whether the value existed before the change.
That matches what I found. I’m treating missing values as changes, skipping only values whose data and type already match, and storing enough state to delete values that were introduced by the tool.
That’s why I moved away from a plain export. Importing the old snapshot would restore previous values but leave newly created policy values behind, and it could also merge unrelated changes. JSON lets me validate the backup and restrict restoration to the expected Brave policy paths.