Restore is the Cloud PC capability you configure once and thank yourself for on a bad day. The configuration is one small policy; the value is in the three decisions inside it.
The operations article made the case for point-in-time restore as the lever that changes your incident playbook. This companion builds it: the user settings policy that controls restore point frequency and self-service, the manual restore point workflow for pre-change protection, and the one targeting rule that behaves opposite to everything else in Windows 365 and bites people who assume consistency.
The user settings policy
Restore configuration lives in Windows 365 user settings, alongside the local admin and self-service reset toggles. In the Intune admin center, go to Devices, then in the Manage Windows 365 Cloud PCs area open Cloud PC Settings and select Add, or edit an existing user setting if one already targets the population you care about.
Name the policy for its population and level, then work through three decisions. First, Enable Local admin: leave it unchecked for any general population, consistent with everything the Intune series has argued about standard user as the default state. Be aware the checkbox is enforcing in both directions; an unchecked policy actively removes local admin rights from targeted users, which can surprise environments with legacy scripts that added users to the local Administrators group. Second, Allow user to initiate restore service: this is a per-population judgment. I grant it to technical users who understand that a restore is a full-disk time machine that destroys everything after the chosen point, and I withhold it from everyone else, because a panicked user with a restore button is a data-loss incident with a timestamp. Third, Frequency of restore-point service: every 4, 6, 12, 16, or 24 hours, with 12 as the default and a hard cap of ten short-term points regardless of interval. The arithmetic is the decision: four-hour points cover roughly the last forty hours at fine grain, twenty-four-hour points cover ten days coarsely. I default volatile-work populations to the four or six hour setting and accept the shorter reach, because old restore points carry their own risk; machine credentials and certificates roll on their own schedules, and a restore that predates a rotation can produce a Cloud PC that boots but trusts nothing. The four weekly long-term points exist automatically either way and are not configurable.
Assign the policy to user groups and create it. Then read the next paragraph, because the targeting rule is the trap.
Provisioning policies give an overlapped user the first policy created. User settings give them the most recently created one. Same product, opposite rules, and nothing in the portal warns you.
When a user lands in more than one user settings policy, the most recently created policy wins and all others are ignored, and the tiebreaker is creation time, not last-edited time. This is the inverse of provisioning policy behavior, where the first policy wins. The safe design is the same in both cases: non-overlapping assignment. If you want tiered capability, standard users with restore points only, power users who may self-restore, admins with the full set, build the tiers as separate policies on mutually exclusive groups rather than layering, because layering does not merge settings; it picks one policy and discards the rest.
Manual restore points and the restore itself
Before any risky change to a Cloud PC, an application upgrade, a configuration experiment, an agent migration, take a manual restore point: Devices, All devices, select the device, Restore points, Create restore points. Know its constraints going in: one manual point per Cloud PC, overwritten by the next one you take, expiring after a maximum of twenty-eight days. It is a pre-change snapshot, not an archive. When a state genuinely needs preserving, for an investigation or a dispute, use the share option to copy the restore point into an Azure storage account, where it lives on your terms instead of the platform’s.
Restoring is deliberately unexciting. On the device, the same Restore points view lists every available point with its type, health, and expiry; pick the newest point that predates the problem, restore, and have the user sign in immediately to verify the machine trusts its world. Unhealthy points are flagged in the list; skip them. For incidents that hit many machines at once, the same bad patch or the same destructive change, use Bulk device actions from Devices, All devices, which restores up to a hundred Cloud PCs against a target date and time, choosing the point before, after, or closest to it, with an option to skip unhealthy snapshots. And keep the runbook rule from the operations article in force here, where the buttons actually live: restore before you reprovision. The restore preserves the desktop and costs minutes. The reprovision is the tool of last resort standing right next to it in the menu, and a hurried technician should have to pass the cheap option to reach the destructive one.
Windows 365
‹ Previous: [W365 4] Operating Cloud PCs: The Endpoint You Already Know How to Manage
Next: [W365 5] The Cloud PC as a Privileged Access Workstation ›
