Windows 365 Cloud PC Architecture Design Provisioning options

Published Mar 04 2022 02:41 PM 9,341 Views
Microsoft

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.

 

jsifuentes_0-1647269418615.png

 

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 2adding 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.

 

jsifuentes_1-1647269471611.png

 

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 3helping 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.

 

jsifuentes_2-1647269555889.png

 

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

1 Comment
Version history
Last update:
‎May 17 2022 10:56 AM
Updated by: