We all know, that sometimes applications need user settings in the Current User Registry or File Changes in the User Profile. Therefore, two main Technologies could be used:
- MSI Repair / Targeted Shortcuts
- Active Setup
Most of the Package Engineers I know use Active Setup, when the package was not MSI based or some special things had to be executed. The solution was really cool and helped a lot. This functionality is also built-in in famous package wrapping utilities like the PSAppDeployToolkit. Now the main Issue is, that Active Setup entries are not migrated during an Inplace Upgrade of Windows 10.
What are the issues?
If a new user is signing on to a pc which is migrated, then affected applications will not work correctly. This is a big problem if a lot of users are signing on to multiple computers. It is the same issue if you delete the user profile, because it was corrupt. Then you will also loose the configuration of the applications which should be generated trough Active Setup. So, if your users are using multiple computers or you delete the user profiles from time to time, then you need the solution from this blog.
This led to one question, why is it not migrated? And I found an answer which I never Imagined: Active Setup is not a public available functionality and is not supported for use by other components than the operating system. This was already written in 2011, but was not that important, because in-place updates where not required that often.
It must be pointed out that the “Active Setup” mechanism has never been publicly documented and Microsoft will not necessarily support any use of Active Setup by any component that doesn’t ship within the Windows product. There are lots of undocumented mechanisms. In general, people representing Microsoft should not recommend their use — at least not without plenty of caveats. My $0.02.
Analyse if you have packages which are using Active Setup (The lazy manual way)
First of all, you have to check if you are affected by this issue. The easiest way is to setup a clean Windows 10 machine and compare the following two registry key locations with production devices in your company:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Active Setup\Installed Components HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components
If you have differences, then you have packages, which are using Active Setup and you should plan a remediation for it.
Analyze it automatically, the way I like it
I created some tools which help to detect if you are affected. These scripts are able to detect the issue, when you are running Windows 10 1703 or 1709, the other versions are not yet tested:
- This is an SCCM Inventory Extension(MOF) to get an overview of all Active Setups in your environment. With this option, you will get all Active Setup entries in your environment and you can create reports.
You can download the respective Inventory Extension Files directly from GitHub. The usage of the MOF Files is explained in the following docs article.
- I also created a PowerShell Script, which can be used with the ConfigMgr Scripts Feature. This Script will compare the default keys of a new Windows 10 device with the one on your device and return compliant if no other than the default one exists. The Script can be downloaded from GitHub.
The last option is to use a SCCM Configuration Item which will report the compliance of each Device. Also this can be downloaded from GitHub.
So how can we solve this issue?
The very important thing is: Know that there is an issue and if you are affected!!! There are some ideas how to solve that:
- First, we thought about a script, which will backup the Active Setup registry keys before executing the in-place upgrade and restoring them when it was successfully. This could be an easy solution for ConfigMgr Task Sequences, but it is nearly impossible to detect, which Active Setup Entries are from an operating system component and which not. So, this idea cannot be used.
- The second idea is based on MSI Repairs. We could try to repackage all the non MSI Apps which require user settings. There was always the goal of Microsoft to have just MSI packaged application, but this was never reached, because you should not repackage all the applications you have.
The third option is to build an own solution for this issue, which uses the same functionality as active setup, but is using another registry path. This is the solution we choose, because it has the biggest flexibility.
Create our own implementation of Active Setup – Active User Setup
The solution is already available for our WimAsAService and Syntaro Customers. The solution is available as source code on GitHub, if you prefer to get a compiled version inclusive an MSI, then you can request this on our Homepage.
Our solution has the following features:
- Logging of actions to %TEMP%\ActiveUserSetup.log
- Executing things once for every user after login
- Versioning of the actions, so if you change something, then the action will be executed again for every user
- Success Exit Code definition, to have a retry if the action failed on the last login.
- Wait on Exit of the process (Synchronous or Async Mode)
- Displaying Notifications during executions of the apps.
Installing Active User Setup
To have the solution available in your custom wim’s from our Image factory, just add the package GLOBAL_baseVISION_ActiveUserSetup_1.0.2_001_P_EN_x99 to your Image Type.
Download MSI for distribution over Intune and ConfigMgr
Using Active User Setup
To register an executable, you have to create a registry with the following structure:
[HKEY_LOCAL_MACHINE\SOFTWARE\ActiveUserSetup\???] "Execute"="iexplore" "SuccessfulReturnCodes"="0;3010" "WaitOnFinish"=dword:00000001 "OnlyWhenSuccessful"=dword:00000001 "Name"="Test Task1" "Version"="1" "Argument"="www.basevision.ch"
For further Information, you find the latest documentation in our Wiki.
Syntaro App Management
In Syntaro App Management, you can just download the actual Base Script from Github, which will provide a simple functions to use the solution in your packages:
SYNTAX Add-ActiveUserSetup [[-Name] <String>] [-Path] <String> [[-Parameters] <String>] [[-SuccessExitCodes] <Int32>] [[-Version] <Int32>] [[-WaitOnFinish] <Boolean>] [[-OnlyWhenSuccessful] <Boolean>] [<CommonParameters>] DESCRIPTION Adds new task to the active User setup tasks, which are executed in usercontect of every user. A Prerequisite to use this functionality is, that you have deployed the baseVISION Active User Setup Solution. PARAMETERS -Name <String> Specifies when the task should be triggered. Default is Syntaro Installer -Path <String> The path to the Executable file. -Parameters <String> The parameters to pass to the executable specified in the Path variable. -SuccessExitCodes <Int32> List of exit codes to threat as successfull. Default is 0 and 3010. -Version <Int32> Version Number of the Active User Setup. Everytime you change something, then you should increment by 1. -WaitOnFinish <Boolean> when this option is true, the the processes are executed serial and not in parallel. Default Falue is true. -OnlyWhenSuccessful <Boolean> when this option is true, then the entry is only marked as executed, when the exit code matches one of the SuccessExitCodes. Default Falue is true. -------------------------- EXAMPLE 1 -------------------------- PS C:\>Add-ActiveUserSetup -Name "Test" -Path "iexplore" -Parameters "www.basevision.ch" -SuccessExitCodes @(0,3010) -Version 1 -WaitOnFinish $false -OnlyWhenSuccessful $true
A lot of package engineers are not aware of this unsupported feature, which they regularly used and, in the past, properly functioned. because they never did inplace upgrades of the operating systems. I hope this post gives some awareness and helps companies to save some money.
This post was a great Teamwork, Credits to Jürg Koller, Pascal Berger and Samantha Howlett which all helped to analyze this topic.
- Build better pilot rings for Updates with MEM Intune - June 13, 2021
- Automatic Intune Documentation evolves to Automatic Microsoft 365 Documentation - May 25, 2021
- Build better pilot rings for Updates with MEMCM - March 14, 2021