Blog Post

Core Infrastructure and Security Blog
14 MIN READ

Windows 365 Enterprise – Points of Clarification and PoC Proven Practices

MichaelHildebrand's avatar
Sep 14, 2023

Hi folks – Mike Hildebrand here, coming to you live from sunny St. Louis, MO.  Summer is winding down here; it’s mid-September and the dog and I once again have the house to ourselves.  I guess something about the peace and quiet activates the ‘time for a blog’ part of my brain.  Today, I’ll chat with you all a bit about the popular Windows 365 Enterprise (W365) service and the Cloud PC (CPC).

 

There continues to be a great deal of interest in this service and we continue to add helpful and unique capabilities such as W365 Boot - W365 SwitchW365 Frontline and this one is SUPER neat – it lets you use certain Android devices (Motorola ThinkPhone) like a thin-client to connect to your W365 CPC via an ‘enhanced’ W365 mobile app.

 

Over the last year or so, me and my teammates, along with our W365 partner in crime - Bradley Dupay, have explored W365 with a lot of customers.  We’ve presented it, white-boarded it, demo’d it and helped many customers ‘kick the tires’ with their own W365 Proof of Concept (PoC) project.  Many times, those PoCs were operational within an hour or so - and most of them quickly drove to production deployments to address time-critical business needs. 

 

We have great planning/tech docs about W365 and a great architecture doc here.  There are many technical blog posts on our Windows IT Pro blog site.  Also, my peer and buddy James wrote up a brief PoC blog a while back. 

 

Therefore, this won’t be a ‘how-to’ post but instead, I’ll offer up some points of confusion that I had and a ‘grab-bag’ of deployment thoughts and considerations - and some bumps to avoid.  I’ll throw in some patterns for success that I’ve seen work over a year’s worth of PoCs - and finally, a planning document and visual aid to help you with your own PoC or deployment. 

 

I’m a self-admitted slow learner.  I’m usually the last one in the room to exclaim ‘OH!  I get it now!’ – and that’s often a day or two later, when I’m out mowing or something.  Even with that being the case, as a long-time IT Pro/Intune/Azure techie guy, I’m still somewhat embarrassed at how confused I was by W365 at first.  I kept thinking I was missing “the obvious” on so many facets of the service:

 

Point of confusion

Clarifying information

Where do I define the specs for the VM (CPU, RAM, etc.)?  I don’t see those options in the portals anywhere?

 

The license SKU determines the specs for the VM (CPU/RAM/storage) that the user is entitled to. 

 

How are CPCs named?  Depending on where I look, I see two different names for any given CPC – and I didn’t set either one of them?

 

Cloud PC name

The provisioning service auto-generates the Cloud PC name based in part on the Provisioning Policy name and the assigned user’s name:

  • This is the name the end-user sees in the W365 app/portal.
  • The naming ‘schema’ for this display name is not configurable.
  • The end-user can change the display name from their portal page, but this has no impact on the NetBIOS/device name.

 

 

Device name

The provisioning service also auto-generates the NetBIOS ‘Device name’ for the CPC – but it is unrelated to the provisioning policy name or the ‘Cloud PC name.’

  • Just like other Windows PCs in Intune, it is the NetBIOS name that the IT admin sees in the Intune portal.
  • The naming schema for the NetBIOS name can be configured to some level, via a ‘device name template’ within the provisioning policy
  • Here’s how the above CPC appears in the Intune portal but oddly, the Cloud PC name (above) isn’t listed in the Intune portal’s device page for the CPC.

 

Intune is required – but how and when do CPCs enroll?  Does Co-management work? 

 

W365 is deeply integrated with Intune – it took me a bit to realize just how deep that integration goes.  You use the Intune portal to manage, configure and report on the service and the CPCs.  On the back-end, too, the Intune infrastructure is busy with the W365 automations, including auto-enrollment into Intune during the provisioning of the CPCs.  Co-management is supported and works just fine. 

 

Of course, many customers I’ve worked with also deploy their other corporate standard apps, VPN clients, security stack, etc. to their CPCs, just like the rest of their Windows endpoints.

 

NOTE: It often helps me to (re-)remind myself that CPCs are ‘just’ Windows 10/11 VMs and most management options, settings and paradigms apply/work just fine.

 

How do I ‘kick off’ the VM provisioning?  I don’t see where I click ‘Deploy’ anywhere?

