Category: How-to

Purview Deployment Video Series Part 1 released

I’m excited to share the first video of my Purview deployment series:

Deploying Microsoft Purview – Part 1 – AUDIT LOG | ANALYTICS | ONBOARDING DEVICES

In this video, I walk through the first steps I take when deploying Microsoft Purview in a new environment.

We’ll start by enabling the core foundations that Purview relies on, including Audit Logging, Data Loss Prevention (DLP) Analytics, Insider Risk Management Analytics, and Device Onboarding. These components provide the visibility and telemetry required to build effective data protection and insider risk strategies.

In this episode you’ll learn how to:

✅ Enable the Microsoft Purview Audit Log

✅ Verify audit logging is working correctly

✅ Enable Data Loss Prevention (DLP) Analytics

✅ Enable Insider Risk Management Analytics

✅ Configure Insider Risk integrations and user-level insights

✅ Connect Microsoft Defender for Endpoint with Intune

✅ Deploy Defender onboarding policies from Intune

✅ Onboard devices into Microsoft Purview

✅ Understand alternative onboarding methods including Group Policy, Configuration Manager, and scripts

Check out the video here:

Using Microsoft Purview to Find Files Containing Passwords and Credentials

Passwords have a habit of finding their way into places where they should not be.

  • An Excel workbook containing service accounts.
  • A project handover document with an admin password.
  • A script containing an API key.
  • A configuration file with a connection string.

These are not password-protected files. They are normal files where somebody has written a password, username, API key, token or another credential directly into the content.

Microsoft Purview already has built-in credential detection that can help us find this type of data.

And importantly, if the objective is simply to find these files, we do not need to start by creating a DLP policy.

We can start with Data Explorer.

Let’s take a look.

Credential detection in Microsoft Purview

Microsoft Purview includes a number of built-in Sensitive Information Types, usually shortened to SITs, specifically designed to identify credential patterns.

A good starting point is All Credential Types.

This is a bundled Sensitive Information Type that includes detectors for things such as:

  • General passwords
  • User login credentials
  • Microsoft Entra credentials
  • Client secrets
  • API keys
  • Access tokens
  • Connection strings
  • Shared access signatures
  • Service-specific credentials

There are also individual credential SITs including:

  • General Password
  • User Login Credentials
  • Microsoft Entra user Credentials
  • Microsoft Entra Client Secret
  • Azure SQL Connection String
  • Azure DevOps Personal Access Token
  • GitHub Personal Access Token
  • Client Secret / API Key

This means we can start broad and then narrow the search down if required.

There is an important limitation

Before going any further, there is something worth understanding.

Purview is not a magic password scanner.

It does not simply look through every document and somehow know that a random piece of text is a password.

The credential Sensitive Information Types use supported patterns, keywords and contextual evidence to identify credentials.

For example, something structured like:

username=admin;password=SomePassword

is much more aligned with the documented credential detectors than somebody writing:

The password for the old system is bluechair

Microsoft also documents that the General Password Sensitive Information Type uses English-only password-related keywords.

So this approach can help identify credentials, but it should not be treated as a guarantee that every password somebody has ever written into a document will be found.

Step 1: Test the credential Sensitive Information Type

Before searching production data, it is worth seeing how the credential detection actually works.

In the Microsoft Purview portal:

  1. Go to Information Protection.
  2. Select Classifiers.
  3. Select Sensitive info types.
  4. Search for All Credential Types.
  5. Open the Sensitive Information Type.
  6. Select Test.
  7. Upload a test file containing fake credential values.
  8. Review the results.

I would create a few simple test files containing things such as:

  • A fake username and password
  • A password assignment in a script
  • An XML configuration containing a password
  • A fake API key
  • A fake connection string
  • Normal business text that should not match

Do not use real credentials for testing.

The idea here is simply to understand what Purview is capable of detecting before looking at production data.

Step 2: Open Data Explorer

Now we can see what Purview already knows about the data.

In the Microsoft Purview portal:

  1. Go to Solutions.
  2. Select Information Protection.
  3. Select Explorers.
  4. Select Data Explorer.

Data Explorer provides visibility into content that Purview has classified using things such as Sensitive Information Types and sensitivity labels.

Rather than creating another policy just to discover the data, we can use the classification information that Purview already has.

Step 3: Search for credential information

Within Data Explorer, search for the credential Sensitive Information Type.

A good place to start is:

All Credential Types

This gives us the broadest view of content that Purview has classified as containing supported credential patterns.

From there, we can start drilling into the results.

For example:

All Credential Types

Then: SharePoint

Then: Site

Then: Folder

Then: File

The same approach can be used with OneDrive.

This gives us a way of working from the classification down to the actual location of the file.

Step 4: Narrow the search

All Credential Types is useful for the initial discovery because it covers a large number of credential types.

But sometimes we might want to be more specific.

Instead of searching for everything, we could search for individual Sensitive Information Types such as:

General Password

or: User Login Credentials

Or perhaps we are specifically interested in secrets used by applications: Microsoft Entra Client Secret

Or development credentials: GitHub Personal Access Token

Or database credentials: Azure SQL Connection String

This is where the built-in credential Sensitive Information Types become really useful.

We can start broad and then narrow the investigation depending on what we find.

Step 5: Investigate the files

Once we have identified a file, the next step is to determine whether the match represents a genuine credential.

There are separate permissions within Purview for this.

The Data Explorer List viewer role allows an administrator to see items and their locations.

The Data Explorer Content viewer role provides additional access to the content of those items.

That second permission is obviously sensitive.

If somebody can investigate files containing credentials, they may potentially be able to see the credential itself.

Access to this capability should therefore be limited to the people who genuinely need it.

There is another limitation worth knowing about.

Credential scanning classifiers do not currently support:

  • Contextual summary
  • Redacted preview
  • Match feedback
  • Not a Match feedback

That means credential matches need to be investigated carefully.

Step 6: Remediate what you find

Finding the file is only the start.

If a genuine credential is discovered, a remediation process could look something like this:

  1. Confirm that the match is a genuine credential.
  2. Identify the system or service associated with it.
  3. Rotate or revoke the credential.
  4. Remove the credential from the document.
  5. Replace it with an approved reference to a secrets-management platform.
  6. Review who had access to the file.
  7. Investigate relevant activity if required.

The important part here is rotate or revoke the credential.

Simply deleting the password from the document does not mean the credential has not already been seen or copied.

What about DLP?

This is where I think the distinction becomes important.

If the requirement is:

“Show me files that Purview has identified as containing credentials.”

Start with Data Explorer.

There is no need to create a DLP policy just to perform that discovery.

But once we have established that credentials are being stored in documents, the next question becomes:

How do we stop this happening again?

That is where Data Loss Prevention becomes useful.

A DLP policy can use the same credential Sensitive Information Types as conditions.

For example:

Content contains > Sensitive information types > All Credential Types

The policy could then be used to:

  • Generate alerts
  • Notify users
  • Display policy tips
  • Monitor activity involving the content
  • Apply restrictions where appropriate

So I see the two capabilities as solving slightly different problems.

Data Explorer helps us understand what is already there.

DLP helps us introduce controls around what happens when that type of data is detected.

Taking it further with DLP

Once the initial discovery has been completed, a custom DLP policy could be created.

In the Microsoft Purview portal:

  1. Go to Solutions.
  2. Select Data Loss Prevention.
  3. Select Policies.
  4. Select + Create policy.
  5. Select Custom.
  6. Create a Custom policy.
  7. Select the required locations.
  8. Create an advanced DLP rule.
  9. Add the condition Content contains.
  10. Select Sensitive info types.
  11. Add All Credential Types or the individual credential SITs required.

I would start any new policy in simulation mode.

This allows the policy conditions to be evaluated before introducing enforcement.

Once the results have been reviewed, the policy could then be tuned and appropriate alerts, notifications or restrictions introduced.

Advanced classification scanning and protection must be enabled when credential scanning Sensitive Information Types are used with Endpoint DLP.

This can be configured from:

Data Loss Prevention > Overview > Data loss prevention settings > Endpoint settings > Advanced classification scanning and protection

