Windows 365 "Enable local admin" Is Now GA: What Changes for Admins?

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.All and Group.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.

check out my GitHub page for the script. https://github.com/app2pack/Windows365-Scripts/blob/main/W365-EnableLocalAdmin

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

1. List what you have. Open your existing User settings and note which ones enable local admin and which groups they're assigned to.
2. Recreate them as Cloud PC configurations under Devices > Cloud PC Settings, with the same group assignments.
3. Check for conflicts. Since the new policy overrides the legacy one, confirm the result is what you intended before you remove anything.
4. Move recovery settings to Cloud PC configurations, and handle user-facing recovery permissions in Windows App settings.
5. 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. 

Bug or ?? : Intune EAM update silently drops supersedence

Update: 05/August/2026 - This issue is limited to our Tenant only and doesn't affect others.

I ran into a strange issue today and wanted to write it down. Partly to save someone else the trouble, and partly because I’m now pretty sure this is a bug and not just me clicking the wrong thing.

A bit of background first. The Enterprise App Management (EAM) side of Intune lets you deploy apps straight from Microsoft’s catalog. No more packaging or manual works. When a newer version comes out, Intune shows it in a report under Apps > Monitor > Enterprise App Catalog apps with updates. The idea is simple. You click the app, hit Update, and Intune creates the latest version as a new app that supersedes the old one. The old installs then move up to the new version.

That’s how it’s meant to work. Here’s what actually happened.

Following the normal steps:

I was testing this with Docker Desktop (x64). I had deployed it as an EAM catalog app, and a newer version (4.78.0.229452) showed up in the report, just like it should.

I clicked on the app. On the overview page there’s an Update button at the top. One thing I noticed here: Intune shows a small warning that says “This app can update itself. App updates will come directly from the publisher…” Docker is one of those apps that can update on its own. Its Update Method was even listed as Auto-update. Keep that in mind, because it’s why I doubted myself at first.

Clicking Update opens the Supersede with latest app wizard. This part looks completely fine while you’re going through it:

1. You go through App information, Program, Requirements, Detection rules, and Scope tags. All good.

2. You reach the Supersedence step. Intune has already added the old Docker Desktop app under “Apps that this app will supersede.”

3. The Uninstall previous version toggle is set to No by default. That means update in place instead of replacing. Which is what you want for a version update.

4. You click Next, reach the review screen, and the supersedence is right there in the summary before you save.

Every screen tells you the same thing. This new app will supersede the old one. So you save it.

And then it’s gone.

This is where it breaks. After the new app is created, I opened its Supersedence tab, expecting to see the old Docker Desktop app listed.

It wasn’t there. The list was empty. The relationship the wizard showed me twice, once on the supersedence step and once on the review page, just didn’t save.

I thought maybe it was a display glitch, so I opened the Relationship viewer on both apps to check. Nothing there either. The new app shows no link to the old one, and the old app shows no link to the new one. After saving, Intune treats them as two completely separate apps.

So the supersedence you set up during the update is accepted, shown to you, and then dropped on save. No warning, no error.

Why this matters?

If you don’t catch it, this is a real problem. The whole point of the Update button is to build an update chain so devices with the old version move to the new one. No supersedence link means no chain. Your existing installs never learn there’s a newer version, and you end up with two separate apps instead of a proper update path. The report says the update is done, but nothing is actually superseding anything on the devices.

The tricky part is that it looks like it worked. You only find out by going back into the new app and checking the Supersedence tab yourself, which most people won’t do after the wizard just told them everything was set.

At first I blamed the self-updating app.

With Docker, I wasn’t sure. Its Update Method was set to Auto-update, and there was that warning saying the app updates itself. So my first thought was that Intune drops the supersedence on purpose because a self-updating app doesn’t “need” it. That would have been annoying but at least it would make some sense.

So I tested a second app to rule that out.

I picked Notepad++ (x64), version 8.6.9. This one is different in every way that matters here. Its Update Method is set to Supersedence, not Auto-update. It doesn’t self-update. The warning on its page is just the plain “A newer version of this app is available in the Enterprise App Catalog.” No self-update note at all.

I ran the exact same Update flow. Same result. The wizard added the old version, showed it on the review screen, let me save, and then the new app came out with an empty Supersedence tab. The Relationship viewer showed no link between the two, same as Docker.

That settles it for me. This isn’t about self-updating apps. A normal catalog app, set to supersede, still loses its supersedence on save. It’s a bug in the update flow itself.

What I’m doing about it:

For now the workaround is boring but it works. After you run the Update flow, go back into the new app, open the Supersedence tab, and add the old version by hand if it’s missing. Then check the Relationship viewer to make sure it stuck before you assign anything. Don’t trust the wizard’s word for it.