The back-end service is always monitoring the policies and license assignments.  Once you add a user to a Provisioning Policy AND assign the user a license (you gotta do BOTH), then the service automation kicks in and you’ll see the CPC provisioning within the portal. 

 

What about local admins?  Can I make CPC users local admins – but only on their CPCs – not any of their other PCs?  What about LAPS and EPM?

Yes, you can define User Settings Policies and assign them to the users (NOT the CPC devices).  In my screenshot, the ‘CPC-LocalAdmin’ Policy is assigned to the ‘Americas - LocalAdmins’ Group.  LAPS is supported but EPM isn’t yet (that’s already in the works, though).

 

On that note, how do I deprovision a CPC? For instance, say I want to remove a CPC from a user?

You remove the license assignment and/or the Provisioning Policy from the user (i.e., remove the user from the group that is assigned to the license or Provisioning Policy).  The service will ‘see’ that change - and initiate a ‘grace period’ of seven days then delete the CPC from the service, Intune and Entra ID (including in the user’s ‘Devices’ section). 

 

 

 

If this is a ‘cloud-only’ solution, can the CPCs get access to a LAN?  What about Hybrid Join?

 

As mentioned above, for the most part, CPCs are just Windows 10/11 VMs, hosted in Azure.  They can be Entra ID Joined or Hybrid Joined, and they can also be configured with connectivity to your org’s LAN resources (via Azure VNet config or a typical VPN client)

 

What happens if I reprovision a CPC?

 

CAUTION: Reprovisioning a CPC drastic – the OS and all local data/settings/apps are lost.  Realistically, the service provisions a totally new VM, including a new NetBIOS ‘device name’ and deletes the old one (from Intune and Entra ID-).  Though the Cloud PC name/display name will be the same as it was before.

 

Can the VMs be ‘resized’ into higher/lower performance VMs?

 

Yes.  Both ‘bigger’ and ‘smaller’ CPC resizing is possible with a few caveats about licensing - and storage won’t size-down.  This operation retains the OS ‘as is’ – it’s not a wipe/reset or reprovision.

 

Can the CPCs be moved to another Azure Region?

 

Yes – but only at the ‘Provisioning Policy’ level (i.e., ‘all CPCs from a given Provisioning Policy can be moved’ – not at a per-CPC level)

 

Can I mix and match?  License types (Enterprise vs Frontline); join types (AAD vs HAADJ); various Azure regions, Microsoft-hosted network vs Azure VNET connection to my org’s LAN?

Yes – and this flexibility is yet another SUPER powerful aspect of W365.  In point of fact, I’m rocking ‘all of the above’ in my lab environment, all over the world.  Here’s an Azure map of my W365 CPCs:

 

Can I use a custom OS image?

Yes – with a few caveats.  Obviously, this may introduce additional levels of complexity and management overhead (i.e., image creation, maintenance, etc.).

 

What if I edit an existing Provisioning Policy?  What happens?

Generally, existing CPCs aren’t affected; any new CPCs will be deployed with the changes.  Edits to a Provisioning Policy won’t trigger a reprovision of all the existing CPCs for that Policy. 

 

Oh, yeah one more … “How do I turn the thing off?

 

The short answer is ‘you don’t’ – the design of W365 Enterprise is that the CPCs are ‘always on’ – the end user won’t see the shutdown option in the Start menu or elsewhere in the UI (nor will the IT Pro see power off/on in the Intune portal). 

 

NOTE: The cost incurred by the CPCs running 24x7 is covered within the license cost.

 

Technically, they can be shutdown via PowerShell or CMD but there are health checks in the service and if a CPC is found to be off, the service will boot it up.

 

NOTE: On the contrary, W365 Frontline CPCs are designed to be offline unless in-use.  They CAN be powered off/on via the Intune portal and shortly after a user ends his/her W365 FL ‘session,’ the VM will be shutdown.  When the user attempts to re-access the FL CPC, it will power back on and boot up.

 

 

Policy-driven

As I cleared up my confusions, I came to the realization that Windows 365 is a quite different PC provisioning model than I was used to.  It’s a ‘policy-driven’ process vs nuts, bolts, and a box of parts. 

The fact is for Windows 365, there are just a few configurations to make in Azure and Intune – and then, the back-end service automation takes over and does the other 98% of “the work.”   That was “work” I was used to doing - and expecting to do.     