The Devices location can then be included within the DLP policy.

  1. Go to Solutions.
  2. Select Data Loss Prevention.
  3. Select Policies.
  4. Select the existing DLP policy and select Edit policy.
  5. Ensure Exchange email, SharePoint sites, OneDrive accounts and Devices are selected as locations.
  1. Edit the existing advanced DLP rule containing All Credential Types or the individual credential sensitive information types.
  2. Add the condition Content is shared from Microsoft 365 and select with people outside my organization.
  3. Under Actions, select Restrict access or encrypt the content in Microsoft 365 locations.
  4. Select Block users from receiving email or accessing shared SharePoint and OneDrive content.
  5. Select Block only people outside your organization. This prevents the document being sent externally through Exchange or shared externally through Teams, SharePoint or OneDrive.
  6. Set User notifications to On.
  7. Enable Notify users in Office 365 services with a policy tip.
  8. Customise the policy tip with a message such as: A password or credential is believed to have been detected in this document. This action has been blocked to prevent the document leaving the organisation. Remove the credential and try again.
  1. Ensure User overrides are not enabled so the user cannot bypass the restriction.
  2. Under Incident reports, enable Send an alert to admins when a rule match occurs.
  3. Add the required administrators or security team under Send email alerts to these people.
  4. Create a separate advanced DLP rule for Devices using the same credential sensitive information types.
  5. Under Actions, select Audit or restrict activities on devices.
  6. Set supported exfiltration activities such as uploading to restricted cloud services, copying to removable USB devices, copying to network shares, printing, copying to the clipboard, transferring through restricted applications, Bluetooth and RDP to Block.
  1. Enable User notifications for the endpoint rule and use the same credential-detection message.
  2. Configure the endpoint rule to send an alert to the required administrators when the rule is matched.
  3. Save the rules and select Turn the policy on immediately.
  4. Test the policy by attempting to send the document to an external Exchange recipient, share it externally through Teams and transfer it using the configured endpoint activities.
  5. Confirm that the transfer is blocked, the user is informed that a credential may have been detected and the administrator receives the DLP alert.

The important thing is that DLP comes after we understand the problem, rather than creating a DLP policy simply because we want to search the data.

Licensing

An E5 licence is required to use credential scanning Sensitive Information Types.

This is worth checking before planning the solution.

Summary

There are really two parts to this.

Finding the problem

Use the built-in credential Sensitive Information Types with Data Explorer.

A simple starting point is:

All Credential Types > SharePoint / OneDrive > Site > Folder > File

Then investigate the matches and remediate genuine credentials.

Preventing the problem

Once we understand what is being stored and where, we can introduce Data Loss Prevention using the same credential Sensitive Information Types.

That gives us the ability to move from simply discovering credentials to alerting, educating users and potentially restricting what can happen when credentials are detected.

So the approach becomes:

  1. Test the credential Sensitive Information Types.
  2. Use Data Explorer to see what Purview has already classified.
  3. Search using All Credential Types.
  4. Narrow the investigation using individual credential SITs where required.
  5. Investigate genuine matches.
  6. Rotate or revoke exposed credentials.
  7. Remove credentials from the files.
  8. Consider DLP if ongoing monitoring or prevention is required.

Sometimes the simplest place to start is not another policy.

It is looking at what Purview already knows about your data.

Note: When configuring DLP policies, keep in mind the service limitations of Purview. Particularly the 2 million character scanning limit for file content. If your environment has many files like this, consider deploying auto labelling policies based on file criteria that is likely to occur earlier in the file, then targeting DLP policies at the labels.

Microsoft Learn references

Windows 11 Snap Layouts – Multitasking Tool Overview

💡 Many organisations are completing their Windows 11 rollouts, and the improved Snap layouts feature is one I see underused for multitasking. Despite being around since Windows 10, I encounter many people who are unfamiliar with it.
I’ve made a short video showing how Snap layouts work and why they’re a highlight for anyone juggling multiple apps. If you’re new to Windows 11 or just want to get more organised, this is worth a look.

Let me know if you’ve found other Windows 11 features that help you work smarter.

How to Disable Windows Copilot using Intune or Group Policy

In this post I will explain how to use Microsoft Intune or Active Directory Group Policy to disable Windows Copilot for one or more users.

Introduction

On 26th September 2023, Microsoft released optional update KB5030310, one of the most ground breaking updates to Windows in recent times. With it comes Windows Copilot, which for millions of users worldwide will serve as an introduction to using an AI powered chat interface to enhance their day to day productivity.

