Application Deployment in Windows 365 – Recommended Practices

Microsoft

 

(This post was jointly written with Aleksandar Bozadzhiev)

 

Overview

As more companies are using Windows 365 to enable their employees, reduce their costs, or reimagine how to provide a managed Windows experience, we’re hearing some consistent feedback. A common challenge we hear is “How can I ensure that all my required applications are installed before my users can access their Cloud PCs?”  Common statements we’ve heard include:

“I need to ensure all security tools are installed before users can logon to reduce risk.”

“I need to ensure my people are immediately productive when they 1st logon.”

 

This article will provide some recommended approaches to help you meet this need; providing both technical and process recommendations.

 

Technical Recommendations 

Use Intune to assign applications to devices rather than users.

By targeting devices you can better ensure your applications get installed as soon as possible. When a Cloud PC is provisioned, it immediately is enrolled with Intune. After enrollment, the Cloud PC will sync with Intune to determine what applications, policies and profiles are required for the device.  Assigning to user groups will result in the Intune sync occurring after the user 1st logs, potentially delaying the installation of required apps for several minutes after logon.

 

Additionally, using Configuration Manager or a third-party solution to install applications will result in additional delays, as Intune will need to install the 3rd party agent/client, which will then do its own scan/sync to determine what needs to install on the Cloud PC.

 

Of course, there may be exceptions where applications are more appropriate to be targeted to users rather than devices; such as software that has specific license requirements, or applications require a user to be logged on to perform the installation.

 

Use “All Devices” group and device filters (rather than dynamic groups)

Our Windows 365 documentation provides details on how to use both dynamic groups and device filters for targeting applications. The challenge with using Azure AD dynamic groups is that a newly provisioned Cloud PC may not be in a dynamic group for some time, potentially for several minutes up to several hours. This is due to the nature of how dynamic groups are processed and synced to Intune. When a Cloud PC is provisioned and enrolled into Intune, the following actions occur:

 

  1. A device object in both Azure AD and Intune are created.
  2. Azure AD Dynamic group membership is periodically calculated for new members.
  3. Dynamic group membership is synced with Intune.
  4. The Cloud PC checks-in with Intune to determine what applications, policies, and profiles are applicable.

The above actions occur sequentially and run on a periodic schedule which results in a potentially significant delay in installing applications.

 

Using the “All devices” Intune virtual group and device filters when assigning applications will result in your applications being installed as fast as possible. Why? Device filters are evaluated by Intune immediately upon enrollment and the All Devices Intune group does not require any synchronization activity.

 

Device filters that can be used with Cloud PCs include:

 

Also, note that if you’d like to use an Enrollment Status Page (ESP), a device filter that represents a specific provisioning policy is the only filter that is supported with an ESP. More details in the section below.

 

The above links describe how to create a device filter. The below images shows an example of creating a device filter, and then using a device filter when assigning applications.

 

CurtisSawin_0-1688058040634.png

 

CurtisSawin_1-1688058040642.png

 

 

 

Check out the Common Questions and Answers in our Intune documentation for more details on the challenge of using dynamic groups to deploy applications at enrollment.  Also, note our performance recommendations in our Intune documentation when using groups for application targeting.

 

Recommendation: To reiterate, using the “All Devices” group AND a device filter that represents some or all Cloud PCs will provide the best possible performance, installing your applications as fast as possible post provisioning. Using a device filter that represents a specific provisioning policy or a specific configuration will provide granular targeting.

 

What about using an Enrollment Status Page (ESP)?

An ESP is commonly used to display the provisioning status when enrolling with Intune. It’s a detailed progress indicator. An ESP is designed to be displayed while the user is waiting for their device to be ready. When using Windows Autopilot to provision new physical Windows devices, the ESP runs in two phases: the device ESP and the user ESP. The device ESP runs only during the default out-of-box experience (OOBE). When provisioning Cloud PCs the device ESP is not used – as there’s no OOBE phase - only the user ESP. Since a Cloud PC is provisioned without a user present, an ESP may add complexity to the overall provisioning process. Further, while there is a setting “Block device use until all apps and profiles are installed” this is only used during the user ESP phase, and this setting is not used during Cloud PC provisioning when targeting apps to devices. Thus, if you’re targeting applications to device groups, we recommend not to use an ESP for Cloud PCs.

 

