Windows 365 Enterprise provides an easy method to automatically provision Cloud PCs, without the complex skillsets that are required for successful deployment in other virtualization environments. Windows 365 also offers flexibility, allowing organizations to manage Cloud PC users, deployment locations, and lifecycles.
This article reviews some common considerations you can make for initial user provisioning, when you might need multiple provisioning policies, and how to manage those provisioning policies going forward.
Scenario 1 – Provisioning by location
Before you create a provisioning policy, you need to create your on-premises network connection (OPNC). These connections do a couple of things:
- Connect Microsoft Endpoint Manager to your network, so that Cloud PCs can join your domain and your users have access to resources.
- Check that deployments will be successful. The network connection performs an initial environmental health check to make sure you’re ready to deploy Cloud PCs, as well as ongoing health checks to monitor the connection health between your on-premises resources and Cloud PCs.
- Define where (geographically) you can deploy your Cloud PCs to ensure proximity to a user’s main working location, so that they get the lowest latency connection and the best experience.
To expand on the last point, consider this environment’s user and network topology:
In this scenario, the OPNC is deployed to a virtual network (vNet) and domain controller in East U.S. Therefore, all Cloud PCs are provisioned in East U.S., even for users in North Europe. This can generate latency for the users in Europe as they connect across the globe to their Cloud PCs.
If the customer wants to deploy Cloud PCs locally to all users, then they need to create a vNet in North Europe, and either configure vNet peering back to the main site with the domain controller or deploy a domain controller in that site. Either way, they need to make sure that the new vNet has line of sight to a domain controller for domain join, and update the DNS settings on the new vNet.
Finally, create an OPNC for each vNet to make them available for multiple provisioning policies. This will allow you to create provision profiles for different user groups, and deploy each Cloud PC in the appropriate geographic location.
The final topology would look like this:
Scenario 2 – Deploying to different user personas
In this scenario, you need to apply different provisioning policies to different users based on their user personas. You may also want to personalize Cloud PCs for a specific user profile, and perhaps departmental apps that are user assigned aren’t suitable for other reasons. In this instance, you can combine multiple provisioning policies with dynamic groups and then assign the appropriate apps and configuration settings to that dynamic group. As an example, complete the following steps to create a policy for users with a “Finance” persona:
- Create a provisioning policy for the Finance users. Note that you can use the same OPNC for multiple provisioning policies.
- Create a dynamic device group containing all Cloud PCs from a specific provisioning policy.
- Assign apps to this policy.
Now, when you add users to the group targeted by the Finance provisioning policy, the device will automatically provision, and the assigned Finance apps will start installing on the Cloud PC as soon as it’s finished initial provisioning.
Note: The user inside the Azure AD group targeted to the provisioning policy must be assigned a Windows 365 license to kick off the provisioning process. To simplify this process, you can target the same Azure AD group to the license and the Cloud PC provisioning process will kick off automatically! |
Scenario 3 – Giving users multiple Cloud PCs
You might want to give users multiple Cloud PCs, and Windows 365 supports this—but there are couple of caveats to be aware of:
- A user can have multiple Cloud PCs, but they must be of different license SKUs. That is, a user can have a 2x vCPU 4GB Cloud PC and a 2x vCPU 8GB Cloud PC, but they cannot have multiples of the same size.
- A user should be targeted by group membership to a single provisioning policy only. There is no technical blocker to stop you from targeting user groups that have overlapping members, but you won’t get the behaviour you might be expecting. The Windows 365 service will provision a Cloud PC to a user based on the first provisioning policy they were assigned. And if you later modify one of the other policies that targets the same user, if the user reprovisions a Cloud PC, it will be configured with the settings of the most recently changed policy.
In other words: you can’t pin a user’s Cloud PC license to a particular provisioning policy.
As an example of these two scenarios, the following diagram shows a user who has two assigned licenses, and both Cloud PCs are provisioned from Provisioning Policy 1 (which was the first assigned policy):
Scenario 4 – Updating a provisioning policy and moving users between policies
In this last scenario, you want to update a provisioning policy or move users between them. This can be useful if you have custom images and want to manage image updates either through a test group of users or by updating the Cloud PC for all users.
Updating a provisioning policy
When you update a provisioning policy, the Windows 365 service will not automatically update all the associated Cloud PCs with the new policy settings. This is by design to stop an automatic destructive action from immediately impacting users. If you want to force an update of a user’s Cloud PC, go to the device’s Overview page in the Endpoint Manager admin center and select Reprovision. This will start reprovisioning of that Cloud PC, but using the latest settings contained in the provisioning policy (OPNC or image change).
If you need to force reprovisioning across multiple Cloud PCs, it’s possible to automate a bulk action using the Graph API for Cloud PC.
Once a Cloud PC has been re-provisioned with the latest provisioning policy settings, it will be reflected in the All cloud PCs page, as shown in the following screenshot:
Moving a user between provisioning policies
If a user moves department or geography permanently, then you might have a reason to reassign them a different provisioning policy. This is possible, but note that when a user is no longer in scope for their existing policy (removed from the assigned group) then the service will initially place the existing Cloud PC into a grace period of seven days. This prevents accidental data loss or loss of service for the user. Once this seven-day period has expired, and the user is already assigned a new provisioning policy, the service will automatically start provisioning a new Cloud PC right away.
On our roadmap we’re building the ability to override the seven-day grace period and remove the Cloud PC immediately, which will speed up your ability to move users between provisioning policies. You will see an option similar to the following image:
Learn More
We’ve covered some common scenarios around Cloud PC provisioning policies to help you understand different options for your environment and the flexibility that Windows 365 provides. We hope this information helps you as you work to design the best implementation for your organization. For comprehensive information about Windows 365 Cloud PC provisioning, see Provisioning overview. If you have additional questions or feedback, please add a comment below.