Many organisations are still adjusting to the march to an AI enabled workplace and so need some time to test and understand before unleashing it for their workforce.

Disable with Intune

Edit: 23/10/2024 - in May 2024 Microsoft have deprecated the TurnoffWindowsCopilot policy CSP that is referenced in the steps below. This means the Intune steps in this post will not work. See Microsoft's post on the subject:  https://techcommunity.microsoft.com/t5/windows-it-pro-blog/evolving-copilot-in-windows-for-your-workforce/ba-p/4141999

A recent addition to the Policy CSP is the TurnOffWindowsCopilot setting, documented here. At the time of publishing this post there is no built-in setting in Intune to manage Windows Copilot. So we will create a custom OMA-URI policy:

  • In Intune, select Devices > Windows > Configuration Profiles > Create profile.
  • Under Platform select Windows 10 and later.
  • Under Profile type select Templates.
  • Under Template Name select Custom > select Create.
  • Name the profile something meaningful.
  • Under Configuration Settings select Add.
  • Set the name to something meaningful.
  • Under OMA-URI enter the below text:
./User/Vendor/MSFT/Policy/Config/WindowsAI/TurnOffWindowsCopilot
  • Set Data type to Integer.
  • Set the Value to 1 (setting it to 0 will enable Windows Copilot which is the default setting).
  • Save the policy and assign it to a security group containing users for whom you wish to disable Windows Copilot.
  • No reboot is required. When the user next signs in, the Windows Copilot icon in the taskbar will have been removed.
The Administrative Template that is used in the Group Policy version below cannot be imported in to Intune as a Custom Administrative Template. When you come to apply it to a device it will fail because it tries to modify a protected part of the registry.

Disable with Group Policy

Pre-Requisites

  • Obtain the WindowsCopilot.admx and WindowsCopilot.adml files from the C:\Windows\PolicyDefinitions file of a Windows 11 device that has the KB5030310 installed on it.
    • When Windows 11 23H2 is released it will include the same files.
    • Alternatively, you can download the files from my Github here.

Implement Group Policy

  • Import the WindowsCopilot.admx file to the PolicyDefinitions folder in your domain. This will either be C:\Windows\PolicyDefinitions on your Domain Controllers or if you have a central store configured (which you should do), it will be in a location like: 
\\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions
  • Import the WindowsCopilot.adml file to the PolicyDefinitions\en-US folder.
  • On a Domain Controller or from a device with the AD DS management tools installed, open Group Policy Management console.
  • Create a new Group Policy Object and name it something meaningful.
  • Edit the GPO, expand User Configuration > Administrative Templates > Windows Components > Windows Copilot
  • Open the setting Turn off Windows Copilot.
  • Set it to Enabled.
  • Select OK. The policy will now look like this:
  • Link the GPO to an Organisational Unit that contains users for whom you wish to disable Windows Copilot.
  • No reboot is required. When the user next signs in, the Windows Copilot icon in the taskbar will have been removed.

Summary

Windows Copilot provides an opportunity for users to begin experimenting with a new way to command their computers. In a production environment, it is important to use deployment rings such as Test, Pilot and Broad to prepare for and understand the impact of any change to the environment. An ability to roll back for individual users is most welcome. Fortunately, Microsoft have made it easy to switch Windows Copilot on and off on a targeted basis.

How to Get Windows Copilot Preview

In this post I will describe how to install the Windows Copilot Preview update.

Introduction

On 26th September 2023, Microsoft released optional update KB5030310, one of the most ground breaking updates to Windows in recent times. With it comes Windows Copilot, which for millions of users worldwide will serve as an introduction to using an AI powered chat interface to enhance their day to day productivity.

Now lets walk through how you can get your hands on it.

Prerequisites

  • A device running Windows 11 22H2.
  • An environment that allows you to manage your Windows Update settings (some corporate networks prevent users from doing this by restrictive policies).

Installing Windows Copilot Preview

The process requires a reboot
  • From the Desktop select Start > Settings > Windows Update.
  • Turn on Get the latest updates as soon as they’re available.
