Challenge 2: Software Access
Most new software places Registry entries in the HKEY_LOCAL_MACHINE hive. These entries control general access to the application's files, the location of the executable and auxiliary files, and the components that the software installs. Some software places Registry entries that control functions such as button bars, default data file locations, and other software settings in the HKEY_CURRENT_USER hive. Such software requires every authorized user's personal profile to contain the software's HKEY_CURRENT_USER settings. A user whose profile doesn't contain these settings can see the files in NT Explorer but can't run the software.
Changing the default profile won't help you solve this problem because programs use settings in the default profile only to create new profiles. A program that requires users to have its HKEY_CURRENT_USER Registry entries can't use the default profile's settings for users whose profiles don't contain the necessary entries. Therefore, if you place a program's settings in the default profile's ntuser.dat file, users you create profiles for in the future will be able to use the software, but the change won't affect users who already have profiles.
Adding software settings to a policy. You can change the policy file to push a program's HKEY_CURRENT_USER Registry entries to users who already have profiles. You must copy the Registry key that the software enters in HKEY_CURRENT_USER to the default profile's HKEY_LOCAL_MACHINE hive. Adding the software settings to the policy is more difficult than passing security settings to users across the network because regedt32 doesn't have a simple copy function. To copy a Registry key from one hive to another, you must copy the key to a disk, create an empty key in the target hive, and restore the file you saved on the disk to the new key. Be extremely careful when you use this technique to copy keys. When you replace one key with another, NT deletes all the original key's information. To avoid deleting Registry information, restore Registry data only onto empty keys.
Suppose I need to give everyone in my company access to a video-capture program from Hyperionics called HyperCam. When I install HyperCam, the installation process saves the software's settings in the HKEY_CURRENT_USER\Software\Hyperionics key on all my users' computers. Screen 3 shows this Registry key. To provide all my users access to HyperCam, I load ntconfig.pol into regedt32 and open the HKEY_LOCAL_MACHINE\Policy\Users\.default\Software key. I click Edit, Add to add a key with the name Hyperionics to the default user's Software key. Screen 4 shows the new key.
I open HKEY_CURRENT_USER\Software\Hyperionics and click Registry, Save Key to copy the data in the Hyperionics key to my hard disk. (Where you save the file doesn't matter as long as you remember where it is.) Next, I select the HKEY_LOCAL_MACHINE\Policy\Users\.default\Software key that I created and click Registry, Restore. A Restore Key dialog box appears; I use its Browse function to find the Hyperionics file on my hard disk. I select the file and confirm my choice, and regedt32 prompts me with a dialog box for an additional confirmation. Screen 5 shows this dialog box, which warns you that the data you are restoring will overwrite the values in the current key. I click OK to continue, and regedt32 transfers all the information from the HKEY_CURRENT_USER Hyperionics key to the default profile's new HKEY_LOCAL_MACHINE Hyperionics key. The system policy then gives every user access to HyperCam.
Another Ntconfig.pol Procedure
In addition, you can edit the policy file to create custom templates that include REG_MULTI_SZ entries. "Map Your Drives with Policies" in the March 1998 Windows NT Magazine Reader to Reader column shows how to write a policy that creates network drive connections. If you have several systems with the same configuration and directory structure, you might want to give them access to the same shares. You can't write a policy in SPE to make the shares available because NT stores your shares as MULTI_SZ Registry entries. To create a policy for your shares, you need to edit the ntconfig.pol file directly.
Because regedt32 doesn't have copy and paste functions, select the HKEY_
LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares key on a system with the correct shares and click Registry, Save Key to save the key to a disk. Load ntconfig.pol into regedt32, and add a LanmanServer key to the HKEY_LOCAL_MACHINE\Policy\Computers\.default\SYSTEM\CurrentControlSet\Services key. Create a Shares key in the new LanmanServer key. (Making this change in the .default location will add these shares to all your systems. If you want to add them to only a few systems, you can add the LanmanServer and Shares keys to named computers by replacing .default in the HKEY_LOCAL_MACHINE Registry key with each computer's name.)
After you create the LanmanServer and Shares keys, select the new Shares key and click Registry, Restore. Open the file you saved to disk. NT will add all the shares, which are MULTI_SZ Registry entries, to the default profile in the ntconfig.pol file. When the designated computers receive the policy, NT will overwrite the systems' current shares with the shares in the policy.
Closing the Policy
After you use regedt32 to change ntconfig.pol, you need to unload the hive from regedt32 so that NT can use it as a policy file. Select the Policy key and click Registry, Unload Hive. NT will prompt you to save the changes. After you confirm the changes, NT will remove the hive from the Registry editor and save ntconfig.pol to its original location.
Procedure Limitations
When I demonstrate these procedures, people often ask me, "Why do you continue to write policy templates or use SPE profiles when you can edit the policy file directly?" I don't edit ntconfig.pol for all my policy changes because creating policies in this way has three limitations.
First, if you make changes to the policy through ntconfig.pol, you can't later use the SPE GUI to maintain those entries; you can change them only through regedt32. This limitation makes troubleshooting difficult. Be careful! Test your entries on a small scale before editing the policy file for a large network.
Second, when you create HKEY_LOCAL_MACHINE entries in the default profile for a program's HKEY_CURRENT_USER settings, users gain access to the software, but regedt32 doesn't create menu entries or desktop icons for it. To overcome this limitation, you must use SPE to create custom desktop and menu folders for the users whom you give access to a program.
Third, this procedure works extremely well for adding entries to the Registry, but removing Registry entries through ntconfig.pol is very difficult. When you deactivate the policy through SPE, the tool might make a special entry that removes a value or key. I recommend editing the policy file directly only to add keys, values, and settings--never to remove them.
Flexible System Policies
Editing the policy file directly through regedt32 offers you many options. I described procedures for the default user, but you can easily use the same techniques to add software access or restrict permissions for specific users or groups. Simply create keys for their individual or group policies instead of the default user profile.
Modifying NT policy files directly is a convenient addition to SPE's system policies functionality. The ability to use REG_MULTI_SZ entries, the flexibility to add large amounts of Registry data automatically, the option of setting user permissions in the Registry, and the ease of adding items to the policy file make editing system policies easier than ever.