Let's dive into architecture design options to provision Cloud PCs in your Windows 365 ecosystem!
Remember to loop back to the main deck for Windows 365 Cloud PC Healthcare Series
When Windows 365 was initially released last year August 2, 2021. We had only one available architecture design option, with the addition of Azure AD Joined Public Preview, customers now have 3 available options to roll out Cloud PCs!
This topic has become quite common to speak about, as we get lots of questions from our HLS customers around architecture provisioning options for WHEN/HOW to provision Cloud PCs in your environment. Each of these options are designed to fit a state of the customer environment, making it available to dark to cloud, hybrid modern or cloud adopted. We believe this is an important topic to discuss that can be beneficial for our Microsoft peers, as well as to our customers and partners externally, to give you full visibility of the available options when planning the foundation of your Windows 365 ecosystem and requirements aligned for each of them to make you successful.
Let’s dive in!
Windows 365 Cloud PC Architecture Design options
OPTION 1: (Windows 365 Azure AD Joined + hosted in Microsoft Network)
Let's begin looking at OPTION 1 “recommended Microsoft architecture option to get started!”
- Fully hosted in Microsoft network and managed by Intune (Co-Management optional)
- Cloud PCs are enrolled as Azure AD Joined devices
- This option delivers a low-latency experience for end-users connecting to Cloud PCs based on regions
- Removes customer constraints (Azure subscriptions, vNETs, S2S or ER tunnels, etc...)
- This is the recommended option to get started with Cloud PCs
-
Available for hybrid and cloud Azure AD users
- Optional: you can deploy a VPN client to give your users access to on-prem apps and resources
- Important: WS-Trust is required to be enabled, keep this in mind for federation services IDP (e.g., ADFS, Okta, Secure AUTH, etc...)
Note: most third-party IDP federation services will block WS-Trust for extranet but allowed for intranet. Since the request will be coming from Microsoft network, it could be blocked as is coming from extranet.
This is the most suitable design to get your organization started. Most of the time we're against timelines, POC and Pilots that need to validate user experience and solution platform. Many big enterprise organizations have multiple business units of IT administrators to control different sub-domains (e.g., identity, mobility, network, security, compliance, etc..) which can add up to delays in the project to align all these teams and change request management process to fulfill the requirements for Windows 365. Most of our customers love this option because it’s very much resource-less needed.
Let's define an important outcome for this option:
- OPTION 1 helps customers deliver a low-latency Cloud PC user experience for end-users based on location (e.g., US, Europe, Asia, etc...)
For more information on regions availability:
Windows 365 supported regions| Microsoft Docs
Primarily you want to initiate with OPTION 1, and then analyze if OPTION 2 might be a better fit. You may need your users to have a dedicated connection for multi-layer networks in different Production VNETs, that's where OPTION 2 does a much better job.
OPTION 2: (Windows 365 Azure AD Joined + hosted in Customer Network)
Now let's look at OPTION 2 “adding the Customer network layer architecture for their Cloud PCs”
- Hosted in the Customer network and managed by Intune (Co-Management optional)
- Cloud PCs are enrolled as Azure AD Joined devices
- Latency Cloud PC user experience delivered is based upon customer network alignment and optimization
- Users benefit from a S2S or ExpressRoute tunnel to access on-prem apps and resources
- This option can address multi-layer access (e.g., multi-network domain access, global peering, cross-regions, etc...)
- Requires: Azure subscription, vNET connectivity
-
Available for hybrid and cloud Azure AD users
- Important: WS-Trust is required to be enabled, keep this in mind for federation services IDP (e.g., ADFS, Okta, Secure AUTH, etc...)
Note: most third-party IDP federation services will block WS-Trust for extranet but allowed for intranet. Since the request will be coming from Customer network, it will be allowed as is coming from intranet.
This option is more strategically aligned with the customer network. Many of our HLS customers range several applications and resources they provide to their users located in different cross-geo, on-premises, cloud locations and multi-layer domain networks (e.g., Multiple PROD vNETS, Hub-Spoke topology, etc..). Another huge advantage from this option is that it removes the on-premises hurdles that are required for OPTION 3 (e.g., line-of-sight of Domain Controllers, AD Connect, Sync Schedules, GPOs, Hybrid Domain Joined, etc...)
There are a few considerations to leverage this design option:
- We recommend a dedicated vNET-CPC for your Cloud PCs, and global peering to your PROD vNET networks
- Customers can leverage different monitoring solutions in Azure from existing Microsoft and third-party NVA's
- Customer networks must be configured for Windows 365, whitelist the URLs/Endpoints/Ports and exempt inspection & filtering from outbound traffic to prevent impact on the Cloud PC user experience
Network requirements for Windows 365 | Microsoft Docs
So, what’s the unique benefit from this option?
- OPTION 2 gives customers Cloud PC access to a dedicated corporate tunnel connection to the organization applications, and resources and multi-layer domain networks across regions and locations
This option gives our customers an opportunity to expand workloads (some organizations have their Azure network positioned for servers, not for workstations)
OPTION 3: (Windows 365 Hybrid Azure AD Joined + hosted in Customer Network)
And finally let's review OPTION 3 “helping our HLS dark to cloud customers to leverage a Hybrid Cloud PC ecosystem”
- Hybrid option for customers with existing SCCM environments, dark to cloud, managed by Co-Management
- Cloud PCs are enrolled as Hybrid Azure AD Joined devices
- This option fully relies on customer network and on-premises environment
- Users benefit from a S2S or ExpressRoute tunnel to access on-prem apps and resources
- Requires: Azure subscription, VNET connectivity, line of sight to DCs, AD Connect, GPOs, Hybrid Domain Joined, etc...
-
Available for hybrid Azure AD users only
- Important: WS-Trust is required to be enabled, keep this in mind for federation services IDP (e.g., ADFS, Okta, Secure AUTH, etc...)
Note: most third-party IDP federation services will block WS-Trust for extranet but allowed for intranet. Since the request will be coming from Customer network, it will be allowed as is coming from intranet.
It is not uncommon to find dark to cloud customers in the HLS region, we see these as opportunities for an area of improvement and innovation to help our customers deliver a modern management experience and strategic alignment for their end-users with Windows 365 Cloud PCs. Many of our HLS customers find themselves not ready to move to the cloud or shift some of the on-premises workloads to Microsoft. This option allows them to leverage existing PC management solution Microsoft Endpoint Configuration Manager (MECM… aka SCCM) and enable Co-Management to control and manage the Cloud PCs in the Windows 365 ecosystem.
Like OPTION 2… OPTION 3 has the same Azure network considerations for customer network alignment to comply with Windows 365 Cloud PCs, to optimize their network and provide a low-latency experience.
With Co-Management customers have the option leverage existing PC management workloads, (e.g., application delivery, device restriction, scripts roll out, collection reports, etc..) and bring into a hybrid state, where either their SCCM server or Intune can trigger the tasks for the same motions from Microsoft Endpoint Manager console a “single-pane-of-glass” for all your device management needs.
So, what benefits does this design option offer to dark customers?
- OPTION 3 helps customers to leverage existing SCCM environments to control their Cloud PCs environment with Co-Management, without moving to the cloud and scale up to a hybrid state with Microsoft Endpoint Manager in their journey to a Windows 365 ecosystem
Conclusion
Consider reviewing these architecture design options when building your Window 365 foundation before identifying a road blocker. As you can see, we have multiple options that can be strategically injected for a different business use case, all aligned to deliver the same goal “a Cloud PC user experience in a Windows 365 ecosystem”. So why stop here? There’s so much more to learn!
If you want to learn more about Windows 365 Architecture and provisioning options, please visit our enterprise documentation
Windows 365 architecture | Microsoft Docs
If you have any recommendations, for a specific business use case or scenario that is directly related to your organization where Windows 365 Cloud PC can innovate your user's productivity and remote hybrid experience, please feel to share on the comments below and we'll help you to prioritize them as they come.
Bookmark this link for Windows 365 Cloud PC Series: https://aka.ms/HLSWindows365
Thanks for visiting – Juan Sifuentes LinkedIn