Enabling preview features may reveal additional features unrelated to Windows Copilot. I recommend only doing this on test devices.
  • Select Check for Updates.
  • The update “2023-09 Cumulative Update Preview for Windows 11 Version 22H2 for x64-based Systems (KB5030310)” will appear. 
It is possible to install the update without enabling Get the latest updates as soon as they're available however, Windows Copilot will be hidden.
  • If you don’t see the update, try selecting Advanced options > Optional updates.
  • Install the update.
  • Reboot the device.
  • Login and wait for the Desktop to load. You will now see the Copilot Preview icon
  • Select the icon and you will be presented with Windows Copilot! Enjoy!
The screenshot above was taken while logged in on an Azure AD joined device that had Bing Chat Enterprise enabled. This is what the Protected green shield at the top signifies.

Summary

Welcome to a new way of commanding your device. As you can see, it is easy to install the preview. When Windows 11 23H2 is released in Q4 2023, Windows Copilot will be enabled by default. Check out Microsoft’s 2 minute video overview of features in this update:

How-to: Renew Apple Push Notification Certificate in Microsoft Intune

In this post I will cover:

  • Why Microsoft Intune uses an Apple Push Notification Certificate
  • Key points of APN certificate management in Intune
  • Checking if the APN certificate is expired
  • How to Renew an APN certificate in Microsoft Intune

Note: This post assumes that you already have Intune configured with an Apple Push Notification certificate and are managing Apple devices via Intune MDM.

What is an APN certificate used for?

An Apple Push Notification certificate is issued by Apple and is used by a Mobile Device Management system to authenticate itself to the Apple devices that it manages. In the case of Microsoft Intune, it sends the APN certificate to the Apple device and the Apple device, such as an iPhone, validates the certificate before accepting management messages from Intune.

Key points of APNC management in Intune

  1. If the APN certificate expires and the grace period of 30 days passes then ALL of the Apple devices managed by Intune MDM will stop accepting management tasks from Intune. If this happens then all devices will need to be re-enrolled in Intune. This is a difficult task for a large organisation!
  2. When an APN certificate is due to expire you must always renew the certificate and not create a new one. Using a brand new certificate will break the trust between your existing Apple devices and Intune. If you accidentally do this, you can revisit the Apple portal and renew the expiring certificate. Loading that in to Intune should restore service for the existing Apple devices.
  3. Your APN certificate is tied to the Apple ID that was used to create it. If you do not have access to this Apple ID (such as it was created in the name of a former employee) then start taking steps now to gain access! One workaround is to contact Apple Developer Program Support with the certificate details and they will be able to migrate the certificate to another Apple ID.
  4. Once a renewed APN certificate is loaded in to Intune, all Apple devices will seamlessly transition to accepting the new certificate. There are no device side changes required

Where to find your APN certificate expiry date

It is extremely important to be aware of when your APN certificate is due to expire for the reasons mentioned above.

  1. In the Endpoint Manager portal https://aka.ms/dmac > Devices > Enroll devices > Apple enrollment > Apple MDM Push certificate
  2. On this page you will see which Apple ID the created the certificate as well as the expiry date.

If your APN certificate has already expired then you will see the following alert on the Home > Connector status tab of the Endpoint Manager portal as seen below:

How to renew an APN certificate in Microsoft Intune

  1. In the Endpoint Manager portal https://aka.ms/dmac > Devices > Enroll devices > Apple enrollment > Apple MDM Push certificate.
  2. The lower section of the page allows you to renew your certificate. Select Download your CSR.
  3. A file called IntuneCSR.csr will be downloaded.
  1. Select Create your MDM push Certificate > Login to the Apple portal that opens with the same Apple ID as was used to create the soon to expire APN certificate.
  2. Select Renew next to the certificate. DO NOT select Create new certificate!
  1. Select Choose file > upload the IntuneCSR.csr file > select Upload
  1. Select Download to download the new certificate.
  2. A file called MDM_Microsoft_Corporation_Certificate.pem will be downloaded.
  3. Back on the Intune portal, enter the Apple ID used to create the Apple certificate > Upload the .pem file.
  1. Once Intune validates the certificate it will show as Active with a green tick at the top of the page. There are no devices side actions required.

Summary

The Apple Push Notification certificate enhances the security of Intune MDM. Maintaining it is often overlooked because it is easy to set up and normally created as part wider project to migrate to Intune with many moving parts.