I’ve already raised a bug post in the Microsoft Management Advisors Teams channel program and also a support ticket, and I’m waiting on confirmation of the bug and the next steps. I’ll update this post once I hear back. If you’ve seen the same thing on your own EAM catalog apps, I’d love to know. Two apps that were completely different, one auto-updating and one set to supersede, both dropped the relationship the same way. So I doubt it’s just me.

Until then, check your Supersedence tab after every EAM update.

Access Windows 365 Cloud PC from Ubuntu Linux

I use Ubuntu as my daily machine, but my work lives on a Windows 365 Cloud PC. When I first set it up, I assumed it would be a headache. It wasn't. There's no official Linux app, but the browser route works well. VS Code, PowerShell and even Teams calls run fine inside the Cloud PC.

Here's how I do it.

Connect through the browser

Microsoft's Windows App is available for Windows, macOS, iOS and Android, but not for Linux. The good news is you don't need it.

1. Open Chrome or Edge on Ubuntu. (Edge for Linux is available as a .deb from Microsoft.)
2. Navigate to the Windows 365 Portal (or windows365.microsoft.com) and sign in with your work account.
3. Click your Cloud PC and choose Open in browser.

That's it. Your Windows desktop shows up in a tab. Press F11 for full screen and it feels close to a normal desktop.

Tip: Use a Chromium-based browser. Firefox works for basic sessions, but I had fewer problems with Chrome and Edge, especially with audio and clipboard.

Using VS Code inside the Cloud PC

Once you're in, the Cloud PC is just Windows. Open VS Code from the Start menu and work as you normally would.

• Your code, extensions, terminals and builds all run on the Cloud PC, not on your Ubuntu machine.
• Clone repos, install extensions and run your projects there.
• If you need to move files between Ubuntu and the Cloud PC, enable file transfer in the browser session, or use OneDrive.

Nothing is installed on Ubuntu for this. Your laptop is only the screen, keyboard and mouse.

Using PowerShell inside the Cloud PC

Same idea. Open Windows PowerShell or PowerShell 7 on the Cloud PC and run your scripts there.

This is actually the big benefit of using a Cloud PC from Ubuntu. Windows-only modules (Active Directory tools, registry access, Windows-specific admin modules) just work, because you're running real Windows. You can also run PowerShell from the VS Code terminal inside the Cloud PC.

Using Office apps inside the Cloud PC

This is one of my favorite parts. Ubuntu has no native Word, Excel or PowerPoint, but on the Cloud PC they're the full desktop versions.

• Open Word, Excel, PowerPoint, Outlook and OneNote from the Start menu, just like on a normal Windows PC. Sign in with your work account and they're licensed automatically.
• Everything works as you'd expect: Excel macros and Power Query, PowerPoint presentation features, Outlook add-ins and shared mailboxes. These are the things the web versions struggle with.
• Files saved to OneDrive sync inside the Cloud PC, so you can open the same documents from anywhere.
• Copy and paste text between Ubuntu and the Cloud PC works once clipboard access is allowed in the browser. For files, use OneDrive or the browser's file transfer option.

If you only need a quick edit, Office on the web (office.com) in a local Ubuntu tab is fine. But for heavy Excel files, macros or presentations, the desktop apps on the Cloud PC are much better. And because they run in the cloud, large spreadsheets open as fast as the Cloud PC's size allows, with no load on your laptop.

Microsoft Teams calls

This is the weak spot, and I'll be upfront about it. When I opened Teams inside the Cloud PC from Ubuntu, I got this message:

"We're unable to optimize your virtual desktop."

 

 

Here's what that means in real life:

• Audio is very choppy. Without optimization, your voice and the other person's voice are streamed through the remote desktop session instead of being handled by your local machine. Any small network hiccup shows up as broken, robotic audio. If you are using Firefox, switch to chrome browser and the experience is good and not choppy or laggy.
• The camera isn't detected inside the Cloud PC. Teams in the Cloud PC can't see your Ubuntu webcam, so video meetings aren't possible from there.

• Screen sharing works, but it's choppy too. It's usable for showing a document or a quick demo, but don't expect smooth motion or video playback. If you are using Firefox, switch to chrome browser and the experience is good and not choppy.

The reason is that Teams needs media optimization to hand audio and video over to your local device, and that isn't available in this setup. Without it, everything goes through the remote session.

What I do instead:

• Join important calls from Teams in a browser tab on Ubuntu (not inside the Cloud PC). Audio and your camera work normally there, because the call runs on your local machine.
• Keep the Cloud PC for your work (VS Code, PowerShell, Office apps) and share content from it by joining the call locally and sharing the Cloud PC browser window or tab.
• Use Teams inside the Cloud PC only for chat, files and quick listen-only calls.
• Use a headset. It helps with audio quality in either case. 

Video playback:

I tried streaming YouTube inside the Cloud PC and it lagged. Video is the hardest thing to push through a remote session, because every frame has to be rendered on the Cloud PC and then streamed to your screen. Text, code and documents feel fine, but video doesn't. If you need to watch a video or a training session, play it in a regular Ubuntu browser tab instead.

