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:
$FOOTPRINTS
= "HKEY_CURRENT_USER\Software\UserPackages"
If $FOOTPRINTS\Change1 = "Complete" Then Goto "End" EndIf
Shell "REGEDIT CHANGE1.REG"
If Exist "$FOOTPRINTS" <> 0 AddKey "$FOOTPRINTS" EndIf
SetValue ("$FOOTPRINTS", "Change1", "Complete",
"REG_SZ")
:End
Exit
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:
CLASS USER
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
END POLICY
END
CATEGORY
END CATEGORY
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:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Update
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
Comments