Article: A Deep Dive into Active Setup: Part 1
by Jacob Kimbrough
Jacob Kimbrough is a Consulting Architect at Fulcrum Technology Solutions. Kimbrough joined the Infrastructure team in 2014.
“Active Setup” has been with us a long time – at least since Windows 98, and perhaps since Windows 95. The name likely hails from the days of “Active Desktop,” which IT professionals of a certain age will remember. You can see it in action when you log in to Windows for the first time: it’s the little box that briefly flashes at the top left of your screen. It is used to make sure certain things are set up in each user’s profile the first time the user logs on and is very handy for endpoint management. Microsoft makes extensive use of its functionality to prepare new profiles – from Internet Explorer to the .NET Framework.
In this technical article, we’ll discuss what Active Setup is, why you would use it, a few use cases – and, most importantly, some tricks, caveats, and gotchas for various scenarios. If you’ve landed here with a particular Active Setup problem, I hope my hard-earned battle scars will provide you some help!
What is Active Setup?
At its core, Active Setup is a set of Windows Registry entries (created in HKEY_LOCAL_MACHINE). At logon, explorer.exe looks at these registry keys and compares them to a similar registry path in your user profile’s registry (HKEY_CURRENT_USER). If the entries don’t exist in HKEY_CURRENT_USER, then we know we haven’t run something for you yet, and we run the specified program or script.
There is also a versioning system in case you, the admin, need to update what gets run in user profiles at some later point.
Key facts about Active Setup:
- It is run by exe before the desktop appears
- It is run before Run or RunOnce registry entries are executed
- It’s run in the user context; e.g., the user who is logging on
- It can execute any arbitrary script or executable that needs to run for the user
- It runs once for each user who logs on, regardless of whether they have an existing profile
Okay… Who Needs It?
As someone who manages endpoints or terminal or VDI environments, sometimes you need to affect changes on a per-profile basis. And sometimes, you want to set something up not just for current users, but for any user who might log on in the future.
You could use a script and iterate over user profiles in C:\Users, load registry hives, and make changes. I’ve done that in the past. But that’s a little messy and doesn’t account for NEW users who might log in (unless you’re also altering the default user profile – also messy). That’s where Active Setup comes in. Microsoft makes use of use of it, too. During logon, sometimes you can glimpse titles like “Setting up Windows Media Player” or “Configuring Internet Explorer.”
When Are We Ever Going To Use This
Criteria for using Active Setup
1. You have a non-interactive script or executable that you want to execute on a PC (or lots of PCs).
2. You need it to run once, but per user.
3. You need it to run once for any user who might log onto the PC – whether they have an existing profile or are logging in for the first time to that PC.
4. You may, in the future, need to run it again (if circumstances dictate) in each user profile.
If you have something that you need to run at every logon, then you probably want to use RunOnce. Active Setup would be the thing to use if you have something you need to initialize once per user, but for every user, on a PC or terminal or Citrix server.
Example: Get OneDrive for Business going
Recently, I needed to deploy the new OneDrive for Business package to a large number of PCs. The process can be more messy than Microsoft would have you believe, and there are a lot of scenarios for which the installer doesn’t account. Recent versions of the installer have improved the process for admins, but caveats still remain. In my case, I needed a OneDrive configuration script to launch as the user (in the user’s context). I was distributing the script via SCCM (which executes scripts in the SYSTEM context, once per PC) but I needed part of it to run for each user: users who had existing profiles, and any new user who might log in. Active Setup to the rescue!
And here is the solution: I can use the SYSTEM context to set up a series of Active Setup entries. These will run in the user’s session, once per user, for any current or future user who might log on later.
Example: Set user defaults
Another recent use for me was an application in a terminal environment. The application has an XML file to hold user configuration items, and this XML is stored with the user’s profile. If a new user logs on and launches the application, it will interview the user for defaults (and auto-select some poor choices). Using Active Setup, I am able to gather the required information on behalf of the user and pre-populate the XML using a script. The end result is a clean, “already done” experience for the user.
Since the XML file only needs to be configured once for a user profile, Active Setup is a perfect fit. And, if I need to change a setting down the road, I can alter my script and have Active Setup re-run it when the users log on.
That’s it for Part 1. In Part 2, we’ll get technical and look at how to construct and test Active Setup components.
The Fulcrum Difference
At Fulcrum Technology Solutions, we differentiate ourselves from other technology- and business-consulting firms with a unique guarantee: when you hire Fulcrum, we commit to finish the job. Whether working under a time-and-materials contract or a cost-plus arrangement, we will not leave until we’ve delivered exactly what we said we’d do. Our word defines us, and motivates us to give you the service that you deserve!