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.

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.

Windows 365 Remote Desktop Shows Only a Black Screen? Here’s the Quick Fix

Sometimes when connecting to a Windows 365 Cloud PC using windows App, the session connects successfully—but all you see is a black screen. You may try refreshing, reconnecting, or waiting for several minutes, but the screen remains blank.

This is a known and occasionally encountered issue, and thankfully, the fix is simple.

What Doesn’t Work

• Refreshing the session
• Disconnecting and reconnecting
• Waiting for the screen to load

If none of these resolve the issue, the Cloud PC itself likely needs a restart.

✅ The Fix: Restart the Windows 365 Cloud PC

1. Open the Windows App (Windows 365 app).
2. Locate your available Windows 365 Cloud PC.
3. Click the three dots (⋮) next to the Cloud PC.
4. Select Restart.

The restart process may take a few minutes. Once completed, reconnect to the Cloud PC—you should now be able to log in normally without the black screen.

What If You Don’t See the Restart Option?

In some locked-down or restricted environments, the restart option may not be visible to end users. In this case:

• Contact your IT support team
• They can restart the Cloud PC from the Intune Admin Center → Windows 365 blade

After IT performs the restart, the Cloud PC should work fine.

Final Thoughts

A black screen on Windows 365 can be frustrating, but it’s usually not a serious issue. A simple Cloud PC restart resolves it in most cases. If you’re restricted from restarting it yourself, your IT team can handle it quickly through Intune.

Windows 365: Fixing Microsoft Teams performance issue

Fixing Microsoft Teams Performance Issues in Windows 365

Microsoft Teams is a critical collaboration tool for many organizations. However, ensuring optimal performance on Windows 365 Cloud PCs or Azure Virtual Desktop (AVD) environments often requires specific configurations. This article provides a step-by-step guide to verify and enable Teams SlimCore Media Optimization for improved performance.

Step 1: Verify Teams Media Optimization Type

Before making any configuration changes, verify that your Teams client is using the new SlimCore Media Optimization architecture. Follow these steps:

1. Open the Microsoft Teams client.
2. Click on the ellipsis (...) on the top bar.
3. Navigate to Settings > About.
4. Check the optimization type listed under the Teams version:
   • AVD SlimCore Media Optimized: means it’s new optimization based on SlimCore.
   • AVD Media Optimized: means it’s  Legacy optimization based on WebRTC.

Step 2: Enable Teams Media Optimization

To enable media optimization for Teams in Windows 365 or AVD environments, configure a registry key on each session host if it’s not already present. This key will be present if it’s already optimised. If not, you need to configure.

Registry Configuration Steps:

1. Open Registry Editor as an administrator.
2. Navigate to the following path:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Teams
   

3. If the Teams key doesn't exist, create it.
4. Add the following value:
• Name: IsWVDEnvironment
• Type: DWORD
• Value: 1

Reference: https://learn.microsoft.com/en-us/azure/virtual-desktop/teams-on-avd#enable-media-optimization-for-teams

Alternatively, you can automate this process using a PowerShell script.

You can find the Powershell script in my GitHub Repository 

If Teams is not optimised, you can see a Not optimised banner at top of the Teams. You can click it and select optimise virtual desktop and restart and Teams should be automatically optimised for media audio and video quality inside windows 365.

https://learn.microsoft.com/en-us/azure/virtual-desktop/teams-on-avd#enable-media-optimization-for-teams