If you’d like to use an ESP for user targeted applications and policies, make sure to follow the guidance here. Specifically, note that a custom ESP is only supported when you use a device filter that targets a specific provisioning policy. Using dynamic device groups with an ESP is not supported.

 

Process Recommendations - Planning for onboarding users to Cloud PCs

Without using the “Block device use until all apps and profiles are installed” setting, how can we ensure all the apps are installed prior to the 1st logon?  This is when it’s important to consider the onboarding process.

 

Meaning, when testing/evaluating Windows 365, you might assign a license to yourself or your coworker, ensure you’re in a group that is assigned a provisioning policy, and then check the Intune admin console to see when you’re Cloud PC status changes from “provisioning” to “provisioned.”

If you then immediately connect to your Cloud PC, you may find that not all of your applications installed, and then think “Well I can’t give this to my users until I know all my apps will be there!” Surprisingly, this statement holds the key to managing this challenge.

 

Think about how you’re going to provide Cloud PCs to users. How many will you provision at a time? One? One hundred? One thousand? What’s your communication plan? How will users know when (and how) to use their Cloud PCs?

 

What we find is that it is uncommon for users to login to their Cloud PCs shortly after they’re provisioned. Below is a chart that shows some of our internal telemetry from the last 28 days (based on time of this writing).

 

CurtisSawin_2-1688059083676.png

 

Some takeaways from this data:

  • Less than 30% of users sign-in to a Cloud PC less than 1 hour after it’s been provisioned.
  • Over 50% of users sign-in to their Cloud PC 4 hours or more after it’s been provisioned.

Additionally, we found that the average time until 1st login is just over 32.4 hours and the median is 4.2 hours as there is a lot of variation in the results. What we can infer from the above is that most companies have users that do not sign-in immediately after provisioning and wait several hours before doing so. Sometimes this is done unintentionally, while sometimes this is planned during a deployment project.  For example, a deployment plan may look like the following:

 

  • Day 1 - Provision 50/500/5000* Cloud PCs
  • Day 2 – Review the results
  • Day 3 – Send out end user communications

* Earlier this year, we worked with a company who followed this model and successfully provisioned over 10,000 Cloud PCs in less than 24 hours.

 

The above deployment plan can definitely be compressed to build in a 2-3 hour buffer (for example) to ensure all apps are installed.

 

Consider how a user will know to log on to their Cloud PC for the 1st time. As an IT admin, you can control when to notify people that their Cloud PC is ready. During your notifications, you can optionally provide a link to download the Windows 365 app through the Microsoft Store, or a link to the Intune Company Portal to install the app.

Lastly, make sure to test your application installation prior to onboarding your Cloud PC users in a production environment. While this may sound obvious, such testing helps eliminate potential onboarding challenges.

 

What can be done to verify application installation?

The Intune Admin portal can be used to review the results and ensure that all device targeted apps are installed. Administrators can select a Cloud PC and view the “Managed Apps” list that are targeted to the device. Using the Intune admin portal is a great way to review the results of a few Cloud PCs.

 

CurtisSawin_4-1688059316800.png

 

Additionally, the Graph API can be used to help you automate this process. Check out our documentation that explicitly mentions how to get the application installation status on a user’s device.

 

The Microsoft Hosted Network (MHN) can help

If you’re concerned about having a Cloud PC connected to your network without immediately having your required security applications, consider using the Microsoft Hosted Network when planning your network deployment of the Windows 365 service. Using the MHN is the simplest option and aligns with the Zero Trust framework model and is the Microsoft recommended deployment model for Azure AD joined Cloud PCs. Additionally, a Cloud PC is not connected to your network until a VPN connection is explicitly established, further reducing risk.

 

Summary

When it comes to the Windows 365 provisioning process, the process used by IT admins to perform testing and evaluation can be vastly different than the process to deliver Cloud PCs to end users. In most environments, people 1st sign-in to Cloud PCs several hours after they are provisioned.  Acknowledging this human behavior and building a waiting period buffer is a means to ensure all your applications are installed and provide IT admins a way to verify prior to providing the Cloud PC to end users.

 

The technical guidance above will also help you provide the best provisioning and onboarding experience to your users.

0 Replies