I was speaking to a peer via email recently (his name was Adam Steinhoff – thanks Adam – in case anyone thinks I am making him up) and we discussed an issue with application instability after removing Active Setup StubPath entries from the local machine.
For those unfamiliar with it, Active Setup is what you see when a user logs on to a machine for the first time and you see various Windows dialogs as the initial user profile and applications are set up. There are a couple of issues with this. Firstly, login time – a lot of time is eaten up by these various setup routines, and as we all know by now, login time is extremely important to end users. Secondly, if you are discarding profiles at logoff (whether they’re mandatory profiles or you’re using the guest spoofing trick), then this simply means that these myriad Active Setup routines run at every login – not a great situation.
Active Setup is controlled by a bunch of Registry keys under HKLM\Software\Microsoft\Active Setup\Installed Components and HKLM\Software\Wow6432Node\Microsoft\Active Setup\Installed Components. Each of these has a value called Version, one called IsInstalled and one called StubPath (well, most of them do). Every time a user logs in, the content of this key is compared against the same key in HKCU. If the HKCU key does not exist and/or the “Version” value is less than that in HLKM and IsInstalled is set to 0, the appropriate “StubPath” command is run and the key copied to HKCU so it is not run again. However, in situations where the profile changes are not saved, this simply leads to the process repeating itself.
An easy way around this, you may think, is simply to remove all of the StubPath entries from the HKLM hive. A good idea, but some of these commands are actually required to configure various parts of the operating system (think DotNet and some base Internet Explorer settings), so you may find some application compatibility issues once you’ve removed them. If you do end up in this situation, the key part here is identifying which StubPath entries need to run to allow your applications to function correctly, so you may be in for a little bit of trial and error. However, in the example in this blog we are going to cover one of the most common ones, the ie4uinit one, so that may be a good place to start if you are having issues.
If you remove all of the StubPath entries from HKLM and you don’t have any app issues, you are in luck, you can skip ahead to whatever the next stage of your deployment is. I normally use AppSense EM Registry actions to remove the StubPath entries (see image below) – you can use Group Policy Preferences just as effectively or update your base images. Note – the image below isn’t a list of what you’d expect to be removing, dependent on software installed, you may find a very long list of entries to be discarded from the Registry.
Don’t forget after you’ve installed Windows Updates you may see some new ActiveSetup entries, so remember to check for these after you’ve updated your systems. Now, if the removal of these values causes you some application issues, after you’ve identified the entries you need to run, you have two main choices:-
1. Let the ActiveSetup run, and save the required Registry keys (from both HKLM\Software\Microsoft\Active Setup\Installed Components and HKLM\Software\Wow6432Node\Microsoft\Active Setup\Installed Components) into Session Data
2. Do not let ActiveSetup run, and execute the required StubPath commands using a Process Started trigger
From a login/logoff time perspective, I’d choose option 2 every time. Particularly if you are in an environment where you can use a Process Start trigger like wfshell.exe (XenApp) or statustray.exe (PVS) which allows you to almost delay the execution till “after” the logon has finished, if you take my meaning. If you don’t have these options, though, explorer.exe will do the trick as the Process Started trigger. The process for setting this up is as follows:-
Create a Process Started Condition for the process you’ve selected (explorer.exe, wfshell.exe, statustray.exe or whatever process you find works the best)
Create a Flow Control Condition so that they only execute once per session (see this post if you don’t know about Flow Control Conditions)
Add an Execute Action for the commands specified in the required StubPath entries, adding parameters to the Action if specified in the Registry entry. The entry we’ve chosen as an example, ie4uinit, doesn’t have any parameters.
UPDATE – I’ve done an article on creating a Post-Logon Trigger, rather than leveraging some other part of the OS for this, see http://appsensebigot.blogspot.co.uk/2013/10/creating-post-logon-trigger-in-appsense.html
Don’t forget to add the entries from both the normal and Wow6432Node keys, if you are on an x64 system. In the example below we’ve added both, as you can see. You can also see the dependency on the Process Started and Flow Control Conditions.
Once you have saved and deployed this, you should be able to remove all of those time-consuming StubPath entries from the Registry to give yourself a smoking-fast login – but still be able to run the commands needed for your applications to work correctly.
I may be the AppSense Bigot, but however I am an independent consultant and I’d probably be inviting a snotty comment if I didn’t mention the fact that AppSense’s major competitor, RES, has a GUI option that can do this for you. So, if you guys at AppSense are watching (stupid comment – I know you are), consider this a feature request. I know the RES option just does what we’ve just covered, but it’s a bit easier for your administrator if there’s an out-of-the-box GUI option covering this. Thanks.
Share
