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.

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).

Advertisement

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.

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.

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.

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.

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.

Windows Deployment Services in Azure = No

Can SCCM be truly in Azure only? That depends on whether you consider an on premise PXE service as a part of the SCCM infrastructure or not.

WDS is not supported in Azure: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

But we all know that ‘not supported’ doesn’t always mean ‘doesn’t work’. There are many things in the Microsoft world that start off as not supported but end up being fully fledged features.

Let’s put it to the test;

  • In Azure, an SCCM primary site server running a PXE enabled DP with a boot image and Windows 10 image task sequence deployed to to the collection ‘All Unknown Computers’.
  • On premise, a DHCP server with options 66 and 67 configured. An RRAS running a IKEv2 VPN to Azure.
  • Any/Any is open on the firewalls between the Azure and on prem subnets.

What we get is…

In the screenshot below:

10.1.0.50 – PXE Boot Client

10.1.0.9 – VPN Gateway

10.0.0.4 – WDS (SCCM)

pxe

The WDSNBP.com file is downloaded using TFTP. But when it tries to get the boot image file it gets ‘No response from Windows Deployment Services server’.

After this the PXE client switches to download the pxeboot.com boot image which is the wrong image. The PXE session is therefore a failure.

There is no firewall block and clearly some traffic is being responded to by the WDS.

Using netmon we get the below trace from the WDS server

azuretrace

The first image, column 1 is the source IP, column 2 is the destination. We can see that the Request is being received by the WDS server and an ACK packet is being sent back to the PXE client. This is repeated.

Below are the ports the traffic is using. One of them is UDP 68:

pxeport

So why doesn’t the PXE client think the WDS server is responding?

Below is the netmon from the on premise RRAS server, remember this is the VPN gateway on prem.

onpremtrace

It shows the requests being relayed to Azure, but nothing coming back. Something in Azure is blocking this.

A little googling and this comes up: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq

“What protocols can I use within VNets?

You can use TCP, UDP, and ICMP TCP/IP protocols within VNets. Unicast is supported within VNets, with the exception of Dynamic Host Configuration Protocol (DHCP) via Unicast (source port UDP/68 / destination port UDP/67).”

And so there we have it. Azure appears to be actively interfering with UDP port 68 traffic, likely preventing it from being routed down the VPN. So in this scenario, the PXE service needs to be setup on premise.

Only by saying that the PXE service is not a part of the SCCM infrastructure could we, in this scenario, say that SCCM is entirely cloud based.