Windows 365 Enterprise Architecture · Part 4

Choosing the wrong Windows 365 license type creates the wrong device model for the user. That usually shows up later as confusion: a persistent Cloud PC where the business expected a shared one, or a shared model where users assumed their state would follow them. That is why SKU selection is an architecture decision, not just a procurement choice.

This post explains the three main Windows 365 license models in practical terms: what each one does, how the device model differs, and where organizations commonly misread the licensing behaviour and end up either misconfiguring the service or spending more than necessary.

If you are joining this series here, Part 1 covers the core Windows 365 mental model, Part 2 covers provisioning policy design, and Part 3 covers identity design. The SKU decision sits on top of all three of those foundations.

The three license models

For most enterprise planning conversations, Windows 365 comes down to three operating models: Enterprise, Frontline Dedicated, and Frontline Shared. Each answers a different question about persistence, concurrency, and how many users are expected to share the Cloud PC experience.

Windows 365 Enterprise

Windows 365 Enterprise is the standard 1:1 model. One licensed user receives one personal Cloud PC.

This is the default design for users who need a stable, personalized desktop that persists across sessions. The Cloud PC keeps its state across reconnects. The user returns to the same device identity, the same installed applications, and the same managed environment each time.

This is the right fit for knowledge workers, power users, developers, finance users, and anyone else who needs a consistent working environment rather than a temporary session.

In Windows 365 Enterprise, the relationship is simple: one named user, one primary Cloud PC, one effective provisioning policy per Cloud PC license. A user can hold multiple Enterprise licenses, but Microsoft provisioning still uses the first assigned provisioning policy for those Enterprise Cloud PCs. If different Enterprise builds are required, separate identities are the cleaner and safer design.e Cloud PCs, but all will be provisioned from the same policy. Different builds require separate identities.

Windows 365 Frontline Dedicated

Windows 365 Frontline Dedicated is designed for workers who need their own persistent Cloud PC but do not need it available for continuous use throughout the day in the same way as a full Enterprise user.

A single Frontline license allows up to three Cloud PCs to be provisioned for three named users, with one concurrent session across that license. Each user gets their own dedicated Cloud PC, and each Cloud PC preserves its own state between sessions.

That is the key distinction: Frontline Dedicated is still a persistent per-user model. It is not a shared machine. The savings come from non-concurrent usage, not from removing persistence.

This makes it a strong fit for shift-based roles such as retail, healthcare, contact center, and other workforce models where users need their own environment but are not all active at the same time.

One important correction to a common assumption: Frontline Dedicated does not behave like Enterprise in every assignment scenario, but it also does not give you a free-form way to mix device blueprints casually. The design still needs governance. License efficiency comes from concurrency constraints, not from relaxing architecture discipline.

Windows 365 Frontline Shared

Windows 365 Frontline Shared is the non-persistent shared model.

This is the design for scenarios where multiple users rotate through the same Cloud PC experience one at a time and there is no requirement for a personal persistent environment. The Cloud PC is shared, sessions are non-concurrent, and user session state is not preserved in the same way as a personal persistent Cloud PC.

This model fits kiosk-style access, task-based work, highly standardized workflows, and environments where cost efficiency matters more than personalization.

The important architectural point is that Frontline Shared should not be treated as a cheaper version of Enterprise. It is a different device model entirely. If users expect their own persistent machine, Frontline Shared is the wrong fit.

Comparing the three models

Misconceptions that cause bad design decisions

More provisioning policies do not create more Cloud PCs

For Windows 365 Enterprise, assigning a user to more than one provisioning policy does not create more options and does not create another Cloud PC. The service uses the first assigned provisioning policy for each Cloud PC license and ignores the others for that provisioning event.

That means policy overlap is still a design problem, not a scaling tool.

More licenses do not resolve policy conflicts

If a user has multiple Enterprise licenses, the user can receive multiple Enterprise Cloud PCs, but those Cloud PCs are still provisioned using the same first-assigned provisioning policy for that identity.

Multiple licenses do not let you use one identity to generate different Enterprise builds from different provisioning policies. If you need different builds with clear separation, design for separate identities.

Group targeting does not continuously create more Cloud PCs

Provisioning is tied to license and policy evaluation, not to a constant re-creation loop whenever group membership changes. Once a Cloud PC exists, changing the targeting model does not mean the service simply creates another one in the background. Where architecture changes are needed, the answer is usually controlled lifecycle action, not accidental duplication.

Governance and over-licensing

Windows 365 cost control is mostly an identity and lifecycle governance issue.

Unlike pooled VDI models, Windows 365 does not give you a general concurrency lever for Enterprise cost reduction. If a user has an active Enterprise license, that user is consuming a Cloud PC entitlement whether they sign in often or not.

That makes bad license hygiene expensive. If a user leaves and keeps their Windows 365 license, the cost continues. If a user is licensed in error, you are paying for a service that was never needed. If a role changes and the wrong SKU remains assigned, the environment drifts into both cost waste and design inconsistency.

This is why license assignment should sit inside a proper joiner, mover, leaver process. It should not be handled as a loose manual activity.

How to choose the right SKU

Before assigning a Windows 365 SKU to a user group, answer these questions clearly.

• Does the user need a persistent, personalized environment across sessions?
  • If yes, the choice is usually Enterprise or Frontline Dedicated.
• Does the user work in shifts or in a pattern where non-concurrent access is acceptable?
  • If yes, Frontline Dedicated may be the more cost-efficient fit than Enterprise.
• Does the use case require a shared, non-persistent environment rather than a personal Cloud PC?
  • If yes, Frontline Shared is the better match.
• Do multiple users need to connect to the same desktop experience at the same time?
  • If yes, Windows 365 is not the right answer for that design. Windows 365 does not provide multi-session access within one Cloud PC. That is where Azure Virtual Desktop becomes the more appropriate recommendation.
• Has provisioning policy design already been finalized for the group in scope?
  • SKU assignment should follow architecture, not precede it.
• Is there a process to remove licenses when users move roles or leave the organization?
  • If not, expect unnecessary spend and inconsistent lifecycle control.

SKU selection checklist

Before assigning licenses to any user group, these should already be true.

• The business has decided whether the user needs a personal persistent Cloud PC or a shared model.
• The organization understands that Frontline Dedicated is still a persistent per-user model, not a shared desktop.
• The organization understands that Frontline Shared is a different operating model, not just a discounted Enterprise SKU.
• The provisioning policy design has already been validated for the users in scope.
• The identity model and join model are already settled for that group.
• A joiner, mover, leaver process exists to add and remove licenses in a controlled way.
• Cost expectations are based on the actual Windows 365 operating model, not on VDI-style concurrency assumptions.

The short version is simple: choose the SKU based on the device model the user actually needs. If the persistence and concurrency assumptions are wrong at licensing time, the rest of the design will be wrong as well.