Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Plan the administrative model, licensing, provisioning, and developer experience for Cloud PCs.
Applies to: Windows 365 Enterprise and Windows 365 Flex
Microsoft Dev Box customers can move developer workstation scenarios to Windows 365 while standardizing on a unified Cloud PC platform. The transition changes how administrators organize resources, assign licenses, and deliver Cloud PCs to developers. Most importantly, Windows 365 uses an admin-led, policy-based provisioning model: the Cloud PC is prepared before the developer connects.
What changes when you move to Windows 365
Microsoft Dev Box and Windows 365 both deliver managed cloud workstations, but their resource models and user journeys differ. Use the following comparison to reset expectations before transition.
Administrative object model
| Microsoft Dev Box concept | Windows 365 approach | Transition implication |
|---|---|---|
| Dev center | Windows 365 service managed through Microsoft Intune | Move governance to Intune roles, policies, groups, and Cloud PC settings. |
| Project | No direct project object | Organize access and configuration with Microsoft Entra groups, Intune assignments, naming conventions, and scope tags. |
| Dev box pool | Provisioning policy plus assigned group and license | Design policies around personas, teams, workload profiles, regions, images, and network requirements rather than projects. |
| Dev box definition | Cloud PC license or SKU plus the image and settings in a provisioning policy | Map each definition to an appropriate Windows 365 license option. |
| Catalog or customization tasks | Gallery or custom image, Azure Compute Gallery image, Intune apps and scripts, and Autopilot device preparation | Translate team-required tools into centrally managed image, app, script, and readiness artifacts. |
| Developer portal and self-service creation | Admin-led provisioning; developer connects through Windows App | Replace create-on-demand guidance with an assignment and onboarding workflow. |
No project concept in Windows 365
Windows 365 does not reproduce the Dev Box hierarchy of dev center, project, pool, and definition. A provisioning policy orchestrates creation of Cloud PCs and contains the network, image, configuration, and assignment information. Target policies to Microsoft Entra user groups or Microsoft 365 Groups. Use scope tags with Intune roles when administration must be delegated to specific teams.
If project boundaries previously controlled access, create an explicit replacement design using scope tags and RBAC on Intune. For example, use one Entra group for each developer persona or workload, apply a consistent naming standard to provisioning policies, assign scope tags for delegated administrators, and maintain separate images or app sets only where technical differences require them.
Licensing and cost model
Dev Box uses an Azure consumption-based model. Windows 365 instead requires the appropriate license before a Cloud PC can be provisioned. For Windows 365 Enterprise, each licensed user receives a personally assigned Cloud PC defined by the provisioning policy. Windows 365 Flex supports dedicated or shared models for intermittent, task-based, or nonconcurrent use.
- Inventory active developers and current Dev Box compute profiles.
- Select a Windows 365 edition and size for each persona.
- Assign licenses before assigning the provisioning policy.
- Validate GPU availability in the region you are interested in.
Windows 365 prerequisites
Licensing requirements
- You must have an Intune license to use Intune to manage the devices.
- Windows 365 Enterprise: Users must have licenses for Windows E3, Intune, Microsoft Entra ID P1, and Windows 365 to use their Cloud PC.
- Windows 365 Flex: Users must:
- Have licenses for Windows E3, Intune, and Microsoft Entra ID P1.
- Be added to the Microsoft Entra security group in the provisioning policy to use their Cloud PC.
For the complete list, see Windows 365 requirements | Microsoft Learn.
Windows 365 capabilities for developer scenarios
The following capabilities can replace or extend common Dev Box scenarios. Confirm the status and regional availability of any preview capability before including it in a production transition.
Images and ready-to-code environments
- Windows gallery images: Start with Microsoft-maintained Windows images available from the provisioning policy experience.
- Developer configuration image: Use a ready-to-code Windows 11 image with common developer tools and WSL-based workflows where available.
- Custom images: Import organization-defined managed images for specialized development stacks.
- Azure Compute Gallery: Reuse versioned custom images maintained by the organization.
- Automated preparation: Link Autopilot device preparation so required Intune apps and scripts run before the first connection.
- App and script delivery: Use Intune to deploy SDKs, CLIs, packages, build tools, repositories, and organizational settings.
Compute and workload options
- Choose general-purpose Cloud PC sizes from 2 vCPU through 32 vCPU, with memory and storage options aligned to the workload.
- Use GPU Select, Standard, Super, or Max offerings for supported graphics, visualization, compute-intensive scenarios, and AI needs.
- Use virtualization-based workloads such as WSL, Sandbox, and Hyper-V on eligible non-GPU Cloud PCs with 8 vCPU, 16 vCPU, or 32 vCPU.
- 2 vCPU and 4 vCPU configurations can effectively support less resource-intensive workloads.
- Assign multiple Cloud PCs when a developer needs separate environments for development, testing, or experimentation. This can be done by assigning multiple Windows 365 Flex dedicated licenses or by assigning one Windows 365 Enterprise license with a Windows 365 Flex dedicated license.
- Use Windows 365 Enterprise or Windows 365 Flex license models to match full-time, intermittent, pooled, or shared usage patterns.
- Run suitable local AI models on appropriately sized 16-vCPU or 32-vCPU Cloud PCs for chat, vision, or image-generation workflows without per-prompt token charges from a hosted model.
Management, networking, and security
- Central management: Manage Cloud PCs, apps, settings, compliance, and provisioning policies in Microsoft Intune.
- Networking: Use a Microsoft-hosted network for the simplest managed, zero-trust deployment, or an Azure network connection when direct integration with a customer-managed virtual network is required.
- Delegation: Combine Intune roles and scope tags so delegated administrators see and manage only the intended objects.
- Security: Apply Microsoft Entra Conditional Access, compliance, identity, endpoint security, and redirection controls.
- Monitoring: Use Cloud PC reports, resource performance information, connection-quality data, alerts, and admin insights to identify provisioning and experience issues. Intune Advanced Analytics provides additional insights and can be used as well.
- Single sign-on and resilient connectivity: Configure supported authentication and connection capabilities to reduce sign-in friction and improve session continuity.
Developer experience after transition
The Cloud PC is pre-provisioned
In Dev Box, developers can create machines from a project pool in the developer portal and wait for first-time provisioning. In Windows 365, the administrator assigns the license and provisioning policy. Windows 365 creates and configures the Cloud PC before the developer begins work.
Developers request access to Windows 365 through the organization’s existing fulfillment process, then receive a ready Cloud PC. Use device preparation, Intune app deployment, scripts, and approved images to minimize first-sign-in setup.
Connect with Windows App
Developers can connect to and manage their assigned Cloud PCs through Windows App without navigating to the Dev Portal. Windows App provides a streamlined connection experience across supported device platforms and exposes the user actions appropriate for the assigned Cloud PC.
- Install Windows App from the Microsoft Store or open it on the device.
- Sign in with the work account that has the Windows 365 assignment.
- Select the assigned Cloud PC.
- Connect and complete any organization-required sign-in or compliance checks.
Operational differences
| Experience | Dev Box | Windows 365 |
|---|---|---|
| Machine creation | Developer self-serves from an allowed pool. | Admin assigns license and policy; service pre-provisions the Cloud PC. |
| Entry point | Dev Box developer portal. | Windows App. |
| First connection | May include the provisioning wait. | Cloud PC should already be provisioned and prepared. |
| Environment control | Developer can select from project pools and may apply supported user customizations. | IT defines the approved image, apps, scripts, configuration, network, and policy baseline. |
| User actions | Core Dev Box lifecycle controls. | Streamlined controls such as connect, restart, reset, rename, and settings, subject to policy and edition. |
Transition workflow
- Discover: Export the Dev Box inventory, including users, projects, pools, definitions, images, regions, network connections, schedules, utilization, and costs.
- Classify: Group developers by workload, compute profile, GPU need, network dependency, persistence requirement, and expected concurrency.
- Design the target: Choose Enterprise or Flex, define Entra groups, provisioning policies, scope tags, network options, images, app sets, and security baselines.
- Prepare licensing: Purchase and assign the required Windows 365 licenses before policy assignment.
- Build the environment: Select a gallery image or import a custom image, then add Intune apps, scripts, device preparation, and compliance requirements.
- Pilot: Transition a representative group that includes standard developers, high-compute users, remote users, and users who require internal network access.
- Validate: Confirm provisioning success, Windows App connectivity, tool readiness, repository access, build performance, security controls, reporting, and support procedures.
- Scale and retire: Roll out in waves, monitor experience and cost, then decommission Dev Boxes after data and workflow cutover is complete.
Note: Commit your code and back up any data you need from your current Dev Box, including WSL data, credentials, and local test assets, before transitioning. Your existing device will be reprovisioned as part of the transition, and you’ll receive a new Cloud PC.
Summary
The key shift is from project-based, developer-created Dev Boxes to licensed, policy-provisioned Cloud PCs. Administrators define the image, network, configuration, security, and assignment in Intune; Windows 365 prepares the machine; and developers connect from Windows App. A successful transition maps existing Dev Box projects and pools to personas, groups, policies, and appropriately licensed Windows 365 configurations.
Next step
Inventory your current Dev Box environments, define developer personas, and pilot the corresponding Windows 365 configurations before beginning the broader transition. Reach out to your account manager to get started.