Modern EUC by Wayne Bellows

Category: Windows 365

  • 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.

  • March 31, 2026, is coming: New Azure VNets won’t have outbound internet by default — here’s the EUC-ready fix (NAT Gateway v2)

    March 31, 2026, is coming: New Azure VNets won’t have outbound internet by default — here’s the EUC-ready fix (NAT Gateway v2)

    The change that won’t hurt… until it does

    If you run Azure Virtual Desktop (AVD) or Windows 365 (Cloud PCs) in Azure, you’ve probably relied on a quiet convenience for years:

    Deploy a VM in a subnet and—without doing anything special—it can reach the internet.

    That “it just works” behavior is going away by default for new networks.

    Microsoft has confirmed that after March 31, 2026, newly created Azure Virtual Networks will default to private subnets, meaning no default outbound internet access unless you explicitly configure an outbound method.

    And here’s the trap: nothing breaks on day one. Your existing VNets keep working as they do today. Then, weeks later, someone builds a new VNet (or a new subnet), tries to deploy AVD session hosts or provision Cloud PCs… and suddenly:

    • Hosts can’t download what they need
    • Windows activation and updates don’t behave
    • Intune enrollment/sync gets weird
    • Provisioning workflows fail in ways that look like “AVD is broken” (it’s not)

    Microsoft explicitly notes that certain services (including Windows activation and Windows updates) won’t function in a private subnet unless you add explicit outbound connectivity.

    So, let’s make this change boring—in a good way. ✅

    What exactly is changing on March 31, 2026?

    ✅ What changes

    • New VNets created after March 31, 2026 will default to private subnets (Azure sets the subnet property defaultOutboundAccess = false by default).
    • Private subnets mean VMs do not get “default outbound access” to the internet or public Microsoft endpoints unless you configure an explicit egress method.

    ✅ What does not change

    • Existing VNets are not automatically modified.
    • New VMs deployed into existing VNets will continue to behave as those subnets are configured today, unless you change those subnets.

    Also important: you still have control

    Microsoft’s guidance is “secure by default,” but you can still configure subnets as non-private if you truly need to keep the default outbound behavior for a period of time.
    That said… for EUC, the better long-term move is to standardize on explicit outbound now.

    Why AVD and Windows 365 teams should care (more than most)

    EUC workloads have a long list of dependencies on outbound connectivity. A few high-impact examples:

    AVD session hosts

    • Agent/bootloader downloads and updates
    • Host registration and service connectivity
    • Windows activation + KMS / public activation flows
    • Windows Update / Defender updates
    • App install flows that fetch from internet endpoints (MSIX, Winget, vendor CDNs, etc.)
    • Telemetry and management paths (depending on your architecture)

    Windows 365 (Azure Network Connection / ANC)

    Microsoft is explicit here: for Windows 365 ANC deployments using VNets created after March 31, 2026, Cloud PC provisioning will fail unless outbound internet access is explicitly configured.

    So the question becomes: what’s the cleanest, most repeatable outbound design for EUC networks?

    Your outbound options (EUC decision guide)

    Azure recognizes several “explicit outbound” patterns.
    For EUC, these are the common ones:

    1) NAT Gateway (recommended default for most EUC spokes)

    Best when:

    • You want simple, scalable outbound for session hosts / Cloud PCs
    • You need a predictable egress IP for allow-lists
    • You don’t need deep L7 inspection for all traffic (or you’re doing that elsewhere)

    2) Firewall/NVA + UDR (hub-and-spoke inspection)

    Best when:

    • You need central inspection, TLS break/inspect, egress filtering at scale
      Trade-offs:
      • Complexity and cost
      • SNAT scaling considerations
      • You may still use NAT Gateway with firewall designs (more on that below)

    3) Standard Load Balancer outbound rules

    Best when:

    • You already have SLB, and outbound rules are a deliberate part of your design
      Trade-offs:
    • More moving parts than NAT Gateway for a simple “give the subnet internet” outcome

    4) Public IP per VM (usually a “no” for EUC)

    Trade-offs:

    • Operational overhead
    • Increased attack surface
    • Harder to govern at scale for pooled hosts / Cloud PCs

    For most AVD and Windows 365 environments, the sweet spot is:
    ➡️ NAT Gateway for outbound simplicity and scale.

    And now we have a better version of it.

    Enter NAT Gateway v2: the “make it simple” fix

    Microsoft announced StandardV2 NAT Gateway and StandardV2 Public IPs to match it. The headline improvements are exactly what EUC architects care about:

    • Zone-redundant by default (in regions with Availability Zones)
    • Higher performance (Microsoft calls out up to 100 Gbps throughput and 10 million packets/sec)
    • IPv6 support
    • Flow logs support
    • Same price as Standard NAT Gateway (per Microsoft’s announcement)

    But know the gotchas

    From Microsoft’s NAT SKU guidance:

    • Requires StandardV2 Public IPs (Standard PIP won’t work)
    • No in-place upgrade from Standard → StandardV2 NAT Gateway (replace it)
    • Some regions don’t support StandardV2 NAT Gateway (check your target region list)

    If you’re designing for EUC scale + resilience, the zone redundancy alone is a big deal.

    Walkthrough: Deploy NAT Gateway v2 for AVD / Windows 365

    Below is a practical, EUC-focused setup using the Azure portal.

    Architecture target

    • You have a VNet with one or more EUC subnets (e.g., AVD-Hosts, CloudPCs)
    • You attach one NAT Gateway v2 to those subnets
    • All outbound traffic from those subnets egresses via the NAT’s public IP(s)

    NAT Gateway is associated at the subnet level, and a subnet can only use one NAT gateway at a time (so plan accordingly).

    Step 0: Confirm your subnet posture (private vs not)

    After March 31, 2026, new VNets will default to private subnets.

    In the subnet configuration in Azure:

    • Find Default outbound access
    • If you want the secure-by-default posture, set it Disabled (private subnet)
    • Then ensure you provide explicit outbound (NAT Gateway)

    Note: if you change an existing subnet’s default outbound access setting, existing VMs may need a stop/deallocate to fully apply the change.

    Step 1: Create a StandardV2 Public IP

    NAT Gateway v2 requires a StandardV2 Public IP.

    Azure portal:

    1. Create Public IP address
    2. Set:
      • SKU: StandardV2 (static)
      • IP version: IPv4 (or dual-stack if required)
    3. Create it

    Step 2: Create the NAT Gateway (StandardV2)

    Azure portal:

    1. Create NAT gateway
    2. Set:
      • SKU: StandardV2
      • TCP idle timeout: leave default unless you have a reason
    3. On Outbound IP, attach the StandardV2 Public IP you created
    4. Create

    Microsoft’s announcement emphasizes StandardV2 NAT Gateway is zone-redundant by default in AZ regions.

    Step 3: Attach NAT Gateway v2 to your EUC subnet(s)

    Now associate it with the subnets where your session hosts / Cloud PCs live.

    Option A (from NAT Gateway):

    • NAT Gateway → Networking → add VNet/subnet associations

    Option B (from Subnet):

    • VNet → Subnets → select subnet → set NAT gateway → Save

    Once attached:

    • VMs in that subnet gain outbound connectivity through the NAT Gateway
    • Your egress IP becomes the NAT’s public IP (useful for allow-listing)

    Step 4: Validate (don’t skip this)

    For EUC, I like three quick validations:

    1. Effective routes
    • Confirm the subnet has the expected path for internet-bound traffic (0.0.0.0/0) via the platform egress with NAT.
    1. Outbound IP check
    • From a session host / Cloud PC, verify outbound IP matches your NAT public IP.
    1. EUC-specific smoke tests
    • Windows activation / licensing behavior
    • Windows Update connectivity
    • Intune enrollment/sync (if applicable)
    • Any app deployment mechanisms that pull from vendor CDNs

    Remember: Microsoft explicitly warns that private subnets need explicit outbound for services like Windows activation/updates.

    Common EUC deployment patterns (what I recommend)

    Pattern A: “EUC spoke NAT” (simple + effective)

    • Each EUC spoke VNet has a NAT Gateway v2 attached to EUC subnets
    • Keep routing simple
    • Use NSGs for egress control + consider NAT flow logs for visibility (where needed)

    Pattern B: “Hub inspection + NAT scale”

    If you route everything through a firewall/NVA for inspection, NAT Gateway can still be relevant in designs where you need scalable SNAT characteristics for outbound (especially when you’ve seen firewall SNAT constraints in the wild). This becomes an architecture conversation, but the key is: private subnets force you to be explicit, and NAT Gateway is the simplest explicit egress building block.

    “Do this before March 31, 2026” checklist

    For AVD admins, Windows 365 admins, and EUC architects:

    • Identify where your org creates “new VNets” (projects, regions, subscriptions)
    • Update your EUC network templates to include explicit outbound (NAT Gateway v2 is the default pick)
    • Standardize an allow-listing approach using the NAT’s static public IP(s)
    • Decide logging posture (do you want NAT flow logs for troubleshooting/top talkers?)
    • Run a “new VNet” dry run now (don’t wait for the deadline)
    • For Windows 365 ANC: confirm your provisioning pipelines won’t fail on new VNets without explicit outbound

    Final thought: make your cloud consistent

    This change is “secure by default,” but operationally it creates a nasty split-brain risk: old VNets behave one way, new VNets behave another.

    The easiest way to keep EUC stable is to choose a consistent outbound pattern everywhere. For most AVD + Windows 365 environments, NAT Gateway v2 is the cleanest baseline: zone-resilient, scalable, and straightforward to operate.