I built a Windows optimizer that refuses to run if Outlook is open

I wrote a PowerShell script that hardens and tunes Windows 10/11. Pretty standard stuff. Disables telemetry, kills bloatware, tweaks the registry for performance, hardens a few obvious holes (SMBv1, AutoRun, Remote Desktop if you don't use it).

Writing those tweaks isn't hard. The hard part is what happens when you run a script like that on a machine someone is actually using.

My first version was clean. Smooth even. Then I ran it on my dad's laptop while he was on a Zoom call. The script disabled a couple of audio services it thought were unused. Mic cut out mid-meeting. He was not impressed.

That was the moment I added context-aware safety.

Now before the script touches anything, it scans for running processes and connected hardware that would care. Outlook running? Skip the network resets. RDP session active? Don't touch firewall rules. Touchscreen detected? Leave the tablet input services alone. Print job queued? Don't kill the spooler.

It's a stupid amount of edge-case logic for a script people will run once. But it's the difference between "optimizer" and "incident."

Here's roughly how the privacy module handles it:

function Invoke-PrivacyOptimization {
    param([switch]$DryRun)

    $context = Get-RuntimeContext
    if ($context.Skip -contains 'Cortana-active') {
        Write-Log "Cortana in use, skipping Cortana disable"
        return
    }

    $changes = @{
        'AllowTelemetry' = 0
        'AllowCortana'   = 0
        'AdvertisingId' = 0
    }

    foreach ($key in $changes.Keys) {
        Save-UndoEntry -Name $key
        if (-not $DryRun) {
            Set-RegistryValue -Name $key -Value $changes[$key]
        }
    }
}

The undo logic is what I'm most proud of. Every registry change writes the previous value to a JSON file in %LOCALAPPDATA%\UWSO\ with restricted ACLs (so a non-admin user on the box can't tamper with the rollback). If anything breaks, you run the script with -Undo and it restores every value from the most recent run.

The catch I didn't see coming: some registry keys don't exist until you set them. So the "previous value" is null. If you blindly restore null, you delete the key entirely. Sometimes that's fine. Sometimes you've just removed a default that Windows would have created on demand, and now an app behaves oddly because that key being absent means something specific. I ended up adding a flag in the undo file marking whether the original key existed or not. Boolean, not the worst code I've ever written, but it took me a full afternoon to figure out why some restores were leaving the system in a weirder state than before the optimizer ran.

I also added a health score. It's a 0-100 number based on services running, telemetry endpoints reachable, disk type vs. configured caching, firewall posture, and a few other things. Mostly it's there so the user has a before/after to look at. Nobody trusts a script that just says "done." They want a number that went up.

What's still rough:

The detection for "active session" is shallow. I'm checking process names. If you renamed Outlook.exe to something custom or you're running a different mail client, the script wouldn't notice. A real solution would hook into Windows session APIs and check what's holding open file handles or audio endpoints. I'm not there yet.

Gaming tweaks are mostly hard-coded. The script enables Game Mode and disables Game DVR if it sees a discrete GPU. Should probably check whether the user actually games. Right now if you have a 4090 and only use the machine for Excel, it'll still flip those bits. Harmless, mostly, but annoying that it lies a little on the report.

The hardware tier classifier is fragile. I divide systems into rough buckets based on CPU/RAM/storage type. The thresholds are arbitrary numbers I picked after testing on six machines. Probably wrong for anything outside that range. If you run it on a Surface tablet or a Steam Deck booted into Windows, results may be funky.

The SSD-specific tweaks (disabling Prefetch/Superfetch, ensuring TRIM is on) only fire if it detects an NVMe or SATA SSD via the storage cmdlets. Hybrid drives confuse it. I have one in a backup laptop and it always classifies it wrong.

If you want to try it, install is one line:

irm https://raw.githubusercontent.com/TiltedLunar123/Ultimate-Windows-System-Optimizer/main/run.ps1 | iex

Run it with -DryRun first. Always. The dry-run mode prints every change it would make without touching anything. I use this on every fresh machine before letting it commit. You can also do -Only "Privacy","Cleanup" to scope it to a few modules, or -Skip "Gaming" to leave specific stuff alone.

If it ever does something you don't like, -Undo will pull the most recent rollback file from %LOCALAPPDATA%\UWSO\ and put things back. The rollback files are plain JSON. You can read them, edit them, or delete them if you want a clean slate.

Repo and full module list here: https://github.com/TiltedLunar123/Ultimate-Windows-System-Optimizer

Issues and PRs welcome. Especially if you have a weird hardware setup that breaks the tier classifier. I want to know.