If you manage Windows 365 Cloud PCs, you've probably noticed some settings moving around in Intune. The big news: Enable local admin is now generally available, and Microsoft is slowly moving away from the old User settingsexperience.
This is a short, practical guide to what changed, where things live now, and what you should do about it. (Source: Cloud PC configurations on Microsoft Learn.)
What is Enable local admin?
It does exactly what the name says: every user in the assigned groups becomes a local administrator on their own Cloud PCs. The permission applies at the user level, so it covers each of their Cloud PCs, and only theirs.
A quick word of caution: just because you can does not mean you should for everyone. The new guidance is a migration map for admins, not a reason to hand out administrator rights to the whole company. Use it for the people who genuinely need it (developers installing tools, for example) and target those groups only.
Where do settings live now?
The simple version is that there are now three places, and each has a job:
- Enable local admin → Cloud PC configurations (Intune).
- Recovery configuration (business continuity and disaster recovery) → also Cloud PC configurations.
- User-facing recovery permissions (what end users can do themselves) → Windows App settings. This one is still in preview.
Cloud PC configurations also supports user group targeting, so you can assign different settings to different groups.
How to create the new policy
- Sign in to the Microsoft Intune admin center.
- Go to Devices > Cloud PC Settings (under Manage Windows 365 Cloud PCs).
- Click Create and choose Cloud PC configurations.
- Give it a name and, if you like, a description.
- On the Configuration settings tab, set the options you want to Enable or Disable. Anything you leave as Not configured stays at its default.
- Add scope tags if you use them.
- Under Assignments, add the groups of users who should get the setting.
- On Review + save, select Create.
Editing and deleting work the same way from the same page. Select the policy to edit it, or use the … menu on the row and pick Delete.
Important: a user who is already signed in must sign out and sign back in to see the change. Keep that in mind when you test, because otherwise it looks like the policy didn't work.
Enable or disable it with PowerShell
You can also create the policy from a script instead of the portal. This uses the Microsoft Graph beta API, which is the same call the Intune portal makes, so it can change without notice. (The request shape is based on the AskAresh post by Aresh Sarkari, who captured what the portal sends.)
A few notes on the script:
- Enable sets the setting to Enabled. Disable sets it to Disabled, which actively turns local admin off. It is not the same as Not configured, where the policy simply doesn't manage the setting.
- You need a Windows 365 admin role (or equivalent Cloud PC permissions) and consent for
CloudPC.ReadWrite.AllandGroup.Read.All. - Test it on a pilot group first. It touches the beta API, and I'd treat the update path (
PATCH) in particular as something to confirm in your own tenant before relying on it.
Create the policy only (no group assignment)
If you'd rather create the policy and assign groups yourself later in Intune, use this shorter version. It creates the Cloud PC configuration with no assignments, so it applies to nobody until you add a group.
https://github.com/app2pack/Windows365-Scripts/blob/main/W365-EnableLocalAdmin-NoGroups
Validating on the Cloud PC
After the user signs out and back in, confirm the membership on the Cloud PC itself:
Get-LocalGroupMember -Group "Administrators"
The user should appear in the list when local admin is enabled, and should be gone when it's disabled.
The legacy User settings are on their way out
This is the part to pay attention to.
- Creating legacy policies is being disabled. This is a Public Preview rollout, so you may see it on some tenants before others.
- Existing policies still apply and can still be edited, but only for now.
- There is no final cutoff date documented. That makes it tempting to wait, but it's better to move early than to be surprised later.
- If a new Cloud PC configuration conflicts with a legacy value, the newer setting wins. Keep that in mind during migration, so you don't end up with a policy overriding something you didn't expect.
A simple migration plan
- List what you have. Open your existing User settings and note which ones enable local admin and which groups they're assigned to.
- Recreate them as Cloud PC configurations under Devices > Cloud PC Settings, with the same group assignments.
- Check for conflicts. Since the new policy overrides the legacy one, confirm the result is what you intended before you remove anything.
- Move recovery settings to Cloud PC configurations, and handle user-facing recovery permissions in Windows App settings.
- Clean up the legacy policies once you're sure the new ones work, and before editing closes.
One thing to remember
Local admin reaching GA does not mean every Cloud PC setting is generally available. Some features around it, like the business continuity and disaster recovery options and the Windows App recovery permissions, are still in preview. Check the status of each setting before you build a production rollout around it.
Final thoughts
The change itself is small: same capability, new home. The risk is in the details, which are making sure the right people get admin rights, avoiding conflicting policies, and not leaving it too late to migrate. Do the migration now while the old settings still work, and you won't have to rush later.
No comments:
Post a Comment