One thing you can do is in the settings - turn off the high DPI and then the video playback seems to be better but not high enough.

Update - For best experience always use chrome or edge browser and the performance is very good and the video play back is really good. Above experience was from Firefox and it wasn't the best.

Also the Advanced clipboard for copy paste works best in the chrome/Edge browser alone.

What about performance?

Here's the thing: since everything runs in the cloud, performance has very little to do with your Ubuntu machine. Your laptop only decodes and displays a video stream of the desktop. The heavy work (builds, scripts, VS Code, Teams processing) all happens on the Cloud PC.

So what decides how fast it feels?

• Cloud PC size. The vCPU, RAM and storage of your Cloud PC decide how quickly builds, VS Code and PowerShell scripts run. If things feel slow, ask IT about a bigger size. Changing your laptop won't help.
• Network latency. This is the main factor for how responsive it feels. Under ~50 ms feels great, and over 150 ms starts to feel laggy. Latency depends on the distance to the Cloud PC's region.
• Connection stability. Remote desktop cares more about a steady connection than raw speed. Wired Ethernet or good 5 GHz Wi-Fi helps.
• Teams optimization. This is the one exception where your setup matters. Without optimization, audio and video go through the remote session, so calls are choppy and the camera isn't available. Running the call locally on Ubuntu avoids this.
• Display settings. Lowering resolution or scaling (especially on a 4K monitor) can make the screen feel snappier.

Your Ubuntu laptop only needs to be good enough to run a browser smoothly. Anything modern will do.

Common gotchas

• Clipboard not working? Allow clipboard access when the browser prompts. Use chrome/Edge for best experience.
• Keyboard shortcuts get caught by Ubuntu. Some shortcuts (like Super or Alt+Tab) go to your local desktop and not the Cloud PC. Full-screen mode helps.
• Session disconnects. Usually a Wi-Fi or VPN issue. Reconnect, and your session is exactly where you left it.

Final thoughts

Cloud PC in an Edge or Chrome tab, VS Code, PowerShell and Office apps running inside it, and Teams calls taken locally in a separate Ubuntu browser tab. It's not an "official" Linux experience, and Teams calls are the one real limitation, but for everything else I barely notice I'm on Ubuntu.

If you've found a better trick, I'd love to hear it.

Windows 365 - Cloud Apps now support APPX and MSIX applications

Cloud Apps for Windows 365 have expanded their capabilities by adding support for APPX and MSIX applications, in addition to traditional Win32 apps. This enhancement allows administrators to discover and publish a broader range of applications, including modern apps such as Microsoft Teams and the new Outlook.

With this update, Cloud Apps provisioning policies can surface more application types, enabling greater flexibility in how apps are delivered to users. For environments that already have Cloud Apps configured, reprovisioning existing policies is required to enable the discovery of APPX and MSIX applications. Once reprovisioned, these apps appear seamlessly alongside existing Win32 applications.

The overall management experience remains unchanged. Admins continue to use the same discovery, publishing, and assignment workflows, while gaining the ability to deliver modern Windows applications through Cloud Apps.

Real‑world use case

Consider an organization using Windows 365 Cloud PCs for contractors, temporary staff, or front‑line workers. Previously, IT teams may have relied on Win32 packages or full desktop images to provide access to essential tools. Modern applications such as the new Outlook, Microsoft Teams (MSIX‑based), or line‑of‑business apps built using MSIX may not have been easily discoverable through Cloud Apps.

With APPX and MSIX support enabled, IT can now publish these modern apps directly as Cloud Apps without re‑engineering deployment methods. For example, a contractor accessing a Cloud PC can launch Microsoft Teams as a Cloud App without needing a full desktop session. This reduces onboarding time, improves performance, and ensures users always access the supported application version.

This is especially valuable for hybrid or distributed teams where users need quick access to specific apps rather than an entire virtual desktop environment.

Benefits for IT teams

One of the biggest benefits for IT teams is improved application coverage. Many modern Microsoft and third‑party apps are now built using APPX or MSIX packaging. Supporting these formats removes a long‑standing limitation and reduces the need to maintain alternate Win32 versions or workarounds.

Operational efficiency also improves. Since the publishing and management workflow remains the same, IT teams do not need additional training or tooling. Existing Cloud Apps policies can simply be reprovisioned, allowing teams to extend functionality without redesigning their deployment strategy.

Security and consistency are another key advantage. MSIX apps are containerized and follow modern Windows security standards, such as clean installs, reliable uninstall behavior, and reduced risk of system‑level changes. By delivering these apps through Cloud Apps, IT teams maintain better control over what users can access while ensuring compliance with organizational policies.

Finally, this update supports a more flexible end‑user experience. Instead of deploying full desktops for lightweight workloads, IT teams can offer app‑only access for specific roles. This can help reduce licensing costs, simplify access models, and align Windows 365 deployments more closely with actual business needs.