It is essential however to stay ahead of expiry and failing to do so can have a huge impact on device management. It should be treated like any other certificate maintenance plan. Key tasks are:

  • The Apple ID credentials are recorded and stored securely.
  • The expiration date is entered in to a calendar that can alert IT staff.
  • The steps to renew the certificate are recorded in a knowledgebase.

How-to: Use the Software Update Point or Windows Update when deploying Windows 10 Feature Updates in ConfigMgr Task Sequences

Introduction

Microsoft Endpoint Configuration Manager Current Branch 2103 now combines the ease of Windows 10 Servicing with the versatility of Task Sequences.

The Windows 10 Servicing node in ConfigMgr has been around for some time however many organisations have not been able to rely on it solely for workstation upgrades. Frequently Task Sequences need to be deployed to carry out the Feature Update in order to clean-up the workstation prior to upgrade or refresh Applications and Drivers to compatible versions.

Doing this carries a burden on the infrastructure. An entire OS image (~5.5GB for 20H2) needs to be stored on Distribution Points in addition to the OS image used for a bare metal OS deployment Task Sequence. Workstations need to download the entire package in order to upgrade. In reality, they do not need all of the files in the package because they already have many of them.

What if we could deploy only the files needed for the Feature Update and even allow clients to download them directly from Windows Update?

Well, now we can! ConfigMgr 2103 introduces integration between the Software Update Point and Task Sequences. Below we will step through how to configure this.

There is no change to the user experience whether you use an upgrade Task Sequence based on an OS image (wim) or Feature Update (esd) file.

Pre-requisites

  • A Software Update Point must be configured in the Configuration Manager environment.
  • The SUP must be configured to download the Upgrade classification for the product Windows 10, version 1903 and later.
  • The SUP must be syncing the same language updates as the workstations that will be targeted for upgrade.

Basic Upgrade Task Sequence

The first thing you may think is that we can simply create a new task Sequence and select a new option in the wizard. Nope, sorry!

We must create a custom Task Sequence and add an upgrade step (or modify an upgrade template from the wizard but more on that later). To do this, open the ConfigMgr console:

Go to Software Library > Operating Systems > Task Sequences > Right click Task Sequences and select Create Task Sequence.

Select Create a new custom task sequence

Give the Task Sequence a Name. Do not attach a Boot image. Optionally select Run as high performance power plan.

Next to create the empty Task Sequence.

Navigate to the new Task Sequence and edit it to open the editor.

Select Add > Images > Upgrade Operating System

On the right, select Install the following feature updates and click the sun symbol.

Expand Classifications > Upgrades > Microsoft > Windows 10, version 1903 and later

Select the version and language you wish to deploy. In this instance it is business editions, 20H2 en-gb x64.

Next go to Add > General > Restart Computer

On the right under Specify what to run after restart: select The currently installed default operating system.

Select OK. That is the all we need to create a basic Task Sequence that will upgrade Windows 10 to 20H2.

This post will not cover all the steps of deploying a Task Sequence except to highlight that when you deploy the new Task Sequence you will find an additional item in the wizard called Deployment Package.

If you have deployed Software Updates from ConfigMgr then you will be familiar with this tab. This appears because we are making use of ConfigMgr’s Windows 10 Servicing components. Here we select which Deployment Package we want to download the update to or we can create a new one.

Note: If you have already downloaded the Feature Update to a Deployment Package then you are not presented with the Deployment Package tab in the wizard.

At the bottom you can select not to use a Deployment Package. Doing this means the client will use peers (if configured in the environment) or the internet based Windows Update service to download the Feature Update file. VPN clients with split tunnels for internet access may be a good target for such a configuration.

Testing the Deployment

In the lab we have a Windows 10 1909 Enterprise x64 client that I have deployed a 20H2 Task Sequence upgrade to as an Available deployment. I selected the option for no deployment package so that the client downloads the update from the internet.

In Software Center we see the Task Sequence.

We select to install. The Task Sequence runs just like a normal upgrade Task Sequence.

In the client’s ContentTransferManager.log we see the below line confirming that it has started downloading the .esd Feature Update file from Microsoft.

ContentTransferManager.log | Click to zoom in

