AppDeploy - HKEY_CURRENT_USER - Pushing User Profile Settings

Home > Articles > HKCU - Pushing User Profile Settings

HKCU - Pushing User Profile Settings

HKCU (HKEY_CURRENT_USER) settings introduce a different set of problems in deployment. These registry settings are stored in each individual user profile and that makes getting them to everyone a bigger problem than simply installing files and registry settings to a machine. Most well written applications that use HKCU to store user preferences will detect the hive and default values don’t exist when first run. The application should then create and populate its HKCU information with defaults automatically. However, some applications that are not written so well may need to have its desired settings present in order to function properly. More often pushing HKCU settings becomes a task for those wishing to deploy a nonstandard set of default user settings with an application. There are two basic ways to complete this task, through a logon script or through system policy settings.

Most networks use a logon script of some kind. If not, a script can still be used in the same way by adding it to the “All Users” startup group. Either way you do it, you will be sure to want the script to run only once for each user. To do this, the script should first check for a footprint left behind by its initial execution before running, this will prevent it from running over and over again. The footprint can be any change performed by the script that can then be checked for to show the script has been run before. It is a good idea to keep these footprints located in a central area so that they may be checked for later with greater ease. An example:

If $FOOTPRINTS\Change1 = "Complete" Then Goto "End" EndIf
If Exist "$FOOTPRINTS" <> 0 AddKey "$FOOTPRINTS" EndIf
SetValue ("$FOOTPRINTS", "Change1", "Complete", "REG_SZ")

In the above example the script will only run once for each user. The footprint area in the registry will be created if it doesn’t exist. The example is written in KixTart, but can be just as easily written as a simple batch file, in Perl or in any other scripting language. Here the Windows NT “REG” command is used to implement some previously defined registry entries.

The second way to implement user settings, and in some cases the better way, is to use system policies. System policies force registry entries and can do so to all users, or members of specified NT groups. Remember that this method forces settings, so anything set here will always overwrite any settings made by users.

Most think of system policies as what is presented in the default templates provided by Windows NT. However additional settings can be used as well by creating a custom template. For example:


CATEGORY !!MicrosoftIE
CATEGORY !!ConnectionTab 
KEYNAME "Software\Policies\Microsoft\Internet Explorer\Control Panel" 
POLICY !!ProxyEnable
            KEYNAME "Software\Microsoft\Windows\CurrentVersion\Internet Settings"
            VALUENAME "ProxyEnable"
            VALUEON NUMERIC 1
            VALUEOFF NUMERIC 0

A good source of detailed information on creating a custom policy template can be found at: http://msdn.microsoft.com/library/winresource/dnwin95/s646d.htm. An excellent overview of system policies can be found at: http://www.microsoft.com/SYSPRO/win98/Reskit/Part2/wrkc08.asp.

By default system policies are always implemented if present, this can be controlled by the following registry entry:


UpdateMode is a REG_DWORD with the data values:  
0 - A policy file is not downloaded from a server and is not applied.
1 - NTconfig.pol is downloaded (if present) from the NetLogon share of the %LogonServer% and applied.
2 - The UNC path of the policy file is read from NetworkPath and if present, downloaded and applied.

NetworkPath is a REG_SZ value that contains the full UNC path to the policy file. It is only used if UpdateMode is a 2. Example: \\ServerName\ShareName\Policy.pol

The System Policy Editor is not included in the floppy disk version of Windows 95. You can download Policy.exe that contains Poledit.exe. Please see the following article in the Microsoft Knowledge Base for information about downloading Policy.exe: Q135315 

One additional thing to keep in mind is what settings are present in the default user profile. Unless these scripts or policies are to remain in place to cover any new users, which is perfectly acceptable, the default user profile should be modified to incorporate any desired changes. Remember there are two default profiles to update, both the local and network default profiles.

The time will come when pushing user settings becomes necessary. If each machine is used by just one user, and packages are pushed in a way that the user actually performs the installation- HKCU settings can be pushed with the installation package itself. This is rarely the case though, and it is only a matter of time before a particular HKCU setting must be implemented.

Bob Kelly 1/23/00


This post is locked
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