Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
"Fae" Grace Meadows
System Restore reverts system files, the registry and installed programs, not personal files. Here is when a restore point fixes the ticket, when it cannot, the 60-day limit and VBS check, the error codes, and where Microsoft's Point-in-time Restore fits beside it.
A user installs a printer driver on Monday and on Tuesday the laptop will not finish booting. The five-minute fix for that is often switched off on the machine in front of you, and since 2025 it comes with an expiry date. This guide covers what System Restore on Windows 11 can and cannot undo, how to keep it on across a fleet, and where Microsoft's new Point-in-time Restore sits beside it.
A restore point is a snapshot of the parts of Windows that change when software is installed or settings move: system files, the registry, drivers and installed programs. Microsoft's System Restore page says a restore reverts "the system files, registry settings, and installed programs" to their earlier state "without affecting your personal files". The developer documentation is more precise about the mechanism: System Restore "undoes file changes made to monitored files" and then "replaces the current registry with the one saved for the selected restore point".
The word that matters is monitored. System Restore does not copy the whole drive. It watches a defined set of locations and file types, which is why Documents, Desktop, Downloads, Outlook data files and browser profiles come through a restore untouched. That is the design, and it is also why a restore cannot bring back a deleted spreadsheet.
The edges of "monitored" are fuzzier than the dialog suggests. One sysadmin tested it by dropping a text file into every folder he could think of, running a restore, and checking what survived. The file he had put inside Program Files was still there afterwards, because the extension was not on the monitored list. The rules live in the registry under FilesNotToSnapshot, FilesNotToBackup and KeysNotToRestore, and his thread walks through mounting the shadow copies to compare them:
Underneath, every restore point is a Volume Shadow Copy. The same copy-on-write engine that backup software uses takes a snapshot of the volume, and System Restore keeps the pieces it cares about inside the drive's shadow storage. That is why the "Max Usage" slider in System Protection and the vssadmin command both govern how many points survive, and why a backup tool that also uses VSS competes for the same space.
System Protection is set per drive, and on a fresh Windows 11 install the system drive often shows Off, with no restore points and no space reserved. OEM images, small SSDs and in-place upgrades all leave it that way, and nothing in Settings tells the user. The first check on any machine is Start, type "Create a restore point", and read the Protection Settings list. If C: says Off, there is nothing to restore to, no matter what the ticket says.
The Grumpy Sysadmin's walkthrough from October 2026 makes that check the first step, then covers creating a point and using one when Windows will not start:
Turning it on takes a minute. Select the drive, choose Configure, pick "Turn on system protection" and set the Max Usage slider. A tight cap means one or two points before the oldest is deleted, so give it a few percent on a machine with room. The same thing in PowerShell, which is what you want for more than one machine:
powershellEnable-ComputerRestore -Drive "C:\" vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10% Checkpoint-Computer -Description "Baseline" -RestorePointType MODIFY_SETTINGS Get-ComputerRestorePoint
Two notes from Microsoft's own documentation. The vssadmin resize page warns that "resizing the storage association may cause shadow copies to disappear", so set the size before you create the point, not after. And Checkpoint-Computer "cannot create more than one checkpoint each day": a second call inside 24 hours returns an error rather than a point. Windows applies the same 24-hour rule to its own automatic points. The registry value that controls it, SystemRestorePointCreationFrequency under the SystemRestore key, is documented by NinjaOne and Eleven Forum rather than Microsoft, and setting it to 0 removes the skip.
Automatic points come from Windows Update, driver installs and installers that call the restore API, plus a scheduled task that creates one when the machine is idle. What nobody expects is the deletion: a feature update wipes every existing restore point, so the first week after a version upgrade is the one week with nothing to go back to.
For years the retention rule was a mess. Windows 10's documented age limit was 90 days. Windows 11 kept points for anything from 10 days to 90 depending on the machine, and Windows Latest's testing in 2025 found both ends in the wild. Microsoft settled it with the June 10, 2025 security update, KB5060842: Windows 11 24H2 "will retain system restore points for up to 60 days", and "this 60-day limit will also apply to future versions of Windows 11, version 24H2". The value lives in RPLifeInterval, 5,184,000 seconds on 24H2 against 7,776,000 on Windows 10.
Then the July 2026 security update added a second gate. Per Microsoft's restoring the system page, devices on Windows 11 24H2, 25H2, 26H1 and Windows Server 2025 can only restore from points that pass a Virtualization-Based Security check: the point "must meet the minimum VBS CI Policy requirement or, when the VBS CI Policy version cannot be compared, fall within the 60-day limitation". The page is blunt about the rest: "restoring Windows from restore points that do not meet the required security checks is not possible on these versions of Windows". The only way to reach an older point is to turn VBS off first, which on a managed device is a policy change, not a click.
System Restore is a precise tool with a narrow target. It works when the thing that broke lives in the monitored set and a point exists from before it broke. It fails, sometimes loudly, when either half is missing.
| Ticket | System Restore | Try first or instead |
|---|---|---|
| Blue screen after a driver update | Yes, if a point predates the driver | Roll Back Driver in Device Manager |
| Broken after a quality update | Yes | Uninstall the update from Update history |
| Broken after a feature update | No, the upgrade deleted the points | Go back in Settings within 10 days, or a repair install |
| Registry or policy edit broke sign-in | Yes | |
| Installer replaced system files or services | Yes | |
| Malware or adware | No, and it may bring removed files back | Malware removal, then a clean point |
| Ransomware | No, the attacker deletes shadow copies first | Immutable backups |
| Corrupt user profile | No | Profile rebuild |
| Deleted or overwritten documents | No | File History, backup, or Point-in-time Restore within 72 hours |
| Failing disk or memory | No | Hardware diagnostics, then image restore |
Two rows deserve a story each. The feature-update row is where restores go wrong in the field. An r/Windows11 user in August 2026 ran System Restore to fix a taskbar tweak, chose the only point available, which was from before a feature update, and got a boot loop with "Your device ran into a problem" on every restart. Quick Machine Recovery did not help and neither did the other points. Point-in-time Restore, which he had turned on when it shipped and forgotten, brought the machine back to a snapshot from two days earlier:
The replies carry the other half. One user's machine blue-screened at every login after a forced power-off, and a restore point from the previous day fixed it in one pass. Another points out that some updates switch protection off, so the setting needs checking, not trusting.
The malware row is the one technicians argue about. A restore point taken while the infection was present contains the infection, and a restore to it can reinstate files a scanner has since removed. System Restore also leaves the Downloads folder and the user profile alone, which is where the dropper usually sits. Clean first, following the order in our malware removal guide, then take a fresh point. Ransomware is simpler: deleting shadow copies is a standard step in the encryptor, so by the time the note appears the points are gone.
A restore that fails tells you why in a hex code, and three of them cover nearly every ticket.
0x80070005 is access denied. Something has a lock on files the restore needs to replace, and in practice that is a security agent or a third-party filter driver. The fix is to run the restore from Safe Mode, where third-party drivers do not load, or from WinRE, where nothing from the installed Windows is running at all. Our Safe Mode guide covers getting there when the machine will not cooperate. Check the Volume Shadow Copy and Microsoft Software Shadow Copy Provider services are not disabled while you are at it.
0x80070091, "the directory is not empty", is a specific and well-known one. The restore fails while rebuilding the Program Files folder called WindowsApps, where Store packages live, and the log names AppxStaging as the source. The folder is protected and a half-finished replace leaves it in a state the restore refuses to touch. The fix that works for many, but not all, reports: from WinRE or Safe Mode, take ownership of WindowsApps, rename it, and run the restore again. Expect to reinstall Store apps afterwards.
0x81000203 appears before you even pick a point: System Protection itself cannot start. In almost every report the shadow copy services were disabled by a tuning tool or a policy, or the Group Policy "Turn off System Restore" is set. Check services.msc for the two VSS services, then check for the DisableSR value under the SystemRestore policy key.
Whichever code you get, run sfc /scannow and a DISM RestoreHealth pass before trying again, because a corrupt component store fails restores in ways the codes do not explain. And if a point is older than 60 days or predates a VBS policy change, the failure is the security check from the previous section, not a bug.
In June 2026 Microsoft made Point-in-time restore generally available for Windows 11, and the July 2026 update, KB5101650, started rolling it out on 24H2 and 25H2. It uses the same Volume Shadow Copy Service as System Restore and does the opposite thing with it: a full snapshot of the OS volume on a schedule, "the OS, apps, settings, and local files (no user data is scoped out of the restore point)". A restore puts the whole drive back to that moment, personal files included, and anything created after the snapshot is gone. Files already synced to OneDrive are the one exception.
The defaults, per Microsoft: a snapshot roughly every 24 hours, kept for up to 72 hours, using up to 2% of the disk, with a floor of 2 GB and a ceiling of 50 GB. It is on by default on Home devices and on Pro devices that are not domain joined or enrolled in management, provided the OS volume is 200 GB or larger. On Enterprise, Education and managed Pro devices it is off by default until Windows 11 26H2, and an admin can turn it on earlier through the Recovery CSP. Only Enterprise can change the frequency and retention.
| System Restore | Point-in-time Restore | |
|---|---|---|
| What it reverts | Monitored system files, registry, programs | The entire OS volume, files included |
| When points are made | On events, or by hand | On a schedule, automatic only |
| How long they last | 60 days on 24H2 | 72 hours |
| Where you start it | Control Panel, rstrui, or WinRE | WinRE only, BitLocker key required |
| Disk use | Max Usage slider on the drive | 2% default, shares VSS space |
| Admin control | Group Policy, registry, PowerShell | CSP via OMA-URI, Intune |
Microsoft's own advice is to try Point-in-time Restore first and fall back to System Restore when you need to go back more than 72 hours. For a help desk the split is cleaner than that. Point-in-time Restore is for "the machine was fine yesterday": a bad update, a tool that trashed the profile, a user who deleted the wrong folder. System Restore is for "the driver we pushed three weeks ago" and for machines that are managed and have not had the feature turned on yet.
Two traps. The restore has to start locally in WinRE with the BitLocker recovery key, and Microsoft Intune cannot kick it off remotely yet, so the help desk needs key access and a user at the keyboard. And both features draw from the same VSS pool, with the point-in-time maximum applying to every restore point on the volume. Microsoft's guidance is to avoid combining it with other VSS-based backup tools that compete for the space, which is worth knowing before a backup agent and a 2% cap start evicting each other's snapshots.
From a working desktop, open System Restore with rstrui.exe or through Control Panel, Recovery. Choose the point, tick "Show more restore points" if the one you want is hiding, and use "Scan for affected programs" before you commit. That scan lists what the restore will remove and what it will put back, and it is the difference between a five-minute fix and a user asking where their CAD plugin went. Windows restarts on its own when it finishes, and the one thing you cannot do is interrupt it.
When Windows will not boot, the same tool is in the recovery environment: Troubleshoot, Advanced options, System Restore. On an encrypted drive it asks for the BitLocker recovery key first, so have it ready from Entra or AD before you drive out. The WinRE guide covers getting in when the automatic route does not fire. Srikant Sahu's walkthrough shows both routes end to end, including turning protection on in the first place:
System Restore sits in the middle of a ladder, and the rung to pick is the one that undoes the least. Every step up costs the user more.
The order holds for a stop code after a driver install too. Our DRIVER_IRQL guide starts with naming the driver, because a rollback on the right one beats a restore that reverts six others.
On one machine the slider is enough. Across a client's fleet, three things have to be true on every device before patch night: protection is on, the space is set, and a fresh point exists.
Group Policy has one switch, and it is the wrong way round. Computer Configuration, Administrative Templates, System, System Restore, "Turn off System Restore" has to be Not Configured or Disabled; Enabled kills the feature and writes DisableSR=1 under the SystemRestore policy key. That registry value is also the fastest thing to audit, because a tuning script or an old baseline that set it will not show up anywhere else. Turning the policy off does not turn protection on, so the enable step is still a script.
Intune has no built-in toggle for classic System Restore, so the practical route is a remediation script that enables protection on C:, sets the shadow storage size, drops the 24-hour skip, and takes a point with a description that names the patch window:
powershellEnable-ComputerRestore -Drive "C:\" vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10% Set-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore" ` -Name SystemRestorePointCreationFrequency -Value 0 -Type DWord Checkpoint-Computer -Description "Pre-patch $(Get-Date -Format yyyy-MM-dd)" -RestorePointType MODIFY_SETTINGS Get-ComputerRestorePoint | Select-Object -Last 1 SequenceNumber, Description, CreationTime
Run it before the deployment, not during, and collect the last line. If you run OpenFrame, that is one script across a client's devices with the output gathered in one place, which turns "is protection on everywhere" from a question into a list of the machines where it is not. The same run should flag Get-ComputerRestorePoint returning nothing, because a point that was not created is the thing you discover on the night.
Servers are a different world. Checkpoint-Computer is "supported only on client operating systems", and Windows Server has no System Restore at all. The equivalent before a server patch is a hypervisor checkpoint or a backup with a tested restore, which is a backup plan question rather than a Windows setting.
For Point-in-time Restore on managed devices, the switch is the Recovery CSP. The nodes under ./Device/Vendor/MSFT/Recovery/PointInTimeRestore turn it on, set the maximum disk usage in megabytes, and set the frequency and retention in minutes, delivered as an OMA-URI policy from Intune. Remember it stays off on managed devices until 26H2 unless you enable it, and a device that has not been enabled takes no snapshots at all.
Every help desk has had the ticket where the restore point that would have fixed everything was the one that was never taken:
System Restore undoes changes to Windows, not changes to the user's data, and it only works when protection was on before the problem and the point is young enough to pass the 60-day and VBS checks. Use it for drivers, updates and installers; use rollback for a single known change, Point-in-time Restore for a whole machine inside 72 hours, and a backup for anything older than that. Across a fleet, make protection a policy and the pre-patch point a script, and read the output.
Next: immutable backups, for the day the attacker deletes the shadow copies before you can use them.
Lead AI Fairy
Some things defy easy explanation: magic dust, the northern lights… and Flamingo’s AI Angels. Think Charlie’s Angels, reimagined with automation brains and serious RMM (Remote Monitoring & Management) chops. Weird? A little. Effective? Absolutely. That’s the job.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.