The .esd file is ~3.8GB. This is 30% less than the 5.5GB image we would have had to use in the old Task Sequence upgrade method.

After the install the device restarted as part of the Task Sequence steps we configured. We now see version 20H2 is now running on the device.

Advanced Task Sequence

A more realistic Task Sequence for upgrade has a number of pre and post actions. This new way of delivering the .esd file can be piggybacked on to the template that Microsoft provide.

To do this you must already have an Operating System Upgrade image saved in ConfigMgr. It can be for any Feature Update version as we only need it to complete the wizard as you will see below.

Go to Software Library > Operating Systems > Task Sequences > Right click Task Sequences and select Create Task Sequence > Upgrade an operating system from an upgrade package

Give the Task Sequence a Name. Optionally select Run as high performance power plan.

On the Upgrade Package tab, select any Upgrade Package that is already in the environment. Don’t worry about the Edition index, just select Next.

Next all the way through and create the Task Sequence. Once created, edit the Task Sequence to display the editor.

Select the Upgrade Operating System step and change it to Install the following feature updates and click the sun symbol.

Expand Classifications > Upgrades > Microsoft > Windows 10, version 1903 and later

Select the version and language you wish to deploy. In this instance it is business editions, 20H2 en-gb x64.

Now we have an advanced template to build out all the steps we need.

Summary

The integration of Windows 10 Servicing components presents options for reducing the overall footprint of Feature Updates on a network. Previously, to reduce this required separating the advanced capabilities of Task Sequences from the actual upgrade delivered by Windows 10 Servicing.

Clients can now connect directly to Windows Update to download the Feature Update file for a Task Sequence upgrade rather than rely on the Distribution Points or a CDP enabled Cloud Management Gateway (the latter of which can incur costs).

How-to: Desktop Analytics – Export list of devices a given Application or Driver is installed on

Desktop Analytics is now available in Public Preview - Microsoft Tech Community

Introduction

Desktop Analytics is a powerful tool for helping plan deployments of Windows 10 Feature Updates. Two of its features are the Apps and Drivers tabs which provides cloud enabled insights in to your Application and Driver estate and its compatibility with Windows 10 Feature Updates.

The Apps tab has a Plan Installs column which tells you how many devices the particular Application is installed on. Similarly, the Drivers tab has a Plan Devices column which does the same.

One of the shortcomings of the Desktop Analytics console is that although it tells you how many devices have an Application or Driver , you cannot drill down further to get a list of those devices. Being able to view the list of devices without having to run a report in ConfigMgr is a challenge that I recently encountered.

In steps Log Analytics workspace queries! Desktop Analytics stores its data in a Log Analytics workspace. Using the query language Kusto (KQL) we can search the database directly and export lists of devices. Below I have shared the scripts I wrote to do this along with explanations of what they are doing.

Skip to the end of this post if you just want to see the scripts in their entirety.

Pre-requisites

  • Ability to run queries in the Log Analytics workspace in which Desktop Analytics resides.
  • Access to the Desktop Analytics console.

Prepare

1. Get the exact wording for the search terms

First go to the Desktop Analytics console and drill down in to your Deployment Plan > Plan assets > Apps.

Select the Application that you want to report on from the list. In this example I want Adobe Acrobat Reader DC version 21.001.20145.

Copy the exact wording of the name and version number. We will use this in the script query.

If you are searching for a Driver then you go to Deployment Plan > Plan assets > Drivers.

Select the Driver that you want to report on from the list. In this example I want the HP HD Camera Driver spuvcbv64.sys version 3.7.8.5.

Again, ensure to copy the exact wording of the name and version number.

2. Open a Log Analytics workspace query

Navigate to the Log Analytics workspace that contains the Desktop Analytics data. On the left hand menu select Logs.

You should see a blank New Query 1 window (you may have to close the Queries popup to see this).

The scripts use tables in the Microsoft365Analytics sphere. If you expand this on the left you will see all the available tables.

Tip: Double clicking a table will add it to the query pane. Select Run with just the name of a table in the query pane and you will see all the data in the table.

Scripts Deep Dive

Tip: Desktop Analytics takes a data scrape from Microsoft’s central Telemetry repository once every 24 hours. The historical data is left in the tables. So when searching a table be sure to filter by the last 24 hours to prevent duplication of results!