W365 is sorta like going into Taco Bell and ordering from the kiosk.  You tap/select a few options and hit ‘Submit’ – in a few minutes, you’re handed your completed order.  No combining ingredients, no cooking, no baking, no dishes to wash.  I guess that’s the whole SaaS/PaaS model, eh?  I told you I was a slow learner.    

 

Easy

To me, one of the greatest attributes of Windows 365 is its configuration simplicity.  The W365 ‘platform’ rides on top of other well-established technologies (mainly Azure and Intune); after you’ve done a bit of pre-work and spent just a few minutes in the Intune portal, you’ll be on your way to 1 or 1000+ fully configured, Intune-enrolled CPCs.   

 

NOTE: There are some initial “one time” steps that might need to be done for your Azure and/or Intune environment and these may require ‘change control processes.’  They also may be handled by other people/teams in your org. 

 

Consistent

Another great aspect of Windows 365 is its consistency.  And we IT folk LOVE us some consistency, don’t we?  By design, CPCs are all created and deployed ‘the same’ – based on the settings you define.  Your W365 CPC “factory” will just keep pumping them out, based on your licenses and Provisioning Policies. 

 

Onward …

Design thoughts, considerations, questions:

  • Use the Job Aid below to help document and execute your plan.
  • Like most of our modern solutions, Windows 365 is a user-based solution – licenses are assigned to users; users are assigned to Provisioning Policies, Provisioning Policies create CPCs for those users.  You should use Groups to manage and facilitate efficiency and organization in your deployment (examples below).
  • As with any IT solution, your use-cases/work-streams/scenarios will drive your decisions:
    • What workloads will users perform from the CPCs? 
      • That drives the performance needs, which drives the license choice.
    • Where are the users located? 
      • That drives the selection of Azure region.
    • Will the users (or the apps they’ll use) need to connect to LAN resources? 
      • That drives network and connectivity options.
    • How will the CPCs be managed?
      • Short-answer – hopefully, just like the rest of your Windows 10/11+ endpoints.
      • Remember, though, that W365 is dependent on the CPCs being enrolled in Intune.
    • Consider creating Dynamic Device Groups for gathering CPCs
      • This will result in a dynamic collection of CPCs that can be used to target apps or other needs.
      • However, recall that Dynamic Groups are re-processed at intervals – not constantly.
      • That may result in delays/gaps of new CPCs getting dynamically added/removed from that group.
    • Consider Intune Device Filters for your CPCs – this is helpful to filter in/out certain Intune elements (i.e. an Enrollment Status Page policy, ESP) from applying to CPCs:
      • The main benefit of a Filter over a Dynamic Device Group is that the filter is evaluated more predictably and more frequently - when the device enrolls, checks in with the Intune service, or at any other time Intune policies are evaluated.

 

Bumps in the road - my own and common in customer PoCs

  • Read through these - Troubleshooting Windows 365 | Microsoft Learn
  • License + Provisioning Policy = CPC joy
    • Is the user assigned a license AND a Provisioning Policy?  If not, “NO SOUP FOR YOU!”
  • Intune-related
    • Is automatic enrollment enabled - and working?
    • Are there any Intune “enrollment restrictions
    • Consider what impact/results the Intune enrollment will have on the device.
      • App installs, policies/settings, ESP, etc. - any/each/all of these might delay, hang or fail the provisioning:
        • Apps assigned but the source files aren’t reachable by the CPC.
        • Policy settings such as the PowerShell Execution Policy set to require ‘signed scripts.’
        • Enrollment Status Page and W365 CPC
          • ESP works nicely for CPCs but the setting below can minimally or drastically extend a CPC’s deployment time - or even cause it to fail in some cases
            • I strongly encourage using a filter to exclude the CPCs from a blocking ESP Policy – at least initially.

 

  • Do you have many apps and/or Intune policies targeted to the ’All users’ and/or ‘All devices’ group/s?
    • Using these ‘virtual’ Groups simplifies targeting - but these can each (or together) impact how quickly (or not) the CPC provisions.
  • As mentioned earlier, you’ll likely need some elevated permissions in Azure and/or Intune to get your tenant prepared for W365 and CPCs.
    • In addition, the W365 service itself has a few RBAC roles for management of the service, CPCs, etc.
    • Check the docs for what precise permissions are needed depending on the task at hand, including importing the license/s into your tenant (I’ve only seen this work with a Global Admin).
    • If you’ll be using a LAN-connected Azure VNET, there are some Azure dependencies/info to gather/create:
      • You may need a user ID with permissions to do some initial “Azure stuff” – and a person (maybe you – maybe not you) who understands your org’s “Azure stuff” (subscriptions, VNets, Resource Groups)
        • Which Azure Subscription will be used?  Many orgs have more than one Azure subscription these days
        • Which Azure Resource Group/s will be used?
          • I usually recommend creating a new one for W365 – most orgs have naming conventions for creating Resource Groups in Azure
        • Which Azure VNET will be used?
          • If doing Hybrid Join and/or need the CPC to access on-prem resources, verify the selected VNET has DNS server IPs for internal DNS name resolution to function.
        • Which Subnet in that VNET will be used?
          • Make sure there are sufficient IP addresses available in the subnet.

