Modern EUC by Wayne Bellows

Category: Intune

  • Windows 365 Cloud Apps Just Got Serious: APPX and MSIX Support Changes Everything for Frontline

    Windows 365 Cloud Apps Just Got Serious: APPX and MSIX Support Changes Everything for Frontline

    Windows 365 Cloud Apps went generally available in November 2025, and the concept is compelling: stream individual apps from a Cloud PC to a user’s device, without giving them a full desktop. Think RemoteApp, but cloud-native and managed entirely through Intune.

    The problem? Until this week, Cloud Apps only supported Win32 applications. That meant Microsoft Teams and the new Outlook — both packaged as APPX or MSIX — couldn’t be published through it. For most real-world scenarios, that was a deal-breaker.

    As of the week of March 23, 2026, Microsoft added APPX and MSIX application support to Cloud Apps. It sounds like a packaging update. In practice, it removes the single biggest barrier to Cloud Apps adoption.

    This post covers what Cloud Apps is, how it works architecturally, what this update actually changes, and where it fits alongside a full Cloud PC deployment.

    What Are Windows 365 Cloud Apps?

    Cloud Apps is a delivery model within Windows 365 Frontline that lets you publish individual applications to users instead of provisioning a full Cloud PC desktop for each person.

    The experience from the user’s perspective: they open Windows App, see only the specific apps that have been published to them, and click to launch. The app opens in its own window on their local device — no desktop, no taskbar, no Start menu. Just the app.

    From an architecture perspective, Cloud Apps runs on top of Windows 365 Frontline Cloud PCs operating in shared mode. When a user launches a Cloud App, it initiates a RemoteApp connection to one of the shared Cloud PCs in the pool. The Windows UI is stripped away so only the application window is rendered in the remote session. The user sees an app. Under the hood, it’s a Cloud PC running in shared mode, with concurrency tied to the number of Frontline licences assigned to the provisioning policy.

    The key distinction from a full Cloud PC: users don’t get a persistent desktop environment. There’s no personal desktop, no file explorer, no Start menu. They get access to the specific applications IT has published — nothing more.

    How App Discovery and Publishing Works

    This is where it gets interesting, and where the APPX/MSIX limitation was most painful.

    Cloud Apps discovers available applications by scanning the Start Menu of the underlying Cloud PC image. When you create a provisioning policy with the experience type set to “Access only apps,” Windows 365 enumerates every application that has a Start Menu entry on the image. Those apps are then listed in the Intune admin centre as “Ready to publish.”

    Admins select which apps to publish, and those apps become available in Windows App for all users assigned to the provisioning policy. You can edit display names, descriptions, and icons — but the core app discovery is driven by what’s on the image.

    Here’s the catch that tripped up the original release: the discovery and publishing pipeline only supported Win32 executables. APPX and MSIX packages register themselves differently in Windows — they use the modern app model with package identity, containerised execution, and different Start Menu registration paths. The Cloud Apps discovery engine simply didn’t know how to find them.

    That’s what changed this week. The discovery pipeline now supports APPX and MSIX packages alongside Win32 apps. Any application on the image that creates a Start Menu entry — regardless of packaging format — can now be discovered and published as a Cloud App.

    Why This Matters More Than It Sounds

    If you’re not deep in Windows packaging, “we added APPX/MSIX support” might sound like a minor technical improvement. Here’s why it’s not.

    Microsoft has been steadily moving its own applications to modern packaging formats. Teams is an MSIX package. The new Outlook is an APPX package. Many apps delivered through the Microsoft Store and via Intune’s app catalogue are MSIX. The direction of travel is clear: MSIX is the future of Windows app packaging.

    A Cloud Apps deployment that can only publish Win32 apps is a deployment that can’t publish Microsoft’s own flagship productivity tools. That’s not a niche gap — it’s a fundamental limitation that made Cloud Apps impractical for most organisations.

    With APPX and MSIX support, a Cloud Apps deployment can now publish Teams, the new Outlook, and any other modern-packaged app that’s on the image. The feature goes from “interesting concept with a big asterisk” to “genuinely viable for production frontline scenarios.”

    A Quick Primer: Win32 vs APPX vs MSIX

    For context on why these packaging formats matter and what makes them different:

    Win32 is the traditional application model that’s been around for decades. MSI installers, EXE files, and applications that write directly to Program Files, the registry, and shared system locations. They’re flexible but messy — installs can leave residual files, uninstalls aren’t always clean, and conflicts between applications sharing system resources are common.

    APPX was introduced with Windows 8 for Universal Windows Platform (UWP) apps. APPX packages run in a containerised environment with their own virtualised filesystem and registry. They install cleanly, uninstall completely, and can’t interfere with other apps. The trade-off: they were originally designed for UWP-only, limiting their usefulness for traditional desktop applications.

    MSIX is the evolution that bridges both worlds. It brings the clean install/uninstall behaviour and containerisation of APPX to traditional Win32 and .NET Framework applications. MSIX supports differential updates (only downloading what changed), mandatory digital signing for security, and a 99.96% install success rate according to Microsoft’s data. It’s designed to be the single packaging format for all Windows app types going forward.

    The reason Cloud Apps struggled without APPX/MSIX support is that Microsoft has been packaging its own apps in these formats for years. Teams, the new Outlook, and many Store-delivered apps aren’t Win32 — they’re MSIX or APPX. If your app delivery platform can’t see them, you can’t publish them.

    Cloud Apps vs Full Cloud PC: When to Use Which

    Cloud Apps doesn’t replace a full Cloud PC. They solve different problems for different user personas. Here’s how to think about when each model fits.

    Cloud Apps makes sense when:

    The user needs access to a small number of specific applications — typically two or three. They don’t need a full desktop environment, file management, or the ability to install additional software. Think frontline retail workers who need a POS system and Teams. Field service staff who need a single line-of-business app on shared devices. Contractors who need controlled access to specific tools without a full managed desktop. Seasonal or temporary staff where provisioning and deprovisioning full Cloud PCs per person would be operationally heavy.

    A full Cloud PC makes sense when:

    The user needs a persistent desktop environment with their own files, settings, and application state. They work with multiple applications simultaneously and switch between them throughout the day. They need the ability to open apps ad hoc — not just pre-published ones. Their workflow involves file management, browser-based tools alongside desktop apps, or other activities that need a complete Windows desktop.

    The shared licensing model underneath:

    Both Cloud Apps and shared-mode Frontline Cloud PCs use the same Windows 365 Frontline licensing. The licence model allows unlimited user assignments per licence, but only one concurrent active session per licence at a time. So if you have 50 Frontline licences assigned to a Cloud Apps provisioning policy, up to 50 users can have active Cloud App sessions simultaneously.

    This makes Frontline significantly more cost-effective than Enterprise Cloud PCs for shift-based or part-time workers. You’re not paying for a dedicated Cloud PC per user — you’re paying for concurrent capacity.

    Security Consideration: Published Apps Can Launch Other Apps

    There’s one architectural detail worth flagging that catches some admins off guard.

    When a user launches a published Cloud App, that app runs on a full Cloud PC under the hood. The published app can launch other applications that exist on the Cloud PC image, even if those other apps haven’t been published as Cloud Apps.

    For example: if you publish Outlook as a Cloud App and a user clicks a link in an email, it can launch Edge — even if Edge isn’t published. If an app has a “Open in Explorer” option, it could launch File Explorer.

    For many scenarios, this is fine and even expected behaviour. But if you’re in a regulated environment or need strict application control, you should layer Application Control for Windows (formerly Windows Defender Application Control) on top of Cloud Apps to enforce exactly which executables can run on the underlying Cloud PC.

    Don’t assume that publishing three apps means only three apps can run. The published app list controls what the user can launch directly — not what can execute on the session host.

    What’s Still in Preview

    A few things to be aware of that are still in preview or coming soon:

    Enhanced user experiences for Cloud Apps are in public preview. This includes improved Windows Snap support, full-screen mode, better DPI handling, and visual refinements like borders, shadows, and theme integration. These improvements use the same RemoteApp enhancements available in Azure Virtual Desktop.

    Autopilot Device Preparation support for Cloud Apps is also in public preview. This gives you an alternative to custom images for getting apps onto the underlying Cloud PCs — you can use Autopilot Device Preparation policies to install apps during provisioning, and Cloud Apps will discover them once installed.

    User Experience Sync allows app settings and data to persist between user sessions on shared Cloud PCs. Since Cloud Apps runs on shared-mode Frontline Cloud PCs, user state would normally be lost when a session ends. User Experience Sync preserves settings and data, which is important for apps that store user preferences locally.

    The Bigger Picture

    Cloud Apps has been a “watch this space” feature since it launched. The concept was right — not every user needs a full desktop, and app-only delivery is often the better fit for frontline and contractor scenarios. But the Win32 limitation made it hard to recommend for production use when you couldn’t even publish Teams.

    With APPX and MSIX support, that changes. The feature is now capable of delivering the apps that most organisations actually need in frontline scenarios. Combined with the Frontline shared licensing model, it’s a genuinely cost-effective alternative to provisioning full Cloud PCs for users who only need a handful of apps.

    If you evaluated Cloud Apps earlier and parked it because of app support gaps, it’s worth taking another look. The gap that mattered most is now closed.

    Wayne Bellows is a Technical Account Manager at Nerdio. He writes about Azure Virtual Desktop, Windows 365, Intune, and the EUC industry at modern-euc.com.

  • Why Your Intune Policies Don’t Apply Instantly — And How That’s Changing

    Why Your Intune Policies Don’t Apply Instantly — And How That’s Changing

    If you’re moving from SCCM (Configuration Manager) to Microsoft Intune, one of the first things that catches teams off guard is the timing question: “I made a change — why hasn’t it hit the device yet?”

    With SCCM, you had more direct control over deployment schedules and could see exactly what was happening in the pipeline. Intune works differently. It’s not slower by design — it’s built on a fundamentally different architecture. And once you understand how it actually works, both the current behaviour and the improvements Microsoft is rolling out make a lot more sense.

    This post breaks down what happens from the moment you make a change in Intune to the moment a device reflects it — and what’s being done to close that gap even further.

    Intune Is an Eventual Consistency System (And That’s by Design)

    The first concept to get your head around is eventual consistency. Unlike SCCM’s more synchronous delivery model, Intune doesn’t push changes to devices instantly. Instead, devices converge to a desired state over time.

    Think about using your laptop on a flight with no internet. Everything still works — your files, your apps, your settings — because the device operates independently. The moment you land and reconnect, everything reconciles seamlessly. That’s eventual consistency in action.

    The trade-off is that until a device checks in, Intune doesn’t truly know its current state. Are there pending changes? Has something shifted locally? Is the device still compliant? All of that gets resolved at check-in time — which is exactly why check-in timing matters so much.

    The Three Types of Device Check-Ins

    Not all check-ins are the same. Intune buckets them into three main categories:

    1. Single device check-ins These happen when an admin or user takes an explicit action on a specific device — for example, triggering a sync manually from the Company Portal or the Intune admin centre.

    2. Client-initiated check-ins These happen in the background to keep devices healthy when nothing else is going on. They’re essentially the device saying “just checking in, anything new?” on a regular schedule.

    3. Change-based check-ins (the Fast Lane) These are triggered when a service-side change happens that affects one or more devices. This is where most of the action is — and where Microsoft has been focused on driving improvements.

    What Is the Intune Fast Lane?

    The Fast Lane is how Intune accelerates policy delivery when a change occurs. When a service-side change occurs, Intune sends a push notification to affected devices, instructing them to check in immediately rather than wait for their next scheduled check-in.

    Four things trigger a Fast Lane notification:

    1. An admin modifies the targeting of a payload — for example, adding an Entra group to an existing policy assignment
    2. An admin modifies the contents of a payload — like changing a configuration value in a policy
    3. Entra group membership changes — when users are added or removed from groups that have policies assigned
    4. App updates from the store — automatic updates to assigned apps

    The last two are worth flagging for teams coming from SCCM: these can happen entirely behind the scenes. A group membership change driven by HR provisioning, or an automatic app update, still triggers a Fast Lane notification from Intune’s perspective. It’s worth understanding that the system is reacting to more events than an admin might consciously initiate.

    Where the Delays Actually Happen

    The journey from admin change to device compliance looks like this:

    1. Admin makes a change
    2. Intune compiles the list of affected devices
    3. Intune sends push notifications to those devices
    4. Devices receive the notification and check in
    5. Intune applies the changes
    6. Devices report status back to the admin

    Most of the latency sits in the handoff between step 3 and step 4 — between Intune sending the notification and the device actually checking in. That’s the seam Microsoft has been focused on closing.

    The last-mile delivery of notifications relies on platform providers: WNS for Windows, APNS for Apple, and FCM for Android/Google devices. These are best-effort systems — not guaranteed — and can be affected by the device being offline, network issues, or platform delays. That part of the pipeline isn’t fully visible to Intune (or to you as an admin), which is something Microsoft has been working to address.

    What Microsoft Has Been Improving

    Here’s where it gets genuinely interesting for teams that have been frustrated with policy delivery timing. Microsoft has made — or is very close to releasing — five specific improvements to this pipeline.

    1. Smarter, More Targeted Notifications

    The system was sending a lot of noise. Around 40% of Fast Lane notifications didn’t result in any actual device changes. Meanwhile, 65% of all MDM check-ins also produced no changes. The system was accelerating check-ins for devices that didn’t need it, while potentially backing up devices that did.

    The fix: Intune has overhauled its notification system to be far more precise about which devices actually need to check in. The result is a 35% reduction in unnecessary notifications and the ability to process 40% more sessions. Today, 97% of notification-based check-ins are handled on the first attempt.

    That 97% sounds impressive — and at Intune’s scale, it is. But as Albert Caveo from the Intune team puts it: “If your water heater was working 97% of the time, you wouldn’t brag about the hot showers. You’d never forget that one cold shower.” The goal is to keep pushing toward 99.9%.

    2. Intelligent Check-In Prioritisation

    Previously, Intune’s prioritisation algorithm only distinguished between “maintenance” and “non-maintenance” check-ins. That meant a device falling out of compliance due to a detected threat competed equally with a routine background check-in from a healthy device.

    The new model introduces a priority tier system based on impact. Devices with pending changes can now jump to the front of the queue when capacity limits are hit. And the system is moving from those two broad categories to explicit SLO-backed tiers — so a remote wipe or a new device enrolment will always get handled ahead of a background health check.

    The goal: critical check-ins seldom need to retry, and high-priority check-ins complete within one hour.

    3. No More Dropped Notifications

    In the old model, Intune would send one Fast Lane notification per device per 30-minute window. If multiple changes came through in that window, additional notifications were simply dropped. They weren’t queued — they were gone. The device would catch up at its next scheduled check-in, which could be hours away.

    The new system introduces per-device notification timers. When a change occurs, rather than firing a notification immediately, Intune starts a short timer (a couple of minutes). If more changes come in for the same device during that window, the timer extends slightly — up to 10 minutes — allowing the device to pick up all pending changes in a single check-in.

    After notifying, if there are still more changes queued, Intune will always schedule another notification rather than dropping it. The practical outcome: every change you make will result in a push notification. No more changes silently falling through because of notification window collisions.

    4. Fast Lane Expansion to More Payloads

    The Fast Lane previously didn’t cover everything. Scripts, Win32/classic apps, custom compliance policies, and payloads delivered through the Intune Management Extension (IME) or MMPC gateway had inconsistent Fast Lane coverage.

    That’s changing. Fast Lane notifications are being expanded to cover all gateways and all payload types, including IME-delivered content on both Windows and Mac. The experience will be consistent regardless of how a payload is delivered.

    5. Better Windows Notification Reliability via IC3

    For Windows specifically, Intune is adding a second notification channel alongside the native Windows notification service (WNS). The new channel uses IC3 — the same communications protocol that Microsoft Teams uses — delivered via the Intune Management Extension.

    This gives Intune more control over end-to-end notification delivery on Windows, including delivery receipts, better diagnostics, and the ability to reason across all pending changes and device actions in one place. It also lays the groundwork for future capabilities like presence awareness and more targeted notifications.

    The main thing you need to ensure on your end: keep your network and firewall rules up to date with the required Intune network endpoints. Microsoft publishes these, and they occasionally change as new capabilities roll out.

    Bonus: iOS Maintenance Check-In Optimisation

    For iOS specifically, Microsoft has redesigned how maintenance check-ins are handled. Previously, iOS devices had three service-initiated maintenance check-ins daily (roughly every eight hours), and during peak hours these were accounting for up to 40% of all Intune traffic — most of which produced no device changes.

    The new model is smarter: during peak hours, if a device has already checked in recently, the maintenance check-in is deferred. During off-peak hours, it continues as normal. The result: 99.5% of changes to iOS devices are now delivered faster, while overall delayed check-ins across all platforms are reduced by 10%.

    What This Means for Your SCCM Migration

    If you’re mid-migration or planning one, here are the practical takeaways:

    You don’t need to change how you work. All of these improvements are being built directly into the Intune platform. There are no configuration switches to flip or extra steps to take. They apply across the board.

    Understand the model, not just the tools. The eventual consistency model is genuinely different from SCCM. Policies don’t hit devices the instant you save them — but with the improvements above, the window between “change made” and “device updated” is shrinking significantly for anything that matters.

    Watch your network endpoints. The IC3/IME notification improvements require up-to-date firewall and network rules. Worth a check with your networking team if you’re seeing notification delivery issues.

    Use the Fast Lane triggers intentionally. Know that changes to Entra group membership — not just explicit policy changes — trigger Fast Lane notifications. Factor that into how you design your group structures and assignment targeting.

    Closing Thoughts

    Intune timing has historically been one of the more frustrating aspects of the SCCM-to-cloud migration conversation. The “eventual” in eventual consistency felt a little too eventual at times. What’s encouraging about Microsoft’s current direction is that they’re not just adding more notifications or shorter timers — they’re building genuine intelligence into the system. Priority awareness, noise reduction, smarter notification timers — these are architectural changes, not patches.

    For teams managing thousands of endpoints, the difference between “it’ll apply within the next maintenance window” and “critical changes apply within the hour” is meaningful. And that’s the direction Intune is heading.

    Adapted from the Microsoft session “Intune timing demystified: what really happens behind the scenes” presented by Albert Caveo, Principal Product Manager, Microsoft Intune Core Platform team.