Application deployment in Windows 365: recommended practices

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

As more companies use Windows 365 to empower employees, reduce costs, or reimagine how to provide a managed Windows experience, a common challenge we hear is, "How can I ensure that all my required applications are installed before my users access their Cloud PCs?" Other common statements include:

  • "I need to ensure all security tools are installed before users can log on to reduce risk."
  • "I need to ensure my people are immediately productive when they first log on."

This article provides some recommended approaches to help you meet your needs around app deployment, offering both technical and process recommendations.

Technical recommendations

Use Intune to assign applications to devices

Rather than targeting users, assigning applications to devices can better ensure they get installed faster. When a Cloud PC is provisioned, it's immediately enrolled with Intune. After enrollment, the Cloud PC will sync with Intune to determine what applications, policies, and profiles are required for the device. If you assigning apps to user groups, however, the Intune sync will occur after the user's first login, potentially delaying the installation of required apps for several minutes.

If you use Configuration Manager or a third-party solution to install applications, additional delays are likely. Intune would need to install the third-party agent or client, and then perform its own scan and sync to determine what needs to be installed on the Cloud PC.

The exception to this recommendation would be those applications that are more appropriate to be targeted to users rather than devices, such as software that has specific license requirements.

Use the "All devices" group and device filters

Our Windows 365 documentation provides details on how to use both dynamic groups and device filters for targeting applications. The challenge with using Microsoft Entra ID (formerly Azure AD) dynamic groups is that a newly provisioned Cloud PC may not be in a dynamic group for some time. It could take anywhere from 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 Microsoft Entra ID and Intune are created.
  2. Microsoft Entra ID 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.

To install applications as fast as possible, use the All devices Intune virtual group and device filters when assigning applications. Why? Intune evaluates device filters immediately upon enrollment, and the All devices Intune group does not require any synchronization activity.

Device filters that you can use with Cloud PCs include:

 

Note: 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. Find more details in the section below.

The above links describe how to create a device filter. The image below shows an example of creating a device filter.

Screenshot of the Create filter menu in the Intune admin center and the options to choose the filter’s property, operator, value, and rule syntaxScreenshot of the Create filter menu in the Intune admin center and the options to choose the filter’s property, operator, value, and rule syntax

Screenshot of the Edit application menu with a red box highlighting the group, filter mode, and filter exampleScreenshot of the Edit application menu with a red box highlighting the group, filter mode, and filter example

Some applications require a user to be logged on to perform the installation. These applications should be targeted to users and will only install after a user logs in to their Cloud PC for the first time.

Check out common questions and answers in our Intune documentation for more details on the challenge of using dynamic groups to deploy applications at enrollment. Also, check out our performance recommendations in our Intune documentation when using groups for application targeting.

Note: To reiterate, use the All devices group and a device filter that represents some or all Cloud PCs for the best possible performance, installing your applications as fast as possible after provisioning. Use a device filter that represents a specific provisioning policy or a specific configuration for granular targeting.

What about using an Enrollment Status Page?

An ESP is commonly used to display the provisioning status when enrolling with Intune. It's a detailed progress indicator 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. While there is a setting to Block device use until all apps and profiles are installed, this is only used during the user ESP phase, and not used during Cloud PC provisioning when targeting apps to devices. So, if you're targeting applications to device groups, we recommend not using an ESP for Cloud PCs.

If you'd like to use an ESP for user targeted applications and policies, make sure to follow the Enrollment Status Page guide. Remember, an 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 first logon? This is when it's important to consider the onboarding process.

When testing and evaluating Windows 365, you might assign a license to yourself or your co-worker, ensure you're in a group that is assigned a provisioning policy, and then check the Intune admin console to see when your Cloud PC status changes to provisioned.

If you then immediately connect to your Cloud PC, you might find that not all of your applications got installed. You'd 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's uncommon for users to log in to their Cloud PCs shortly after they're provisioned. Below is a chart that shows some of our internal diagnostic data from the last 28 days (based on time of this writing).

CurtisSawin_2-1693512618535.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 the first login is just over 32.4 hours, and the median is 4.2 hours as there's a lot of variation in the results. What we can infer from the above is that most companies have users that don't 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/5,000[1] Cloud PCs.
  • Day 2: Review the results.
  • Day 3: Send out end user communications.

You can definitely compress the above deployment plan to build in a 2-3-hour buffer to ensure all apps are installed. Consider how a user will know to log on to their Cloud PC for the first 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?

You can use the Intune admin center to review the results and ensure that all device targeted apps are installed. As an administrator, you 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.

Screenshot of the Managed Apps menu showing the multiple applications installed and the one that’s now applicableScreenshot of the Managed Apps menu showing the multiple applications installed and the one that’s now applicable

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

Microsoft Hosted Network (MHN) support

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 (MHN) when planning your network deployment of the Windows 365 service. Using the MHN is the simplest option. It aligns with the Zero Trust framework model and is the Microsoft recommended deployment model for Microsoft Entra (previously, 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 you use to perform testing and evaluation can be vastly different from the process to deliver Cloud PCs to your users. In most environments, people first sign in to Cloud PCs several hours after they are provisioned. This human behavior motivates building a waiting period buffer as a means to ensure all your applications are installed. That's a way for you to verify device readiness prior to providing the Cloud PC to users.

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


Continue the conversation. Find best practices. Bookmark the Windows Tech Community and follow us @MSWindowsITPro on TwitterX and on LinkedIn. Looking for support? Visit Windows on Microsoft Q&A.

[1] Earlier this year, we worked with a company who followed this model and successfully provisioned over 10,000 Cloud PCs within 24 hours.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.