Patterns for Success

1. Review/expand your naming standards for W365.  It can be helpful to align the Group names to the targeted Policy/ies

 

2. Create your Groups first – to be used for targeting your Provisioning Policies, etc.  (but leave them empty – you’ll add users later)  

  • Provisioning Policy Groups example
    • The Europe Call Center Group targets the Europe Call Center Provisioning Policy
      • Which creates CPCs in the UK Azure region
    • The Fargo Call Center Group targets the Fargo Call Center Provisioning Policy
      • Which creates CPCs in the Central US Azure region

 

  • License Groups example
    • Assign the appropriate licenses to the matching License Groups.

 

  • Members of the “Size 2-8-128” Group will be entitled a 2vCPU/8GB RAM CPC w/ 128 GB of storage.
  • POP QUIZ! - What would a user in the “Size 4-16-128” Group get?  EYES ON YOUR OWN PAPER!

 

 

IMPORTANT

  • In my examples above, I used a ‘dual Group’ model – I created separate Groups – one for Provisioning Policy and another for CPC size/licensing. 
  • You could just as easily choose a ‘single Group’ model and create one group for both assignment of the license and targeting of the Provisioning Policy. 
    • Here’s an example where I created a single Group to assign both the CPC license and to target the Provisioning Policy for the Sales and Marketing division:

 

  • Either (or both) works – it totally depends on how you’ve designed your Group strategy. 

RELATED NOTE: W365 Frontline ties the CPC size/license into the Provisioning Policy settings; therefore, W365 FL deployments will have to use the ‘single Group’ model.  If you want to be consistent across W365 Enterprise and W365 Frontline, you might want to go with the ‘single Group’ model for both.

 

3. Next, create the Provisioning Polices, ESP Profile (if needed, to avoid the blocking issue), User Settings Policy (if needed, for local admin) - assign them to the still-empty Groups you created above.

  • Provisioning Policy example
    • For my European Call Center scenario:

 

  • ESP Policy example
    • Only the CPCs are included in this filtered ESP Policy (which doesn’t block access to the CPC until after all apps/profiles apply).

 

 

4. Now, you’re set - when ready, you simply add users to the desired Group/s.   

 

BONUS – A ‘Better Together’ idea – make those Groups part of an Access Package in Entra ID.

  • This example provisions a new CPC for users who are assigned the corresponding “Sales and Marketing” Access Package:

Bradley’s E-Z-PoC

Here are the basic elements of our ‘rapid start’ PoC model that we often use with customers:

  • Request a W365 Enterprise trial from your Microsoft sales rep
    • The trial will be one or more license codes sent via email
  • Use the form below to discuss, collect and document your PoC plans
  • Get a Global Admin in your org to add the license codes to your tenant
  • Create a Test User in your tenant
  • Create the Groups/license assignments as discussed above
  • Create a Provisioning Policy in Intune, select “Entra Joined” + “Microsoft hosted network” and assign it to the Group created for the Provisioning Policy
    • You won’t need any additional Azure “stuff” (i.e. subscription, VNET, subnet)
    • There is no connectivity requirement between the LAN and the cloud
  • Put the Test user into the Group/s
  • Sit back and watch the magic happen

 

Ok folks – there you have it - a substantial pile of ruminations, illuminations, musing and tips for a well-understood and successful W365 PoC, pilot or deployment. 

 

Special thanks to “The W365 Whisperer” – Bradley Dupay

 

Hilde 

 

