Desktop Analytics is still a recent product and a small beast that require a bit of time and trial and error to get going. The goal of Desktop analytics is to give data to understand your environment prior to mass roll out a new Windows 10 Feature Update. Desktop Analytics isn’t a product to deploy a Windows 10 Feature Update. ConfigMgr remains the master of the actual deployment.
In this blog post, we’ll detail real-world scenarios on how to use Desktop Analytics information to help during a Windows 10 Feature update deployment.
Desktop Analytics Windows 10 Update Requirements
See our previous post on how to setup Desktop Analytics and connect it to your SCCM/ConfigMgr/MEMCM environment prior to reading this post.
Select devices to be evaluated by Desktop Analytics
Here are a few questions to help determine which devices should be included.
- Should Windows 7 devices be included?
- Assuming you are well into the Windows 7 to Windows 10 migration, it may only add unnecessary noise to your reports in Desktop Analytics.
- Is there any Windows 10 LTSB/LTSC in the environment?
- Are there any devices with a specific application that are mission-critical and need to be excluded from Windows 10 Feature update?
This is important to simply the amount of information in Desktop Analytics. Importing Windows 7 devices will likely bring a ton of no longer used applications that will simply create additional work to sort.
Servers should also be excluded from the collection to define devices to include in Desktop Analytics.
Once the collection is built on your criteria, it can be specified under :
- Administration / Cloud Services / Azure Services / Desktop Analytics
- Select your Target Collection doe Desktop Analytics
Important InfoIf you already added a collection here, but would like to review it, it can be modified. Note that it will take about 2 days to process those changes and reflect the new list of devices.
Create the Windows 10 Deployment Plan
For our test, we will use the Windows 10 20H2 version. A deployment plan will :
- Automatically recommend which devices to include in pilots
- Identify compatibility issues and suggest mitigations
- Assess the health of the deployment before, during, and after updates
- Track the progress of your deployment
The deployment plan can only be targeted per Windows 10 build.
- In the Microsoft Endpoint Manger portal
- In All services, select Desktop Analytics
- Under Manage, select Deployment Plans
- Create a new Deployment plan called Windows 10 20h2 and select the destination version of Windows 10
- Select the device groups that are to be included by that plan. For example, if the main purpuse is to do Feature Update from an earlier version of Windows 10, then the device group(collection from ConfigMgr in the background) should be select.
- On the Readiness Rule, specify whether devices are getting drivers from Windows Update and the default threshold for low install count. Carefully read the note as those applications will be assigned a low Install count which gives this application a Ready state.
- Once created, this will create collections back in ConfigMgr under Device Collections / Deployment Plans.
- Note that those are not to be modified in ConfigMgr at all.
- These collections membership will evolve based on the readiness level of devices. We’ll go more into detail later on.
The goal of Desktop Analytics is to gather data from your application to know if they are compatible with the next Windows 10 version. We will now classify our application to fit our needs.
This is a 2 steps classifications:
- It is possible to classify applications in general for all Desktop Analytics under Assets/Apps. This will be useful for any deployment plans going forward. If you begin with Desktop Analytics, it’s a good idea to begin here.
- With this option, the importance level and owner of the application can be defined. Many can be selected at once.
- The second option, when a deployment plan is created, under Plan Assets /Apps, it is possible to classify applications.
- This is particularly important to assign an Upgrade Decision for Important and Critical applications that were identified. Using this tab to assigned importance is possible, but will be limited to this Deployment plan only.
Unfortunately, any modification to an application isn’t processed live. It usually takes 24h. The sorts will not filter any progress until then.
Note as well that the count displayed is for the App version, meaning that if you flag one application as critical, without being specific about the first, the count may be higher if multiple versions are in the field.
Define Pilot devices
The first way to identify pilot devices is to define a specific collection from ConfigMgr that will be targeted as Global Pilot.
- First, create a collection in ConfigMgr that will have the limiting collection related to the main Target collection of Desktop Analytics
- Once created, Add the collection in Administration / Cloud Services / Azure Services / Desktop Analytics, under the tab Desktop Analytics Connection
- If you do not see the collection in the wizard, it is because it’s not related to the main target collection of Desktop Analytics.
- Once synced, in Desktop Analytics/Global Pilot, the collection will be available to be checked.
- To include this collection as Global Pilot, simply select the collection and click Include
Global pilot means that devices under this collection will be part of the pilot of any Deployment plans.
These could be test/lab devices for early testing and later in the process for IT users as the first few live devices.
Depending on the size of the company, and maturity of pilot testing, SME and some power users should also be included here to ensure the testing of applications compatibility
In the same fashion to implement, it is possible to define an Exclude collection. If there are known devices that should never fall under pilot, this is the solution for it. The collection requirement is the same, and the exclude can be defined in the Global pilot section of Desktop Analitycs.
On top of devices that were identified as pilots, Desktop Analytics provides insight to add devices to the pilot in order to reach 100% coverage across applications and hardware types. This can be seen under a Deployment Plans/Identify Pilot.
The number of devices as recommended will evolve following the mandatory pilot you defined as many applications and hardware will be included by those.
When you wish to add recommended devices, select specific devices or click the Add all to pilot
For more details about Desktop Analytics Pilot devices, see Microsoft docs
Prepare the Pilot
Once Pilots are defined and synced back to the ConfigMgr collection, it’s time to prepare the pilot.
In this section, the information displayed is applications, drivers, and safeguards that have a High compatibility risk rating.
We’ve seen two different kinds of impact here:
- A Safeguard that Microsoft is working to fix
- Unfortunately, there is no link to the actual safeguard details. The name of the asset isn’t always clear.
- Make sure to review our blog post about hard blocks to better understand this key component of Feature Update
- Application or driver that are impacted during the Feature Update.
- An example below states that the FEature Update will remove the following application/driver from the device.
- This is more an FYI to make sure it works fine post-upgrade.
In all cases, those prevent devices to show up under valid Pilot devices as well as Production. Each needs to be assessed the Upgrade decision.
Important noteUpgrade decision isn’t affecting Pilot devices to be eligible to receive the feature update. After all, Pilot devices is to actually test application compatibility in a more operation oriented approach instead of managing this as a complete project.
Approve critical and important applications
At this point, pilot devices are beginning to receive the Windows 10 Feature Update. It’s time to assign an Upgrade decision in order to prepare for the production release of the Feature Update.
While reviewing the importance and readiness of applications, always review the Compatibility risk assigned by Microsoft.
Compatibility Risk High
This is really important since some applications flagged as Compatibility High, are in fact Safeguard(hard blocks) that will prevent Windows 10 Feature Update to run because of know critical impact on devices.
In the example above, there is an “application” called simply Safeguard. Hard to tell what is wrong here. 2 below, an application called SQL Setup on 20h2. Somewhat clear that it’s related to SQL being installed on a Windows 10 devices, but this is in fact a Safeguard from Microsoft.
Unfortunately, this Safeguard isn’t documented on Microsoft Docs.
To identify such a Safeguard, a look is required in the AppRaiser database. This is a topic in itself well covered by Adam Gross’ blog post.
Along with the pre-pilot experience and with reports from the pilots, Critical and Important applications are to be reviewed to assign a decision for the Windows 10 Feature Update readiness. This needs to be achieved under the Deployment Plans. Note that future Deployment plans will require this step as well.
This also emphasize the importance of one deployment plan per Windows 10 release. Having multiple one for the same build will duplicate unnecessary work.
Making such decisions will have a direct impact on many devices’ readiness. A soon as a device doesn’t have any of, Safeguard, Critical or important application not ready for upgrade, it will be considered ready for Production.
Devices will then show up in ConfigMgr collections for the Deployment plan Production.
Production device list
Like stated before, this list will be generated automatically following upgrade decisions for critical and important application, along with no safeguard from Microsoft.
From this point on, many strategies can be achieved to deploy the Feature Update. Either you use a Task sequence or the Servicing method, the assistance from Desktop Analytics will most likely ease your deployment and spare some testing time that was required before that.
The collections generated and managed by Desktop Analytics are in no way required to have the Feature Update deployed to them.
You can easily build a subset of collections to adopt a rollout strategy that fits your environment. Desktop Analytics will offer a pre-screening of the devices to give them a stamp of ready to go or not… from that point, use this information as you wish!
Windows 10 Feature Update monitoring
Desktop Analytics can also help with reporting once Feature Updates are happening.
- At the root of the deployment plan, the Dashboard provide a great high level view of the progress, along with some areas that requires reviews.
- There is 2 Deployment status section. One for Pilot and the second for Production.
- Finally, there is a Monitoring Health that reports assets (read applications) status on upgraded devices. The goal here is to highly any potential failures of approved applications to maybe reconsider a decision to prevent other devices to be broken by the Feature Update. Keep a close eye on that on when moving to Production rollout.
Desktop Analytics Windows 10 Update – Reporting
We built 2 SSRS reports that will help display Desktop Analytics’ useful data.
I really hope this shed some lights on how Desktop Analytics can help rolling Feature Updates in your environment.
Pingback: How to use Desktop Analytics for Windows 10 Feature Update – More Stuff 2 Read [Quite Sparsely]