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.
Windows 365 delivers cloud-based Windows computing instances called Cloud PCs that provide users with personalized, optimized desktop experiences. Each Cloud PC integrates with the following Microsoft Cloud services to provide enterprise-grade security, management, and connectivity:
Intune for device management, security policies, and application deployment
Microsoft Entra ID for identity management and access control
Azure Virtual Desktop for secure remote connectivity and session management
Cloud PCs run in the Windows 365 service and provide users with consistent Windows desktop experiences that they can access from any device, anywhere. This article focuses on Windows 365 deployments that use Azure network connections to integrate with your existing network infrastructure and on-premises resources.
The Windows 365 shared responsibility model
Windows 365 is a software as a service (SaaS) solution. Microsoft manages some components in Windows 365 services, and you manage other components. Your level of responsibility depends on your architecture pattern for deployment.
The Windows 365 management responsibilities are divided into three areas:
Deployment: Plan and deploy the component of the service.
Life cycle: Manage the component throughout its life cycle, such as patching and securing.
Configuration: Configure the component to apply required settings for a scenario.
The following diagram shows the responsibility matrix of a Windows 365 deployment that uses the recommended Microsoft-hosted network, Microsoft Entra join, and gallery images with Microsoft Windows Autopatch. This configuration doesn't require you to manage many components and life cycle stages, and it provides many benefits.
Note
The following diagram represents the responsibilities from the infrastructure perspective, such as setting up the hardware and network and maintaining them. It doesn't include the Windows 365 or Intune tenant subscription setup.
Download a PowerPoint file of this architecture.
The following diagram shows a typical Windows 365 deployment that uses an Azure network connection. It shows the components that Microsoft manages and the components that you manage across the life cycle stages of a Cloud PC.
Download a PowerPoint file of this architecture.
Recommended architecture pattern
We recommend that you deploy Windows 365 with the following components to get a SaaS experience:
- Microsoft Entra join
- A Microsoft-hosted network
- Gallery images
- An Intune-based mobile device management (MDM) service with app and OS configuration
- A Windows 365 app for Cloud PC access
This pattern provides the maximum benefits of the service.
Download a PowerPoint file of this architecture.
The preceding architecture pattern maximizes the value of Windows 365 and provides the following benefits:
- Simplified and faster deployment
- Minimal to zero dependencies
- Full Zero Trust framework support
- Simplified troubleshooting flows
- Self-service user troubleshooting
- Low overhead and management
- Highest maturity model of software and application delivery
The Windows 365 service architecture
The following diagram represents the components in the Windows 365 service. This architecture uses Intune and Microsoft Entra ID, which are core requirements of Windows 365. It also includes optional components such as Azure Virtual Network. It shows Azure network connection and Microsoft-hosted network options, which are mutually exclusive.
Download a Visio file of this architecture.
The following sections expand on the Azure network connection options.
Virtual Desktop
Virtual Desktop is an Azure-based virtual desktop infrastructure solution. Microsoft manages Virtual Desktop. It provides a platform as a service (PaaS)-style solution. Windows 365 uses the network management components of Virtual Desktop to enable connectivity to Microsoft-hosted Cloud PCs. These components include the Virtual Desktop gateway service, a connection broker service, and a web client service. They provide seamless connection to Windows 365 Cloud PCs.
For more information, see Virtual Desktop for the enterprise.
Download a Visio file of this architecture.
Note
Windows 365 uses the components in the Virtual Desktop control plane to facilitate user and Cloud PC connections. Therefore, it inherits most of the connection-related capabilities of Azure Virtual Desktop. Familiarize yourself with how Virtual Desktop networking operates when you design the Azure network connection architecture in this article.
Intune
Intune is a cloud-based endpoint management solution that you can use to view and consume reports and manage the following elements:
- App delivery
- Windows updates
- Device management configurations
- Security policies
Intune simplifies app and device management across many devices, including mobile devices, desktop computers, and virtual endpoints.
You can use Intune to protect the access and data on organization-owned and personal devices. Intune also has compliance and reporting features that support the Zero Trust security model. For more information, see Create a device configuration profile.
Architecture patterns
An architecture pattern describes components and shows configurations that you can use to deploy a service or product. For more information, see "Hosted on behalf of" architecture.
See the following Azure network connection patterns:
Azure network connection with Microsoft Entra join: In this pattern, Microsoft Entra-joined Cloud PCs use an Azure network connection to connect to resources in on-premises environments that don't require Kerberos or Windows New Technology LAN Manager (NTLM) authentication. For example, Cloud PCs might connect to line-of-business (LOB) applications, file shares, or other applications.
Azure network connection with Microsoft Entra hybrid join: In this pattern, Microsoft Entra hybrid-joined Cloud PCs use an Azure network connection to domain join with an on-premises Microsoft Entra ID domain controller. The Cloud PC authenticates with the on-premises domain controller when users access the Cloud PC, on-premises apps, or cloud apps that require Kerberos or NTLM authentication.
Azure network connection architecture patterns
For some patterns, the Windows 365 service connects to on-premises environments via Virtual Network by using Azure ExpressRoute or a site-to-site VPN. An Azure network connection, which is an Intune object, represents this connectivity method. The Azure network connection enables Cloud PCs to connect to on-premises resources such as Windows Server Active Directory or LOB apps.
The Windows 365 service uses this connection during Cloud PC provisioning to join Cloud PCs to an on-premises Microsoft Entra domain and perform health checks to ensure provisioning readiness.
The following table lists a dependency for an Azure network connection for Microsoft Entra hybrid join architecture. Windows 365 runs an automatic health check on this dependency.
| Dependency | Windows 365 check | Recommendations |
|---|---|---|
| Microsoft Entra Connect | Checks if Microsoft Entra Connect is set up and finishes successfully | - Set up the Microsoft Entra Connect sync interval with the default or lowest value. Longer sync intervals increase the possibility of a Cloud PC provisioning failure in production because of a timeout. For more information, see Microsoft Entra hybrid join failure. - Set up domain controller replication for Windows Server Active Directory from a server in the same datacenter as the Windows 365 Azure network connection. This method provides faster replication. - Set up Microsoft Entra ID domain controller replication with a default value. |
The following table lists dependencies for an Azure network connection for Microsoft Entra hybrid join or Microsoft Entra join architecture. Windows 365 runs automatic health checks on these dependencies.
| Dependency | Windows 365 check | Recommendations |
|---|---|---|
| Azure tenant readiness | Checks if Azure subscription is enabled, with no blocking restrictions, and is ready for use | - Use an account that has the right privileges to manage the Azure, Intune, and Windows 365 subscriptions. For more information, see Role-based access control. - Disable or modify Azure policies that prevent the creation of Cloud PCs. For more information, see Restrict allowed virtual machine (VM) SKUs. - Make sure the subscription has sufficient resource quotas for networking and general limits based on the maximum number of Cloud PCs that you want to create. Examples include the network gateway size, IP address space, size of the virtual network, and bandwidth required. For more information, see Networking limits and General limits. |
| Azure virtual network readiness | Checks if the virtual network is in a supported Windows 365 region | - Create the virtual network in a Windows 365-supported Azure region for Cloud PC provisioning. - Create at least one subnet, in addition to the default subnet, to deploy the Cloud PC virtual network adaptors. - Create shared network services, such as Azure Firewall, VPN gateways, or ExpressRoute gateways, in a separate virtual network to allow for routing controls and expansion of deployment. In virtual networks, apply network security groups (NSGs) that have appropriate exclusions to allow the required URLs for the Windows 365 service. For more information, see Networking requirements and NSGs. |
| Azure subnet IP address usage | Checks if there are sufficient IP addresses available | - Create the virtual network with sufficient IP addresses to handle the Cloud PC creation and temporary IP address reservation during reprovisioning. We recommend that you use an IP address space that's 1.5 to 2 times the maximum Cloud PCs that you deploy for the cloud. For more information, see General network requirements. - Treat the Azure virtual network as a logical extension of your on-premises network. Assign unique IP address space across all your networks to avoid routing conflicts. |
| Endpoint connectivity | Checks if the external URLs needed for the Cloud PC provisioning are reachable from the virtual network | - Allow all URLs required for Cloud PC provisioning via the Azure virtual network. For more information, see Allow network connectivity. - Use Azure Firewall to take advantage of Windows 365, Azure Virtual Desktop, and Intune fully qualified domain name (FQDN) tags. Use the tags to create application rules and allow URLs required for Windows 365 Cloud PC provisioning. For more information, see Use Azure Firewall to manage and secure Windows 365 environments. - Bypass or exclude Remote Desktop Protocol (RDP) traffic from any network inspection, proxying, or manipulation device to avoid latency and routing problems. For more information, see Traffic interception technologies. - From the user device and network side, allow the Windows 365 service URLs and ports for proxy and network inspections. - Allow Azure internal IP addresses 168.63.129.16 and 169.254.169.254. These IP addresses provide communication with Azure platform services such as metadata or heartbeat. For more information, see the following resources: - IP address 168.63.129.16 - Azure Instance Metadata Service - Virtual Network FAQ |
| Intune enrollment | Checks if Intune allows Windows enrollment | - Ensure that you set Intune device type enrollment restrictions to allow the Windows MDM platform for corporate enrollment. - For Microsoft Entra hybrid join, set up devices automatically by configuring the service connection point for each domain in Microsoft Entra Connect or by using the targeted deployment model. For more information, see Configure Microsoft hybrid join and Microsoft Entra hybrid join targeted deployment. |
| Microsoft app permissions | Checks the Windows 365 app for permissions on the customer Azure subscription, resource group, and virtual network levels | - Ensure that the account you use to set up the Azure network connection has read permissions on the Azure subscription where you create the Azure virtual network. - Ensure that the Azure subscription doesn't have policies that block permissions for the Windows 365 Microsoft-managed app. The app must have permissions at the subscription, resource group, and virtual network levels. For more information, see Azure requirements. |
| Localization language pack | Checks if the language pack download locations are reachable | - Ensure that the firewall rules in the Azure virtual network allow URLs required for the appropriate version of Windows images. For more information, see Provide a localized Windows experience. |
| RDP Shortpath | Checks if the User Datagram Protocol (UDP) configurations are set up for you to connect | - Enable RDP Shortpath for Cloud PC access to take advantage of UDP's resilience. For more information, see Use RDP Shortpath for public networks with Windows 365 and Use RDP Shortpath for private networks with Windows 365. |
| Intune license | Checks if the tenant has appropriate Intune licenses to use Windows | - Ensure that you have the proper Intune licenses assigned to you in accordance with the licensing requirements. |
| Single sign-on (SSO) check | Checks if the Kerberos server object is created in Windows Server Active Directory and synced to Microsoft Entra ID | - Ensure that you select the SSO option in the provisioning policy. This option enables you to connect to the policy's Cloud PC by using sign-in credentials from an Intune-managed physical device that's domain joined or Microsoft Entra joined. For more information, see Continue creating provisioning policies. |
| Domain Name System (DNS) name resolution | Checks if the DNS in the Azure network connection can resolve on-premises Active Directory domain | - Configure Azure virtual network with the name resolution of an on-premises Microsoft Entra domain by using a custom DNS, private DNS, or private resolver. For more information, see Azure DNS. - Ensure that the DNS servers that you configure in the virtual network reside in the same region and can register newly provisioned Cloud PCs without delay. Avoid DNS referral or redirections to prevent propagation delays, which can result in provisioning delays or failures. |
| Microsoft Entra domain join | Checks that the credentials provided for Microsoft Entra domain join are valid and Cloud PCs can be domain joined | - Ensure that the account for Microsoft Entra domain join has permissions on the Microsoft Entra organizational unit specified in the Azure network connection configuration. - Ensure that the account isn't a standard user account with a domain join limitation. For more information, see Default limit for the number of workstations that a user can join to the domain. - Ensure that the account syncs to Microsoft Entra ID. - Ensure that the organizational unit specified in the Azure network connection doesn't have object limits. For more information, see Increase the computer account limit in the organizational unit. |
For more information, see Azure network connection health checks in Windows 365.
Azure network connection building blocks recommendations
This section describes the building blocks of the Windows 365 Azure network connection architecture pattern.
Azure subscription
Windows 365 usage in an Azure network connection architecture pattern involves two types of Azure subscriptions, a Microsoft subscription and a customer subscription.
Windows 365 uses the hosted on behalf of model to deliver services to Windows 365 customers. This model provisions and runs the Cloud PC in Azure subscriptions that Microsoft owns. The network adapter of the Cloud PC is provisioned in a customer's Azure subscription. The following diagrams show two Azure network connection architecture patterns. You use your own Azure subscription and virtual network.
The following architecture pattern uses a Microsoft Entra join identity to manage the Cloud PC.
Download a Visio file of this architecture.
The following architecture pattern uses Microsoft Entra hybrid join identity to manage the Cloud PC. This architecture requires line-of-sight network communication with Active Directory Domain Services (AD DS) domain controllers in on-premises environments.
Download a Visio file of this architecture.
| Component | An Azure subscription that hosts the virtual network that provides connectivity for a Cloud PC to an on-premises environment and the internet. |
|---|---|
| Architecture patterns | - Azure network connection for Microsoft Entra join - Azure network connection for Microsoft Entra hybrid join |
| Recommendations | - Create or use a subscription that has a virtual network and ExpressRoute or VPN gateways to provide a connection back to an on-premises environment. - Create a dedicated resource group for a Cloud PC to provide permission and resource management. - Exclude Cloud PC resource groups and virtual networks from Azure policies that prevent automatic creation and deletion of virtual network interface card objects or the assignment and release of IP addresses. For more information, see Lock your resources to protect your infrastructure and Azure requirements. - Create dedicated virtual networks for better IP address management and routing controls. |
Virtual Network and hybrid connection
Windows 365 architecture patterns that are based on an Azure network connection require one or more Azure virtual networks. These virtual networks provide connectivity to both on-premises environments and the internet for Cloud PC provisioning. The virtual network adapter of the Cloud PC is provisioned in the Azure virtual network of the customer-owned subscription.
You can deploy Azure networking with varying design sophistication based on your existing on-premises networking or Azure networking. For more information about a basic hybrid network design, see Implement a secure hybrid network.
Consider the following factors when you design an Azure virtual network architecture:
IP address space: The size of IP address space depends on the number of Cloud PCs. Plan for at least 1.5 times the maximum number of Cloud PCs that you deploy. You use the extra IP addresses when you provision and deprovision Cloud PCs.
Name resolution: Cloud PCs use a DNS process to resolve the on-premises domain name in a Microsoft Entra hybrid join deployment or to resolve internet resources or Azure resources in a Microsoft Entra join deployment model.
To use your existing on-premises DNS infrastructure, configure the IP addresses of one or more DNS servers for name resolution. For more information, see DNS requirements.
Ensure that the DNS server IP addresses that you configure in the Azure virtual network reside in the same region as the Cloud PC. Avoid redirecting DNS registration requests to other regions. Redirection can result in delayed or failed deployments and Azure network connection health checks.
For Azure DNS-based name resolution, use the public or private Azure DNS option or the Azure DNS Private Resolver option. For more information, see Azure DNS documentation.
Network topology: Azure networking supports topologies to accommodate different use cases.
Hub-spoke topology with virtual network peering: This simple topology isolates services within dedicated hub and spoke virtual networks. Shared services include Azure Firewall and network gateways. Use this topology if you deploy Cloud PCs in one or more spoke virtual networks within a simple, single-site environment. For more information, see Hub-spoke network topology.
Hub-spoke topology with Azure Virtual WAN: Virtual WAN is an Azure networking service that combines networking, security, and management capabilities for complex network requirements. Use this topology for multi-site, multiple-region deployments that have specific firewalling and routing requirements. For more information, see Hub-spoke network topology with Virtual WAN.
Network gateways: Azure network gateways provide connectivity from a virtual network to an on-premises network. You can choose between VPN and ExpressRoute network gateways. Before you determine your method of connectivity, consider your Cloud PC's maximum bandwidth requirements. Both VPN and ExpressRoute gateways have various tiers, or SKUs, that provide different amounts of bandwidth and other metrics. For more information, see Connect an on-premises network to Azure by using ExpressRoute.
Routing configurations
Windows 365 uses automated health checks to determine the health and readiness of your environment to provision Microsoft Entra join or Microsoft Entra hybrid join Cloud PCs in an Azure network connection-based architecture. Without proper routing configurations in your Azure virtual network and associated networking services, Cloud PC deployments are likely to experience delays or failure.
To optimize routing for the Windows 365 network architecture, follow these recommendations:
Add required URLs to the allowlist: In Microsoft Entra hybrid join and Microsoft Entra join Azure network connection models, ensure that OS antivirus, network firewalls, and load balancers allow the required URLs for each Cloud PC. For more information, see Allow network connectivity.
Use Azure FQDN tags: When you use the Azure Firewall service, apply Azure FQDN tags to allow required URLs for Azure Virtual Desktop, Windows 365, and Intune. For more information, see Use Azure Firewall to manage and secure Windows 365 environments.
Enable pass-through: Windows 365 uses RDP, which is sensitive to latency from traffic inspection devices, such as a firewall or a Secure Sockets Layer (SSL) decryption appliance. Latency can result in a poor experience. Disable traffic inspection of these URLs and enable pass-through. For more information, see Traffic interception technologies.
Bypass proxy: Cloud and traditional proxy services are useful for internet access but introduce latency in RDP connections. This latency occurs when the connection from the user's physical device or from the Cloud PC is forced through a proxy. It results in frequent disconnections, lags, and sluggish response times. Set .wvd.microsoft.com and Windows 365 gateway IP address ranges to bypass proxy services on the following components:
- The user's physical device
- The network that the physical device connects to
- The Cloud PC
For more information, see Optimize RDP connectivity for Windows 365.
Ensure shortest path routing: Ensure that RDP traffic from a Cloud PC follows the most direct route to Virtual Desktop service endpoints. The ideal path is from a virtual network to the Virtual Desktop gateway IP address via the internet. Also ensure that RDP traffic from the user's physical device reaches the Virtual Desktop gateway IP address directly. This configuration ensures optimal routing and doesn't degrade the user experience. Avoid routing RDP traffic to the internet via cloud proxy services or on-premises networks.
Enable RDP Shortpath: Enable RDP Shortpath-based access for user networks, Azure networks, and Cloud PCs. RDP Shortpath uses UDP to transmit RDP traffic. Unlike Transmission Control Protocol (TCP), UDP is resilient to high-latency network connections. UDP also takes maximum advantage of the available network bandwidth to efficiently transfer RDP packets, which leads to an improved user experience. For more information, see Use RDP Shortpath for public networks with Windows 365.
Evaluate Cloud PC placement: For an optimal user experience and routing performance, determine where customers reside in relation to the work apps or network that they access. Also consider the time that customers spend accessing LOB apps compared to the overall time that they access other apps.
Consider the following deployment options for Cloud PC placement:
Deployment option 1: When customers primarily work in LOB apps, such as Microsoft 365 apps, this model reduces latency for those apps by placing the Cloud PC in the same region as the LOB apps (Geography B). This setup prioritizes performance for LOB access, even if the gateway is physically closer to a user in a different region (Geography A). The following diagram shows a traffic flow from the user to the LOB apps.
Download a PowerPoint file of this architecture.
Deployment option 2: If customers occasionally access LOB apps in Geography B, deploying a Cloud PC closer to the customers optimizes the Cloud PC access latency over LOB apps access latency. The following diagram shows a traffic flow for this scenario.
Download a PowerPoint file of this architecture.
AD DS recommendations
In a Microsoft Entra hybrid join architecture, an on-premises AD DS infrastructure serves as the identity source of authority. A properly configured and healthy AD DS infrastructure improves the success of a Windows 365 deployment.
On-premises AD DS supports many configurations that have various levels of complexity. The following recommendations cover only the baseline best practices.
For a Microsoft Entra hybrid join scenario, you can deploy AD DS in Azure VMs. You can also use a hybrid network connection to provide a direct line of sight to your on-premises Microsoft Entra domain controller. For more information, see Implement a secure hybrid network.
For a Microsoft Entra join scenario, follow the reference architecture that integrates on-premises Active Directory domains with Microsoft Entra ID.
Windows 365 uses a watchdog service as part of automated testing. The service creates a test VM account that shows as disabled in the organizational unit that the Azure network connection configuration specifies. Don't delete this account.
Decommissioned Cloud PCs in the Microsoft Entra hybrid join model leave behind disabled computer accounts that require manual cleanup in AD DS.
Microsoft Entra Domain Services doesn't support Microsoft Entra hybrid join, so it can't function as the identity source in that setup.
DNS recommendations
In an Azure network connection deployment architecture, DNS servers or a DNS service in an Azure virtual network serve as crucial dependencies. A healthy infrastructure ensures reliable operation.
For a Microsoft Entra hybrid join configuration, DNS must resolve the domain that the Cloud PC joins. You have several configuration options. The simplest option is to specify your DNS server IP address in the Azure virtual network configuration. For more information, see Name resolution that uses your own DNS server.
For complex infrastructures, such as multiple-region or multiple-domain setups in Azure and on-premises environments, use a service like Azure DNS private zones or DNS Private Resolver.
Cloud PC connection recommendations
Set up deployed Cloud PCs to allow uninterrupted connection flow to and from the Virtual Desktop gateway service. When you deploy apps as part of a Windows OS configuration, consider the following recommendations:
Ensure that the VPS client doesn't launch when the user signs in because it can disconnect the session when the VPN tunnel establishes. Then the user must sign in again.
Configure the VPN, proxy, firewall, and antivirus and anti-malware apps to allow or bypass traffic for IP addresses
168.63.129.16and169.254.169.254. This architecture uses these IP addresses for communication with Azure platform services, such as metadata and heartbeat.For more information, see the following resources:
Don't manually modify the IP addresses of Cloud PCs because it might result in permanent disconnection. Azure networking services assign IP addresses with an indefinite lease and manage them throughout the Cloud PC life cycle. For more information, see Allocation methods.
Contributors
Microsoft maintains this article. The following contributors wrote this article.
Principal author:
- Ravishankar Nandagopalan | Senior Product Manager
Other contributors:
- Paul Collinge | Principal Product Manager
- Claus Emerich | Principal Product Manager
- David Falkus | Principal Product Manager
- Bob Roudebush | Technical Leader and Cloud/Developer Technologist
- Matt Shadbolt | Principal Product Manager, Windows Cloud Experiences
To see nonpublic LinkedIn profiles, sign in to LinkedIn.
Next steps
- Plan your Cloud PC deployment
- Windows 365 architecture
- Windows 365 identity and authentication
- Cloud PC life cycle in Windows 365
- AD DS overview
- Data encryption in Windows 365
- Understand Virtual Desktop network connectivity