Part 1 – Introduction : What is WaaS?
Part 2 – Windows 10 Updates.
Part 3 – Servicing Channels.
Part 4 – Servicing Tools.
Part 5 – “Getting Current and Staying Current”
Part 6 – “Putting it all together”
Part 7.1 – Introduction to Desktop Analytics
Part 7.2 – Onboarding Desktop Analytics
I haven’t discussed in detail how to connect the MEM DA (Microsoft Endpoint Manager Desktop Analytics) with the MEM CM (Microsoft Endpoint Manager Configuration Manager) as it is outside the scope of this blog, but I have provided a link to MS Docs on how you can perform this and how to enrol your MEM CM managed devices onto MEM DA so that you end up with a “triangular connection” between MEM DA, MEM CM and the MEM CM managed devices. Once you have done this, you should have a MEM CM parent collection (and any other additional child ones you may have added) synchronized in MEM DA.
Note: You cannot have more than 1 MEM DA instance per Azure AD tenancy but, you can have multiple MEM CM hierarchies under 1 MEM DA instance.
From here, you’ll need to create one or more Deployment Plans (https://docs.microsoft.com/en-us/configmgr/desktop-analytics/create-deployment-plans). When you create a MEM DA deployment plan, you are essentially selecting a group of devices that you are targeting for a Windows 10 upgrade to a specific build. The “Create Deployment Plan” wizard asks you to enter a name for your plan, the version that the plan will be upgrading devices to, one or more groups of devices that will be targeted (selected from the list of collections that you’ve included during the MEM DA integration with MEM CM), and the target completion date; the latter will help you stay on course.
Once you have created a deployment plan, Desktop Analytics will synchronize with Configuration Manager a folder name ‘Deployment Plan’ will be created under the Device Collections in the Assets & Compliance node. You will find 2 sub-folders there: Pilot and Production. In the Pilot folder, a collection with all the Pilot devices selected from Desktop Analytics portal will be created and the same for the Production folder.
Note: As of this writing, you cannot have more than 20 Deployment Plans. This is important to point out if you plan on segregating your deployments into business units or regions. Since the scope of this blog is for very large environments, you need to take this into consideration and plan according to how you will target groups of devices for each Deployment Plan.
We’ve seen from part 5 of this series that there are 3 deployment rings: Insider, Pilot and Broad. In Desktop Analytics (DA), for each Deployment Plan there are also 3 major phases – Prepare, Pilot and Deploy – and each phase has a number of steps to follow.
Note: Unfortunately, at the time of this writing, there is no Role Based Access Control (RBAC) for MEM DA. So, if you create 2 or more Deployment Plans, you won’t be able to have 2 or more Desktop Analytics administrators exclusively manage 1 or more Deployment Plans. Each user that is granted the Desktop Analytics Administrator Azure AD role will be able to access and modify all aspects of MEM DA.
However, only the Pilot and the Broad rings can be somewhat mapped to the Pilot and Deploy phases from DA. From a WaaS perspective, the Insider ring relates to installing the Insider Program on Windows 10 devices or virtual machines so that you can evaluate the new Windows 10 features. From a Desktop Analytics perspective, the Prepare phase helps you get ready for the Pilot and for the Broad deployment phase well before you start deploying the Windows 10 update by:
The first step of the Prepare phase helps you identify which Apps are critical to your environment that are Windows 10 ready from a compatibility standpoint. You can select each app individually and chose whether it is ‘Critical’, ‘Important’ or ‘Not Important’ to your business. You can also set the “Upgrade Decision” of the app to ‘Review in progress’, ‘Ready’, ‘Ready (with remediation)’ or ‘Unable’. In addition, Microsoft uses information from data aggregated by millions of devices to provide compatibility risk factors for each app along with any known issues from Microsoft, the Adoption Rate of the app (“Contact software provider”, “Highly Adopted”, “Adopted” or “Insufficient Data”), Microsoft’s support statement (“Supported on Windows 10” or “none”) and Readiness insights. Finally, you have information on the app itself (Vendor, category, type, virtualized or not) and its usage in your environment.
Setting the Importance and the Upgrade decision of each app is an important step because, depending on the assessment you select, some devices that have that particular app installed will be included in the Pilot deployment. If an App is market as ‘Critical’ or ‘Important’, Desktop Analytics includes in the pilot deployment some devices with that app. However, if you choose ‘Not reviewed’ or ‘Unable’ in the Upgrade decision, then Desktop Analytics doesn’t include devices with this app in the pilot deployment. More information on Upgrade decision and Importance assessments are detailed here:
The second step is to identify which devices you’ll elect for your pilot. This is an important step as Microsoft has added a great functionality here: “Additional Recommended Devices”. As much as they possibly could, to test the new OS, many IT departments would select systems based on convenience. However, they could not guarantee if their selection accurately represents the majority of the organization’s fleet. With the “Additional Recommended Devices” functionality, Desktop Analytics uses Artificial Intelligence to suggest a number of devices to include in your Pilot phase in addition to the ones you have selected. As a result, the Pilot group is closer to a true representation of your organization’s global group of systems. So much so that Desktop Analytics also provides a percentage of what is covered by your selection and by the recommended selection.
Note: The “Additional Recommended Devices” are also based on the Upgrade decision and Importance values set for each App.
The third step of the Prepare phase is the “Prepare pilot” step. Here you can review the Apps and the Drivers of your pilot group and, as you review the assets, changing the “Upgrade Decision” of each asset to “Ready” or “Ready (with remediation)” unblocks the pilot devices to be included in the Pilot phase.
Note: Devices can have a ‘Blocked’ status if you set the upgrade decision of one or more assets to Unable or if the inventory data for that device is incomplete and Desktop Analytics can’t do a full compatibility assessment
The Pilot step in DA allows you to evaluate the Apps and Drivers’ compatibility and/or issues once the update has been deployed – with the OS build you are targeting – to the subset of your environment that you’ve selected in the Identify Pilot step of the Prepare phase. The Pilot Phase has just 2 steps:
The deployment status step provides information about the success or failure of the OS build deployment to your pilot devices.
The Prepare production step allows the DA administrator to set an Upgrade Decision on the Apps that might have failed or have had some sort of issue during the Pilot deployment.
And finally, the Deploy step in DA is there to monitor the deployment for your whole fleet. This phase also has just 2 steps:
The deployment status step in this phase is the same as for the Pilot phase except that it is targeted at your production devices group.
The monitor health step is also very much similar to the Pilot phase’s prepare production step.
Coming up next week, how the Desktop Analytics integration with Configuration Manager works and, on the following week, how to map the Desktop Analytics phases with the Windows as a Service deployment rings using Configuration Manager.