Active Setup and Environment Manager Personalization

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

The “Active Setup” blogs have been done to death on various other sites but today I want to discuss this particular feature of Windows in conjunction with AppSense Environment Manager.

I will not be going in to detail as to how the individual “Active Setup” elements are executed as this is well documented.

Brief Summary of Active Setup

The purpose of Active Setup is to ensure that users have the correct settings that they need when logging on to an endpoint.

The users’ registry captures a record of the Active Setup entries that has been run against it. In essence, the following occurs:

1. User logs on
2. User profile is loaded
3. Active Setup is engaged by the logon process
4. The following registry keys are read:
   • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components; and
   • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Active Setup\Installed Components
5. Compares the entries in the registry keys above to the following keys:
   • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Active Setup\Installed Components; and
   • HKEY_CURRENT_USER \SOFTWARE\WOW6432Node\Microsoft\Active Setup\Installed Components
6. If any entries are in the HKLM keys but not in HKCU then they will be processed accordingly.

It is easy to see when active setup is running during the user logon as you should see a dialog similar to the following:

This appears in the top-left corner of the screen and the text changes according to what component is being processed. Once everything has completed, the dialog will disappear and the desktop will be presented.

Active Setup and Profile Types

When profiles of differing types are loaded, profile load times are different.

Local – Active Setup runs once on the endpoint for the user logging in for each component. When they log on to another endpoint it runs again. If profile is deleted it will run again.

Roaming – The profile (if it already exists) is copied down to the local machine at logon before Active Setup runs. It will store the settings with the profile and not run again for components already configured.

Mandatory – A built-in mechanism exists in Windows to spawn the Active Setup procedure regardless to the fact that the profile is cached on the endpoint or not.

With both Local and Roaming profiles, the Active Setup components will not be initialised again unless a new component is detected. If that is the case, only that one component will be configured.

Active Setup with Personalization

Active Setup is now available as a Windows Settings Group in Personalization out-of-box.

There are some scenarios where you may want to capture Active Setup in Personalization to help overcome some roaming issues.

If you are using Roaming profiles with Personalization, forget about it, there isn’t really much point as Windows is already doing this. It is not recommended to use Roaming profiles with Personalization as you essentially have two products doing the same thing.

In Environment Manager 8.6 it was made easier to migrate your Roaming profile data in to Personalization, so this may be something that you would want to go away and consider.

You may be using Local profiles on your endpoint for your users but want to use Personalization as a backup mechanism. Or you may simply have an application that simply will only work with a local profile. Applications that use dongles for security, for example, have been known to do this. In this scenario it makes perfect sense to capture Active Setup.

If Mandatory profiles are in use, then capturing the Active Setup key for use in common environments (Citrix, etc.) may decrease logon times as the Active Setup procedure would only run when the list of components changes.

A Couple of Pitfalls

Along with all of this comes a couple of issues and we have seen these with customer issues (not an exhaustive list) and mainly around Internet Explorer and Mandatory profiles.

However, both were resolved by the same solution.

Scenario 1 - CPU Spike when Launching Internet Explorer

When a user launches Internet Explorer it has been seen to cause a spike in CPU activity. But only occurred on logon attempts after capturing data for the first time with Mandatory profiles.

This was caused by Internet Explorer trying to generate Cookie and Certificate key information for the user session. As the profile type was Mandatory, Windows handles the information generation differently and requires Active Setup to be run.

The issue was worsened by the fact that the “Application Data” folder was redirected to a network share which is not recommended.

Scenario 2 – Internet Explorer Download Box

When a user was trying to download files in Internet Explorer, they would intermittently not receive the download notification prompt.

Unfortunately, the cause was unknown as the issue was so intermittent and sporadic. Regardless, we did manage to identify the solution.

However, the circumstances surrounding the issue were common to Scenario 1. Mandatory profiles, Internet Explorer, capturing Active Setup.

The Solution?

The solution to both the scenarios above was simply to invoke one of the Active Setup commands manually for Internet Explorer.

The command line was:

• ie4uinit.exe -BaseSettings

This was configured in Environment Manager as a policy action and executed as either a Logon action or as a Process Started action on iexplore.exe.

Another command was also identified that may also help I this scenario:

• ie4uinit.exe -UserConfig

In Closing

When configuring Active Setup to be captured in Personalization please bear in mind that when using Mandatory profiles, Microsoft require that Active Setup be run on every logon to ensure that the session is configured correctly as some information about the session is only held in memory and cannot be captured.

If you are having trouble with some applications when Personalization is enabled on your endpoint, ask yourself…

1. “Am I capturing Active Setup?”
2. “What happens if I disable Active Setup?”
3. “Is my application listed in the Active Setup Components keys?”
4. “Is there a StubPath entry that I can run manually to fix the issue?”

Hopefully, just by doing question 2 you may have already narrowed the issue down hugely.

If you are capturing Active Setup and using Mandatory profiles, I would recommend running the first Ie4Uinit.exe entry (the second one shouldn’t do any harm either) in the Solution section tested and added to your configuration as it may clear up some so far unknown issues and help create a more stable environment for your users to stay productive.

I hope you have enjoyed this article and have given you some insight on troubleshooting some of those pesky issues that rear their heads.