In Part 1 we built the provisioning policy and wired it to a group with size/capacity. In Part 2, we’ll actually publish the apps, tweak their details, undo changes when needed, and explain how licensing & concurrency work (with a simple diagram).
Once your first Frontline Cloud PC (Shared mode) finishes provisioning, the image’s Start-menu apps appear in Windows 365 → All Cloud Apps as Ready to publish.
You can:Publish, Edit, Reset, and Unpublish apps here. Deletion is tied to the policy assignment (more on that below).
Publish an app (All Cloud Apps)
Intune Admin Center → Devices → Windows 365 → All Cloud Apps
Pick one or more apps (Word, Excel, PowerPoint and Edge) with status Ready to publish → Publish
Watch the status flow:
Ready to publish → Publishing → Published
Once Published, the app appears in Windows App for all users assigned to the provisioning policy.
All Cloud Apps list (Ready → Publishing → Published)
If an app shows Failed: Unpublish it, then publish again. Check that the Start-menu shortcut on your image is valid (path/command still exists).
Edit an app (safe, instant updates)
For a published or ready app, select Edit to adjust:
Display name
Description
Command line (e.g., parameters)
Icon path index
Changes inherit scope tags & assignment from the provisioning policy, and updates are immediate in Windows App.
Edit dialog (name/description/command/icon index)
Reset an app (rollback to discovered state)
If you went too far with edits, use Reset to revert back to whatever was discovered from the image originally (name/icon/command). Great for quick experiments.
Reset confirmation
Unpublish (and how “delete” works)
Unpublish: App status goes Published → Ready to publish and the app disappears from Windows App. Its edited details are reset.
Delete: There isn’t a “delete app” button—Cloud Apps are discovered from the image. To truly remove an app from scope, remove the provisioning policy’s assignment (or update the image so the Start-menu shortcut no longer exists).
Unpublish action
Accessing apps (Windows App)
Users launch Windows App (Windows/macOS/iOS/Android) and see the Published apps. Selecting an app starts a session on a Frontline Cloud PC (Shared mode).
A published app can spawn other apps on that Cloud PC when needed (e.g., Outlook opening Edge from a link), even if the other app isn’t separately published.
To tightly control what can launch, use Application Control for Windows policies.
Frontline (Shared mode) is built for brief, task-oriented access with no data persistence per user session. Think “one at a time” use of a shared Cloud PC.
The rules!
1 Frontline license = 1 concurrent session.
You can assign many users to the policy, but only N can be active at once (where N = number of Frontline licenses you assigned to that policy).
When a user signs out, their data is deleted and the Cloud PC is free for the next user.
There’s no concurrency buffer for Frontline Shared mode (and none for GPU-enabled Cloud PCs).
Monitoring concurrency (what to look at)
Frontline connection hourly report: See active usage over time; verify you’re not hitting limits.
Frontline concurrency alert: Get notified if you breach your concurrency threshold.
Note: Concurrency buffer doesn’t apply to GPU or Frontline Shared Cloud PCs—plan capacity accordingly.
Practical sizing tip: Start with a license count that matches your peak simultaneous users for that group/policy. Watch the hourly report for a week, then adjust up/down.
Troubleshooting checklist
Published but not visible? Confirm the user is in the assigned group and is using the latest Windows App.
Failed on publish? Unpublish → Publish. Validate the Start-menu shortcut on the image and any custom command-line parameters.
Unexpected app launches (e.g., Edge opens)? That’s normal when an app calls another binary. Use Application Control if you must restrict it.
Hitting concurrency: Users 1..N can connect; N+1 waits. Increase Frontline licenses on the policy or split users into multiple policies sized per peak.
I hope you find this helpful information for creating a Cloud App. If I have missed any steps or details, I will be happy to update the post.
This is part one of a two-part series on Windows 365 Cloud Apps. In this post, we’ll walk through what Cloud Apps are and how to create the provisioning policy with PowerShell. In part two, we’ll publish the apps themselves. I’ll also include the PowerShell script that uses Azure/Graph REST APIs.
What is Windows 365 Cloud Apps?
Windows 365 Cloud Apps let you give users access to specific apps streamed from a Cloud PC—without handing out a full desktop to everyone. Under the hood, Cloud Apps run on Windows 365 Frontline Cloud PCs in Shared mode. That licensing model is designed for shift or part-time staff: many users can be assigned, but only one active session per license at a time.
Think of it as “just-the-apps” VDI: Outlook, Word, your line-of-business app—delivered from the cloud—with the management simplicity of Windows 365 and Intune.
Why customers care: You streamline app delivery, lower overhead, and modernize VDI without building and babysitting a big remote desktop estate.
Cloud Apps vs AVD Published Apps vs “Traditional” VDI Published Apps
Topic
Windows 365 Cloud Apps
Azure Virtual Desktop Published Apps
Traditional VDI Published Apps
What users see
Individual apps streamed from a Cloud PC; no full desktop
Individual apps from session hosts in Azure Virtual Desktop
Individual apps from on-prem or hosted RDS/Horizon/Citrix farms
Infra you manage
Cloud PC lifecycle via Intune; Microsoft operates the fabric
You design & operate host pools, scaling, FSLogix, images
You run the farm: brokers, gateways, hypervisors, storage
Licensing / sessions
Frontline: many users per license, 1 active session per license
Per-user/per-device or CALs + Azure consumption; multiple sessions per host
Per-user/device + on-prem infra costs
Admin plane
Intune + Windows 365
Azure Portal + ARM + Host pool automation
Vendor consoles + on-prem change management
App packaging
Start-menu discovered apps from the image (MSIX/Appx discovery expanding)
Image: Set $ImageType (e.g., "gallery") and $ImageId for your chosen image.
Region: $RegionName (e.g., australiaeast or "automatic").
Assignment:
$GroupId: Entra group whose members should see the Cloud Apps.
$ServicePlanId: the Frontline size (e.g., FL 2vCPU/8GB/128GB in the example).
$AllotmentCount: how many concurrent sessions you want available for this policy.
$AllotmentDisplayName: a friendly label that shows up with the assignment.
Verification/Polling: The script dumps the policy with assignments and can optionally poll for provisioned Cloud PCs tied to the policy.
Get-or-Create a Cloud Apps provisioning policy (userExperienceType = cloudApp, provisioningType = sharedByEntraGroup, Azure AD Join in a specified region).
Assigns the policy to an Entra group with service plan, capacity (allotment), and a friendly label
App discovery: Ensure the app has a Start menu shortcut on the image. That’s how Cloud Apps gets its list.
Security baselines: If your tenant enforces restrictions on PowerShell in the image at discovery time, discovery can fail.
MSIX/Appx: Discovery is expanding—classic installers show up first; some Appx/MSIX apps (e.g., newer Teams) may not appear yet.
Concurrency math: Active sessions for the policy are capped by assigned Frontline license count on that policy.
Schema drift: These are beta endpoints. If you hit a property/enum change, the script’s warnings will surface the response body—update the field names accordingly.
What’s next (Part 2)
We’ll move to All Cloud Apps to publish the discovered apps, tweak display name/description/command line/icon index, confirm they appear in Windows App, and cover unpublish/reset workflows—with your screenshots.
I hope you find this helpful information for creating a Cloud App using PowerShell. If I have missed any steps or details, I will be happy to update the post.
Recent Comments