Applications

There are three sections to this code that deal with each table it needs to work through to find the device names from a given Application name.

Part 1

Creates a variable named AppProgID.

Searches the MAApplication table for the Application name and version number. Filter on the most recent data scrape (last day) and extract only the unique ProgramID. There is one ProgramID per Application/Version pairing so each version of Adobe Acrobat Reader DC has its own unique ProgramID.

Tip: You can leave the AppVersion field empty if you are searching for an Application that Desktop Analytics has not detected the version of. You will encounter these In the DA console, the version field is blank.

Part 2

Another variable is created called Devices. Searches the ProgramID column of the MAApplicationInstance table for entries matching the ProgramID stored in the AppProgID variable.

Filters for the most recent data scrape (last day) and extracts the unique device ID. These IDs are meaningless outside of Desktop Analytics so we need to convert these to the device names.

Part 3 (click to zoom in)

Search the DeviceID column in the MADevice table for anything matching entries in the Devices variable. Filters for the most recent data scrape (last day) and extracts a useful set of information about the devices.

  • Output (click to zoom in)

You can export this list to CSV by clicking Export at the top of the Query pane.

Drivers

Due to a difference in the way the data is stored in the tables there are only two parts to this script.

Part 1

Creates a variable named DeviceID.

Searches the MADriverInstanceReadiness table for the Driver name and version number. Filters on the most recent data scrape (last day) and extracts only the unique DeviceID of all devices that have the Driver installed.

Tip: You can leave the DriverVersion field empty if you are searching for a Driver that Desktop Analytics has not detected the version of. You will encounter these in the DA console, the version field is blank.

Part 2 (click to zoom in)

Search the DeviceID column in the MADevice table for anything matching entries in the DeviceID variable. Filters for the most recent data scrape (last day) and extracts a useful set of information about the devices.

Output (click to zoom in)

You can export this list to CSV by clicking Export at the top of the Query pane.

Scripts In Full

Applications

// Desktop Analytics: List workstations with a particular
// Application installed.
// Author: Marcus Zvimba, 28th April 2021
//
/////// INSTRUCTIONS
// Replace the text in the speech marks after AppName and AppVersion with the name and
// version of the Application as it appears in the Desktop Analytics console.
// The text is not case sensitive.
//

//Get ProgramID
let AppProgID =
    MAApplication
    | where AppName =~ "Adobe Acrobat Reader DC"
    | where AppVersion =~ "21.001.20145"
    | where TimeGenerated > ago(1d)
    | project ProgramId;
//Get Device IDs
let Devices =
    MAApplicationInstance
    | where ProgramID in (AppProgID)
    | where TimeGenerated > ago(1d)
    | project DeviceId;
//Get Device Names
MADevice
| where DeviceId in (Devices)
| where TimeGenerated > ago(1d)
| project DeviceName, DeviceId, DeviceLastSeenDate, Manufacturer, Model, OSVersion, OSEdition, OSBuildNumber, OSArchitecture

Drivers

// Desktop Analytics: List workstations with a particular
// driver installed.
// Author: Marcus Zvimba, 28th April 2021
//
/////// INSTRUCTIONS
// Replace the text in the speech marks after DriverName and DriverVersion with the name and
// version of the driver as it appears in the Desktop Analytics console.
// The text is not case sensitive.
//

//Get DeviceID
let DeviceID =
    MADriverInstanceReadiness
    | where DriverName =~ "spuvcbv64.sys"
    | where DriverVersion =~ "3.7.8.5"
    | where TimeGenerated > ago(1d)
    | project DeviceId;
//Get Device Names
MADevice
| where DeviceId in (DeviceID)
| where TimeGenerated > ago(1d)
| project DeviceName, DeviceId, DeviceLastSeenDate, Manufacturer, Model, OSVersion, OSEdition, OSBuildNumber, OSArchitecture

Summary

Kusto is a powerful language and once the core concepts are understood it can be leveraged to maximise the data available from Desktop Analytics. You can create graphical reports to compliment the built-in reports in the Desktop Analytics console.

There is not much movement from Microsoft on the Desktop Analytics UserVoice forum so I highly recommend becoming familiar with how to query the data directly.