P.S. This just in!  Microsoft has been named a Leader in the inaugural 2023 Gartner:registered: Magic Quadrant™ for Desktop as a Service (DaaS). Read the blog and full report here.

 

P.S.S. Next Tuesday (9/19), we’re presenting a webinar about W365 (yours truly and a few other folks will be trolling the chat) - Microsoft Events - Art of the Possible - Evolve the Way You Work with Windows in the Cloud

 

JOB AID - Windows 365 PoC

Scenario details for PoC/pilot: ___________________________________________________________________________________________________________

___________________________________________________________________________________________________________________________________________

Entra ID Group/s for CPC License Assignment (add users as members) - CPC ‘size’

  • ____________________________________________________________________________________
  • ____________________________________________________________________________________

Entra ID Group/s for CPC Provisioning Policy Assignments (add users as members) – CPC ‘config’

  • ____________________________________________________________________________________
  • ____________________________________________________________________________________

Entra ID Group/s for User Settings assignment (add users as members – i.e. local admins on their CPC)

  • ____________________________________________________________________________________
  • ____________________________________________________________________________________

CPC Provisioning Policy names/descriptions text:

  • ____________________________________________________________________________________
  • ____________________________________________________________________________________

Azure Network Connection (ANC) details:

  • Entra or Hybrid Join:
    • Azure Subscription: ___________________________________________________________
    • Azure Resource Group: ________________________________________________________
    • Virtual NET: __________________________________________________________________
    • Subnet: ______________________________________________________________________
  • If you’re doing Hybrid Join, you’ll also need this info, in this format, for the ANC
    • The ‘AD username’ is the service acct used to ‘join’ to AD.  Make sure it has proper AD permissions to create/join computer accounts, including (possibly) at the OU level.

 

CPC Provisioning Policy Settings:

  • License type: For this specific provisioning policy. 
    • Enterprise __________________________________________________________________
    • Frontline: ___________________________________________________________________
  • Join Type:
    • Microsoft Entra Join (aka AADJ)  – MSFT hosted network (stand-alone VNET in Azure – don’t need Azure subscription)
    • Microsoft Entra Join (aka AADJ) – Customer-connected VNET in Azure (need an Azure subscription and permissions to it)
    • Hybrid Microsoft Entra Join (aka HAADJ) – Customer-connected VNET in Azure w/ access to AD/DCs (need an Azure subscription and permissions to it)
  • Network
    • Microsoft Hosted Network - Stand-alone VNET in Azure – don’t need any Azure information/subscription
    • Azure network connection - Customer-connected LAN/VNET in Azure
      • Need a target Resource Group, VNET and subnet
      • Resource Group:  _______________________________________________________________________________________
      • VNET/Subnet: __________________________________________________________________________________________
    • Azure Geography/ies and Region/s (Azure Regions w/ W365)
      • __________________________________________________________________________________________________________
      • __________________________________________________________________________________________________________
    • Use SSO option?
      • ____________________________________
    • OS Image info (Win 11/10/ build, etc.): _______________________________________________________________________
    • Office apps/info? _____________________________________________________________________________________________
    • Windows settings (Language and region): ___________________________________________________________________
    • Autopatch enabled?
      • Yes
      • No
    • Naming Template Details (only applies to the NetBIOS name):
      • ____________________________________________________________________________________________________________
    • Provisioning Policy Assignment Group: _________________________________________________________________________

User Settings Policy options:

  • Local Administrator checked? ______________________________________________________
  • Allow user to reset (reprovision)? __________________________________________________
  • Restore point checked/info? _______________________________________________________
  • Assignment group (should be a group of users, not a group of CPCs):_______________________________________________________

 

 

 



Updated Sep 16, 2023
Version 5.0
  • Once again, an amazing blog entry and I love the reference to Taco Bell for fun and the "Job Aid" check list! Well done.

  • Great stuff!

     

    Given that you can select multiple groups in a single Provisioning policy I never felt a need for additional groups just for the policy sake. Even when you have users with different sized VMs served by the same policy, you will just add them all there. This minimizes the number of entities one has to manage (= less potential for mess and error) and is consistent with Frontline approach.

    So, I'd create user groups for licensing like "CPC 2-8-128" and "CPC 4-8-256" and then select both in my provisioning policy.

     

    Interested to hear the use cases, where the dual-group scenario is really a must!

     

  • Simply awesome. The document is almost one year old, but still so relevant and valid. Thank you, Sirs.