Running custom actions during a Windows 10 Feature Update with Configuration Manager

Deploying Windows 10 Feature Updates in your organisation can be approached in multiple ways. As we merge the perimeter with the Cloud some of us are trying to understand the best way to deliver Feature Updates to our devices. Should we deploy an in-place upgrade using a ConfigMgr task sequence? Perhaps we should push the Feature Update directly from ConfigMgr to our devices. Have we considered leveraging our CMG and using Microsoft as a source for the update binaries to save our VPNs? Maybe some of us are on a co-management journey and are looking at using WUfB. Which ever technology we are leveraging one of the questions that normally gets asked is “Can we control the update process in a way that lets us ‘Run Stuff’ after the Feature Update has completed”.

SetupConfig.ini

When a Feature Update is deployed using the Windows Update Service a file called SetupConfig.ini can be used to control some aspects of the update process. The SetupConfig.ini file can be used by admins in scenarios where there is the inability to pass specific switch parameters to setup.exe during a Windows 10 Feature Update.

Below is an example of the what the content of SetupConfig.ini might look like

[SetupConfig]
NoReboot
ShowOobe=None
Telemetry=Enable
InstallDrivers=
ReflectDrivers=

The example above is taken from
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-automation-overview

For a more comprehensive list of the commands that can be used during Windows Setup check out the following Microsoft article
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-command-line-options

The Feature Update process will look for SetupConfig.ini in the following location: –

SystemDrive\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini

PostOOBE

We can specify the POSTOOBE parameter in the SetupConfig.ini file to tell the Windows Update Service to run a command after the Feature Update has been installed. If you have previously used a ConfigMgr Task Sequence to manage in-place upgrades, you may have noticed that ConfigMgr would typically reference a batch file called SetupComplete.cmd to run after the update process. It makes sense to use the same batch file name for familiarity when we use the Windows Update Service to deploy a Feature Update. The batch file can be placed anywhere on the device as long as it isn’t removed during the Feature Update process. For this reason, placing it outside of the Windows directory is quite sensible.

Below is an example of what the POSTOOBE reference might look like in the SetupConfig.ini

[SetupConfig]
NoReboot
ShowOobe=None
Telemetry=Enable
InstallDrivers=
ReflectDrivers=
POSTOOBE=C:\ProgramData\FeatureUpdate\SetupComplete.cmd

A Batch File…Really?

SetupComplete.cmd is simply used to kick off any script or process we want to run after the Feature Update has been installed. You can specify multiple commands within the batch file or call your other custom scripts. An example of what SetupComplete.cmd may contain could be: –

Practical Example

Feature Update – Post OOBE Script

Because we are using the Windows Update Service to deliver the Feature Update (not a Task Sequence), I would typically deploy my custom POSTOOBE scripts and files as an application in ConfigMgr or Win32app in Intune. In the example that follows I will show you how to leverage SetupConfig.ini to run a PowerShell script during POSTOOBE and copy some files back into the Windows directory that may have been overwritten during the Feature Update.

Ensure the application is deployed to the client before the client is targeted for a Feature Update

The example application we will create is called Feature Update – Post OOBE Script – 1.09.04. We will deploy the application with ConfigMgr. The application uses version control and installs files used for POSTOOBE to C:\ProgramData\FeatureUpdate\<version>. The reference to the POSTOOBE command in the SetupConfig.ini will change to reflect the version of the application we deploy from ConfigMgr e.g.

Application Intent

Our application will do the following: –

  1. Create/Replace SetupConfig.ini at SystemDrive\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini
  2. Create a folder structure at: – SystemDrive\ProgramData\FeatureUpdate\<version>
  3. Create SetupComplete.cmd and add a reference to run SetupComplete.ps1. Both of these files will be saved in: – SystemDrive\ProgramData\FeatureUpdate\<version>
  4. Add a reference in SetupConfig.ini for POSTOOBE to run SystemDrive\ProgramData\FeatureUpdate\<version>\SetupComplete.cmd
  5. Version.txt should contain the version number of the application being deployed. This is useful if you change the application intent and need to ensure your devices have the up-to-date files/scripts in place before they attempt a Feature Update. The version number in this file is used to dynamically build the different elements of the solution, including the actual path where the solution will be installed. In our example, Version.txt will contain one line of text: 1.09.04
  6. Add a reference in SetupConfig.ini to set the Priority of Windows Setup to “Normal”. Some parts of a Feature Update are set to run with a low priority. Microsoft have published best practice for Feature Update priority here: – https://docs.microsoft.com/en-us/windows/deployment/update/feature-update-user-install)
  7. Copy the Files folder to SystemDrive\ProgramData\FeatureUpdate\<version>. This folder contains the files we want to copy back to the SystemDrive during POSTOOBE. The Files folder structure, in your application content source, should resemble the existing Windows disk layout. In this example, we are copying back some Default User Account Pictures to C:\ProgramData\Microsoft\User Account Pictures and a new wallpaper to C:\Windows\Web\Wallpaper
