Get Rid of Active Setup
Are you still using Active Setup to distribute per-user files or registry values? If so, stop! There are better ways to manage initial user settings.
This article assumes basic knowledge of Active Setup. You might want to refresh your memory by reading my article Active Setup Explained.
What is Bad About Active Setup?
No Documentation
Active Setup is an internal Microsoft technology. It is not documented anywhere. It might be removed or changed at any time, although it is still present in Windows 8.
No Support
Since Active Setup is not documented, I would be very astonished if you could open a support call if you have a problem with it.
No Central Management
Active Setup configuration is stored in the user and computer hives of the registry. There is no central management of these entries. Both the registry values and the files required for customization need to be placed on all computers and in all user registry hives. In case of roaming profiles, NTUSER.DAT files stored on the file servers need to be modified.
Yodas Pickup Truck by Gareth Simpson under CC
Requires Explorer
Since Active Setup is executed by Windows Explorer, it is not run when starting a published application on Citrix XenApp.
App-V
Active Setup cannot be used to configure virtualized applications.
No Conditional Execution
Active Setup is run for every user logging on. There is no functionality to execute different code depending on group membership or location.
What to Replace Active Setup With
I am aware of two alternatives to Active Setup:
- Group Policy Preferences
- Custom Framework
This could be invoked from a logon script or use a more sophisticated mechanism. It involves coding (or at least scripting) – yes, it is not trivial, but you are rewarded with great flexibility.
Recommendation
Stop using Active Setup. It is arcane technology, inelegant and difficult to manage. Depending on your needs, replace it with – nothing. That would be ideal. Most applications do not need a per user configuration when they start up. When they first start, they simply generation their initial configuration.
If you cannot get away with doing nothing, try Group Policy Preferences. It is included in the OS, comes for free and is managed centrally.
If you are more of a do-it-yourself type, consider developing a little framework that is run during logon and checks if any configuration work is required.
If the above is not right for you and you have money to spend consider a full-blown user environment management product like RES Workspace Manager.
8 Comments
Amen!
I agree with you to some level. My main gripe with AS is it can cause huge login delays for new accounts to be generated. Many vendor application use AS, so unless you re-package all of their apps (even MSI’s) you can hardly avoid it.
I’ve used it once or twice before GPP was around to deliver application registry settings to an application that had no msi entry points. (A DirectShow filter/codec)
In some ways I prefer AS over GPP as you can contain the application within one place, rather than spreading it out over other technologies like GPP.
Jesse,
There are bigger issues with ActiveSetup and Windows Installer Self-healing and that is that most of the stub/installer apps are single threaded and very CPU intense. The installers get run serially vs some parallelism that can be done in GPO/GPP. Furthermore consuming a bunch of CPU to make 2-3 registry edits, etc is a complete waste of resources. The biggest issue with AS stubs and windows installer advertised features is that most people don’t have the know how to figure out what the component is that is triggering the install and then further figure out what it’s trying to do to the system to ready it for this application. Lastly, the single biggest issue with AS and Windows installer self healing is that people rarely do a good job of roaming the required registry keys to ensure that once the changes required by the AS/MSI repair are made that you capture the keys indicating that this installer component has run. As a result, the AS stub/MSI advertised feature runs at every single logon slowing down logons every time. Helge’s advice (while not simple to follow because it requires some detective work) is learn what the AS stubs and MSI engine is doing, replace those actions with your own mechanism and don’t allow them to run anymore. Long term that’s the best approach, though it does involve some work ahead of time to accomplish.
That was my first statement when learning about user virtualization. Oh, this means we don’t need to use Active Setup any more! Cool!
It sounds as if you are suggesting that every MSI has Active Setup, which is not a good idea at all. Let’s make sure we have a good understanding of when to use A.S. If you have a package with an advertised shortcut, you don’t need A.S. Only if you have a package that (1) doesn’t have an advertised shortcut, or (2) is usually not started with a shortcut – Adobe Reader is a good example – and ONLY IF there are files or reg keys to be populated into the currnet user environment.
I agree that if you don’t have the knowledge AS is problematic, it’s not documented (except at about a thousand websites and blogs – it’s been aroung since before Win XP ) and unsupported – just like the application you are trying to fix with it otherwise it would have a MSI entry point and you would be doing repairs or a GPP – unless you have people that don’t have 100% of the time access to a policy or can afford a product like Appsense – we do but then you have policy AND groups AND desktop vs Virtual configuration to setup – or use AS to pipe that PS Script, file or registry change to each user that requires it. And your issue with a published app or Citrix – what do you need AS for anyway – every user is getting their own copy anyway???
We have used Active Setup in packages (MSI) where no entry points exist.
After an Internet Explorer (v10) patch was deployed earlier this summer, people started having issues with blank homepages (no internet!) in IE on first time login. It was found that this was caused by one of the many IE Active Setup tasks somehow changing user context while running, so that user rights to one of the files related to IE under the user profile, was created with errant rights.
The workarounds:
1. Delete those IE related files in the user profile for any user that logs in. Not very good, has to be done for each case.
2. Insert delay in the Active Setups on all existing and future packages (by putting a > first, i.e. >{productcode})
Microsoft would not do anything about this, because they say “Active Setup is unsupported”.
We need an alternative. GPP works, but it would be better to have some sort of function in the MSI files that could also handle this issue in concert with the OS, that IS supported, and is not Active Setup.
How do I get rid of it?