“Files” folder structure
User Account Pictures Files
Wallpaper Files

Application Installation Flow

Below is an overview of the installation flow for the Feature Update – Post OOBE Script application we will deploy from ConfigMgr

Application Scripts

We will use 3 scripts to install / maintain our “Feature Update – Post OOBE Script” application

  1. Install_SetupComplete.ps1
  2. Uninstall_SetupComplete.ps1
  3. Detect_SetupComplete.ps1

Install_SetupComplete.ps1

Uninstall_SetupComplete.ps1

Detect_SetupComplete.ps1

The installation and removal scripts will reference Version.txt to install/remove the correct version of the application. We cannot reference Version.txt to get the application version when we use a script for the detection method so the version number must be manually updated within the detection script

The version number in the Detection Method script must be updated manually to reflect the content of Version.txt

Application Content Source

You should have the following files present in your application content source folder. (The Install/Uninstall and Detect scripts will not get copied to SystemDrive\ProgramData\FeatureUpdate\<version>).

Build the Application

1. Create a new Application in Configuration Manager

2. Choose to Manually specify the application information

3. Name the application Feature Update – Post OOBE Script – 1.09.04 and add a Software version: 1.09.04

4. Add a Deployment Type of type Script Installer

5. Name the Deployment Type Feature Update – Post OOBE Script – 1.09.04

6. Specify the content location for application source files as mentioned in the previous section “Application Content Source”

7. Set the Installation program to

8. Set the Uninstallation program to

9. Set the Detection Method to use the Detect_SetupComplete.ps1 PowerShell script. Remember the version in the detection script must match the value within Version.txt

10. Set the user experience settings to

Installation Behaviour: Install for System
Logon requirement: Whether or not a user is logged on
Installation program visibility: Hidden
Maximum allowed run time (minutes): 15

11. Add a Requirement for the Operating System to equal Windows 10

12. Deploy the application as Required to the device collection that will be targeted for the Feature Update

Review Installation

You should observe the following on your targeted devices:-

  • SetupConfig.ini exists at SystemDrive\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini and has the Priority and POSTOOBE values have been populated as expected
SetupConfig.ini
  • The folder SystemDrive\ProgramData\FeatureUpdate\1.09.04 exists and contains the expected files and folders
POSTOOBE Installation Folder
  • SetupComplete.cmd contains the following line
  • SetupComplete.ps1 contains the following

POSTOOBE Review

After the Feature Update has completed, you can review Setupact.log in the C:\Windows\Panther folder and see that your script was used during POSTOOBE

Setupact.log

And in our example, the default User Account Pictures were restored and the new wallpaper copied to the Windows\Web\Wallpaper directory (and set by policy)

Default User Account Pictures restored
New wallpaper added (and set via Policy)

Summary

In this blog post we looked at how we could manipulate the Feature Update process when it is being deployed using the Windows Update Service. Now you understand the concept of SetupConfig.ini and POSTOOBE you can very easily adapt the application to be deployed as a Win32app in Intune. There are other actions you can leverage using SetupConfig.ini to give your users the best experience during a Feature Update.

SetupConfig.ini is not as versatile as using a Task Sequence but it gives us some degree of control over the update process. I am really excited to see the new feature in ConfigMgr 2103 where we can deliver Feature Updates in a Task Sequence!

Further reading and best practice can be found below

Best practices – deploy feature updates for user-initiated installations – Windows Deployment | Microsoft Docs

Windows Setup Command-Line Options | Microsoft Docs

https://docs.microsoft.com/en-us/windows/deployment/update/feature-update-user-install#step-2-override-the-default-windows-setup-priority-windows-10-version-1709-and-later

1 thought on “Running custom actions during a Windows 10 Feature Update with Configuration Manager”

  1. Hi Ben,

    Thanks for the article.

    Just wondering could I implement the same via Task Sequence as well. I tried it this morning and added the application step before the upgrade but it didn’t work.

    I can confirm all the Files and Folders were in the right place and if I manually run the SetupComplete.cmd, Correct user Profile pictures are copied successfully.

    Thanks

Leave a Comment

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.

 

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