DOCUMENT:Q185589 27-SEP-2001 [crossnet] TITLE :Guide To Windows NT 4.0 Profiles and Policies (Part 4 of 6) PRODUCT :Windows for Workgroups and Windows NT Networking Issues PROD/VER::4.0 OPER/SYS: KEYWORDS: ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Windows NT Server version 4.0 - Microsoft Windows NT Workstation version 4.0 - Microsoft Windows 95 ------------------------------------------------------------------------------- SUMMARY ======= This article is the fourth in a series of articles that provides information and procedures for implementing Microsoft Windows NT 4.0 Profiles and Policies on client workstations and servers. A whitepaper is available that contains all of this information and additional flowcharts, diagrams and examples and can be downloaded from the following web page: http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp For the other sections of this guide, please see the following article(s) in the Microsoft Knowledge Base: Q161334 Guide to Windows NT 4.0 Profiles & Policies Part 1 of 6 Q185587 Guide to Windows NT 4.0 Profiles & Policies Part 2 of 6 Q185588 Guide to Windows NT 4.0 Profiles & Policies Part 3 of 6 Q185590 Guide to Windows NT 4.0 Profiles & Policies Part 5 of 6 Q185591 Guide to Windows NT 4.0 Profiles & Policies Part 6 of 6 MORE INFORMATION ================ Windows NT Server Operating System White Paper Guide to Microsoft Windows NT 4.0 Profiles and Policies Copyright 1997 Microsoft Corporation. All rights reserved. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Microsoft, the BackOffice logo, MS-DOS, Windows, and Windows NT are registered trademarks of Microsoft Corporation. Other product or company names mentioned herein may be the trademarks of their respective owners. Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA 0997 SYSTEM POLICY - AN INTRODUCTION =============================== A System Policy is a set of registry settings that defines the computer resources available to an individual or to a group of users. Policies define the various facets of the desktop environment that a system administrator needs to control, such as which applications are available, which applications appear on the user's desktop, which applications and options appear in the Start menu, who can change their desktops and who cannot, and so forth. System policies can be implemented for specific users, groups, computers, or for all users. You create system policies with the System Policy Editor. The System Policy Editor is a graphical tool provided with Windows NT Server 4.0 that allows you to easily update the registry settings to generate the correct environment for a particular user or group of users. The System Policy Editor creates a file that contains registry settings which are then written to the user or local machine portion of the registry database. User Profile settings that are specific to a user who logs on to a given workstation or server, are written to the registry under HKEY_CURRENT_USER. Likewise, machine-specific settings are written under HKEY_LOCAL_MACHINE. When you apply a System Policy, the new policy overwrites the existing registry settings, thus giving you, as system administrator, the ability to set restrictions for the client machine and user. When a user logs on to a Windows NT 4.0 computer, the user's profile is loaded first and then the System Policy is downloaded. Any registry settings that you have reconfigured, whether these are machine-specific changes or are specific to the user logging on, are changed before the user receives control of the desktop. Note that System Policy changes are not dynamic; if you make a change to the policy, affected users must log off and log back on so that the new policy can be downloaded and applied. With a properly implemented policy, you can customize the user's environment to your specifications, despite the user's preferences and regardless of where he or she logs on. The settings available in the System Policy Editor provide a variety of options for managing the user environment. For a detailed list of these options, see the section "Registry Keys Modified by the System Policy Editor Default Templates." System Policy Files ------------------- Policies can define a specific user's settings or the settings for a group of users. The resulting policy file contains the registry settings for all users, groups, and computers that will be using the policy file. Separate policy files for each user, group, or computer are not necessary. If you create a policy that will be automatically downloaded from validating domain controllers, you should name the file Ntconfig.pol. As system administrator, you have the option of renaming the policy file and, by modifying the Windows NT-based workstation, directing the computer to update the policy from a manual path. You can do this by either manually changing the registry or by using System Policy. This path can even be a local path such that each machine has its own policy file, but if a change is necessary to all machines, this change must be made individually to each workstation. When a user of a Windows NT 4.0-based workstation logs on, if the Windows NT 4.0-based machine is working in Automatic mode (which is the default), the workstation checks the NETLOGON share on the validating domain controller (DC) for the Ntconfig.pol file. If the workstation finds the file, it downloads it, parses it for the user, group, and computer policy data, and applies it if appropriate. If a user logs on to a machine that has a computer account in a resource domain, the search for the Ntconfig.pol file is redirected to the validating domain controller in the account domain. In this situation, the Windows NT 4.0-based workstation has a secure communication channel established to a domain controller of the resource domain. The Windows NT-based workstation sends the user's logon request over this communication channel, and expects a response the same way. The domain controller in the resource domain receives this request, forwards it to a domain controller in the user's account domain, and waits for a response. Once the domain controller in the resource domain receives this response from the account domain's DC, it returns the authentication request to the client machine, including the validating domain controller's name from the account domain. The Windows NT-based workstation now knows where to look for the Ntconfig.pol file. Policy Replication ------------------ If you implement a System Policy file for Windows NT users and computers and you intend to use the default behavior of Windows NT, be sure that directory replication is occurring properly among all domain controllers that participate in user authentication. With Windows NT, the default behavior is for the computer to check for a policy file in the NETLOGON share of the validating domain controller. If directory replication to a domain controller fails and a Windows NT-based workstation does not find a policy file on that server, no policy will be applied and the existing settings will remain, possibly leaving the user with a nonstandard environment or more capabilities than you want that particular user to have. How Policies Are Applied ------------------------ Once located, policies are applied as follows: - If the policy file includes settings for the specific user account, those are applied to the HKEY_CURRENT_USER registry key. Other group settings are discarded, even if the user is a member of the group, because the user settings take precedence. - If a user-specific policy is not present, and Default User settings exist, the Default User settings are applied to the HKEY_CURRENT_USER registry key. - If no user specific settings are present, and group settings exist, the user's group membership in each of those groups is checked. If the user is a member of one or more groups, the settings from each of the groups- starting with the lowest priority and continuing through the highest priority-are applied to the HKEY_CURRENT_USER key in the registry. NOTE: If a setting is ignored (gray) in the group settings, but the same setting is marked as enabled or disabled in the Default User settings, the Default User setting are used. The Default User settings take precedence over only those settings that are ignored in the group settings. - If the policy file includes settings for the specific computer name, these are applied to the HKEY_LOCAL_MACHINE registry key. Otherwise, the Default Computer settings are applied. This process is independent of the user account for the user who is currently logged on. All users receive these settings when they use this computer. NOTES: - Group policies do not operate in a NetWare only environment, because Windows NT checks for Windows NT global groups only, not NetWare groups. - If an administrator logs on, a policy is in effect, no explicit settings exist for the administrative account, and the Default User settings are present, the administrator will receive the settings of the Default User. Administrative accounts are not exempt from policies. This should be a key factor to consider when implementing policies. The System Policy Editor provides a hierarchical Group Priority dialog that helps you see and manage the order in which group policies are applied. The next illustration shows the dialog and explains these priorities. Additional Implementation Considerations ---------------------------------------- Although a properly implemented policy can simplify system administration in the long term, such policy requires careful planning. Before you implement system policies, consider the following: - Would administration be simplified by defining group settings rather than creating settings for individual users? - Where are the computers located in your network? Is geographic location an important aspect of your network's design-for example, is your network distributed over a large geographic area? If so, computers from a certain locale may benefit from retrieving policy files from a machine that is close at hand, as opposed to using a domain controller that may not be nearby. - What type of restrictions do you want to impose on users? - Will users be allowed to access locally installed common group applications, or will these be overridden by administrator-defined program groups, desktop icons, Start menu programs, and so forth? - What other options are available if you simply want to restrict access to a specific icon or file? Would modifying NTFS permissions be more effective? - Will you be controlling computer-specific settings only, and not user settings? If after considering these issues, you conclude that System Policies will simplify administration of your system, use the System Policy Editor to create the appropriate individual and/or group policies, as explained in the next section. THE SYSTEM POLICY EDITOR ======================== The System Policy Editor is a graphical tool that allows you to easily update the registry settings to implement a System Policy. The System Policy Editor is included with Windows NT Server 4.0, but you can install it on Windows NT Workstation-based machines and on Windows 95-based machines as well. Note that a policy file is valid only for the platform on which it was created. For example, if you run Poledit.exe on a Windows 95-based machine, and you save the policy file, the file will be written in a format that can be interpreted by Windows 95-based machines only. The same is true when you create policy files on Windows NT-based machines. As a result, Windows 95 and Windows NT policy files are not interchangeable. After you complete the installation, the administrative tools group includes the System Policy Editor. Installing the System Policy Editor on a Windows NT Workstation --------------------------------------------------------------- You have two options when installing the System Policy Editor on a Windows NT Workstation-based computer. You can - Run the Setup.bat file from the Windows NT 4.0 CD-ROM \Clients\Svrtools\Winnt directory, or - Copy the System Policy Editor executable, Poledit.exe, and template files to the workstation. The template files have an .adm extension, and are located in the %systemroot%\INF directory, which is hidden by default. Installing the System Policy Editor on a Windows 95 Computer ------------------------------------------------------------ When you install the System Policy Editor on a Windows 95-based computer, the installation process modifies the Windows 95 registry to allow system policies to function correctly. You can install the policy editor from the Windows 95 Upgrade or Retail compact disc, or you can install the editor that ships with Windows NT Server 4.0. To install the System Policy Editor from the Windows 95 compact disc: 1. Insert the Windows 95 Upgrade compact disc in your CD-ROM drive. 2. Open Control Panel, and click Add/Remove Programs. 3. Click the Windows Setup tab, and select Have Disk. 4. Browse to locate the directory x:\Admin\Apptools\Poledit\ (where x is drive A through Z) on the Windows 95 compact disc. 5. Select both Group Policies and the System Policy Editor, and then click OK to Install. It is important that you run the setup program as described above. Undesirable results will occur if you merely copy the Policy Editor and related files to the Windows 95-based computer. To install the System Policy Editor from a Windows NT 4.0 Server ---------------------------------------------------------------- 1. Copy the Poledit.exe file from the Windows NT Server 4.0 to the \windows directory of the Windows 95-based machine. 2. Copy the Common.adm and Windows.adm files from the Windows NT 4.0-based server to the \windows directory of the Windows 95-based machine. 3. Create a shortcut to the System Policy Editor executable (Poledit.exe, located in the \windows directory of the Windows 95-based computer). Updating the Registry with the System Policy Editor --------------------------------------------------- The System Policy Editor allows you to easily update the registry settings to generate the correct environment for a particular user or group of users. You can use the System Policy Editor in two ways: - You can open the local registry through the System Policy Editor, and change the settings for the local user and computer. - You can modify an existing policy file or create a new one to contain the settings that you want to enforce on a per user, per computer, or combined user/computer basis. When you open the System Policy Editor in registry mode, you can modify the registry of the local computer without having to use Regedt32.exe or Regedit.exe. However, you can modify only those values exposed by the templates; the System Policy Editor does not give you access to the entire registry. SYSTEM POLICY EDITOR TEMPLATE (.ADM) FILES ========================================== The System Policy Editor uses administrative (.adm) files to determine which registry settings can be modified. An .adm file is a hierarchical template, and consists of categories and subcategories that dictate which settings are available through the user interface. An .adm file contains the registry locations where changes should be made for a particular selection, additional options for a particular selection, restrictions, and in some cases, the default value for a selection. When you run the System Policy Editor and select Policy Template from the Options menu, a window similar to the one shown below appears. This window displays the names of the .adm files that are currently being used. If you need to make changes to custom applications, for example, you can add a template to this list. To ensure that the system uses the latest administrative information, the System Policy Editor reads the custom .adm files each time it starts. For detailed instructions when creating .adm files, see the section "Creating Your Own Custom .Adm File," later in this document. NOTE: The option to Add or Remove will be grayed out if there is a policy file currently open. Close the file in use and then change the template configuration. CONFIGURING POLICY SETTINGS =========================== The configuration options available to you fall into a tree structure, which is determined by the layout of the .adm file. By navigating through these options, you can select a mode that determines the action that will be taken when the policy file is applied. Policies are applied as follows: - If the box is checked, it is implemented. When the user next logs on, the user's computer conforms to the policy. If the option was checked the last time the user logged on, Windows NT makes no changes. - If the box is cleared, the policy is not implemented, and if the settings were previously implemented, they are removed from the registry. - If the box is grayed, the setting is ignored and unchanged from the last time the user logged on. Windows NT does not modify this setting. The grayed state ensures that Windows NT provides quick processing at system startup because it does not need to process each entry every time a user logs on. NOTE: When you decide whether the value should be checked or cleared, be careful of the terminology of the setting or unexpected results may occur. For example, the Don't save settings at exit option, when checked, does not allow settings to be saved. If you clear the checkbox, the settings can be saved. When you select an option, the pane below it contains other configurable items that relate to the setting you modified, as well as information about the option you selected. When administering System Policies, if you specify paths for particular options such as wallpaper, ensure that the paths are consistent across all workstations that will receive the policy file. SETTING FOLDER PATHS BACK TO DEFAULTS ===================================== If you create a policy file and then change the path to any of the custom shared folders or custom user-specific folders, the change overrides the default setting established in the .adm file. For example, by default a user's program folder path is %USERPROFILE%\Start Menu\Programs. If the policy file is not modified from the default, this value is not changed for the client computer. However, you can modify this value to point to a server location that contains different shortcuts. To do this, click the option in the System Policy Editor, and specify the path to the folder containing the shortcuts. Once this change is applied, the user will receive the new shortcuts. Suppose, however, that you want to restore the user's environment to the state it was in before the change was made. To do this, follow the procedure described next. To restore the defaults: 1. Open the policy file, and click the option to clear the check box. 2. Save and close the policy file. 3. Reopen the policy file, and click the option to re-enable it. The original setting should be displayed, pointing to the user's local machine. NOTE: Be sure to complete all steps; completing Steps 1 and 2 only results in an empty Programs folder on the client machine. CREATING A SYSTEM POLICY ======================== Before you create a System Policy, decide which settings will be enforced and how the settings will be grouped. To create a new System Policy: 1. On a Windows NT Server-based machine in the domain where the policy file will apply, open the System Policy Editor. From the Start menu, click Programs, then click Administrative Tools (Common), then click System Policy Editor. 2. From the File menu, click New Policy. 3. The Default Computer and Default User icons will be displayed. Click the user, computer, or group to be modified. NOTE: If you need to add a user, group, or computer, you can copy and paste the settings without having to manually go through each of the entries and make selections. For example, if you have made modifications to User1 and want to create a similar profile for another user (User2), select User1, then from the Edit menu, click Copy. Select User2, then from the Edit menu, click Paste. Make any changes specific to User2 and save your changes. You will be prompted to verify your changes, and then the settings will be applied. When you add users or computers to the policy file, they automatically assume the properties of the icons Default User or Default Computer respectively. 4. Make changes to the options desired. For more information on each option, see the portion of this guide titled "Registry Keys Modified by the System Policy Editor Default Templates." 5. From the File menu, click Save As and save the policy file with the appropriate name: - If workstations will be set to Automatic mode, use the file name NTconfig.pol. - If workstations will be set to Manual mode, use the name of your choice. 6. If workstations will be set to Automatic mode, place the file in the NETLOGON share of each of the domain controllers that will be performing authentication. To simplify this process, you can use directory replication from Windows NT to replicate the file to the other domain controllers. If you use replication and later make changes to the file, the modified file will be duplicated across validating machines automatically. Windows NT-based workstations, by default, are set to download the policy file in Automatic mode. If you modify the setting to specify manual update and to point to a specific machine, you must inform the workstation about this location change. There are two ways to do this: - Place the policy file in the location specified for manual updates, but maintain a policy file in the NETLOGON share that points to the manual path. Then, leave the Windows NT-based workstation in the default Automatic mode. When the policy file is first downloaded this change will be made, and at next logon and every logon thereafter, Windows NT will go to the new location for policy file updates. - Visit each Windows NT-based workstation either remotely or locally and make the required registry change to point to the new location. (Depending on the number of workstations affected, this could be very time consuming.) 7. Log on to the Windows NT-based workstation to download and enact the policy. Creating Alternate Folder Paths ------------------------------- You may need to create shared folders for groups of users who need a common set of tools and shortcuts. Windows NT 4.0 System Policies allows you to create such shared folders. To create shared folders and alternate folder paths: 1. On a specific server, create a folder that contains shortcuts to network applications or to locally installed programs. If you are creating application shortcuts that will point to local paths on Windows NT machines, refer to the section "Setting Up Shortcuts for Server-based Profiles." 2. Share the folder. 3. Using the System Policy Editor, under computername or Default Computer, select the option Custom Shared Folders, then select Custom Shared Program Folder. 4. Enable this option. By default the local All Users folder for the workstation will be used, but you can replace the path to point to the folder that you created in Step 1 and 2. 5. Save the policy file. When the user logs on, the policy file will be parsed for this information and will replace the common groups from the local machine with the shortcuts, applications, and so forth, from the folder that you created earlier. NOTE: This can be done per user for personal program groups and can also be done for other folder settings such as the startup group, Start menu, and desktop icons. SETTING UP SHORTCUTS FOR SERVER-BASED PROFILES ============================================== You may notice that shortcuts created on any computer automatically embed a universal naming convention (UNC) path for the .lnk file, such as \\machine\admin$. This embedded UNC in the link can be a problem when it is copied to a server and used in a server-based profile. By default, such links are resolved to the original location of the file (the absolute path) before any other path is used (these other paths are referred to as secondary or relative paths). In this case, the UNC path to the original file is always reachable, which prevents the link from being resolved via a local path. As a result, the user trying to execute the shortcut will be asked for the administrator's password for the computer on which the link was created. This problem was corrected in the latest Microsoft Windows NT 4.0 U.S. Service Pack. After you install the service pack, you can work around the problem by modifying the registry as explained next. To resolve links correctly: 1. Open Registry Editor (Regedit.exe). 2. Go to the following key: HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Policies \Explorer 3. Add the following DWORD value by clicking Edit, New, DWORD value: LinkResolveIgnoreLinkInfo 4. Once entered, double-click this value and set the Value data to 1. DEPLOYING POLICIES FOR WINDOWS NT 4.0 MACHINES ============================================== By default, a Windows NT 4.0-based workstation checks the NETLOGON share of the validating domain controller for the user's logon domain. It is therefore critically important that replication of the Ntconfig.pol file take place among the domain controllers performing authentication. If a Windows NT 4.0-based workstation does not locate the policy file on its validating domain controller, it will not check any others. You have another option when enforcing policies. The UpdateMode registry setting, configurable through the System Policy Editor, forces the computer to retrieve the policy file from a specific location (expressed as a UNC path), regardless of the user who logs on. To retrieve the policy file from a specific location: 1. Open either the specific machine policy or the Default Computer policy, and navigate through the Network category and System policies update subcategory to reach the Remote update option. 2. Check the Remote update box. 3. In the Update mode box, select Manual (use specific path). 4. In the Path for manual update box, type the UNC path and file name for the policy file. 5. Click OK to save your changes. The first time the workstation is modified locally via the System Policy Editor or receives a default System Policy file from the NETLOGON share of a domain controller, this location is written to the registry. Thereafter, all future policy updates use the location you specified manually. This is a permanent change until the policy file resets the option to Automatic. The Windows NT 4.0-based computer will never again look at a domain controller to find a policy file until you either change the instruction in the local registry or modify the policy file in the location specified by the manual path to set the mode back to Automatic. DEPLOYING POLICIES FOR WINDOWS 95 MACHINES ========================================== When creating a system policy file for a Windows 95-based client, you must first install the System Policy Editor on a Windows 95-based computer so that you can create the policy (.pol) file. You cannot run the System Policy Editor on a Windows NT 4.0-based server to generate a .pol file for Windows 95-based clients because a policy file is valid only for the platform on which it was created. For procedures when installing the System Policy Editor on a Windows 95-based computer, refer to the section "Installing the System Policy Editor on a Windows 95 Computer" earlier in this document. After you have created the .pol file, you can enable a Windows 95-based computer to look for and accept system policies as is described below. To deploy policies for a Windows 95-based computer: 1. Open the Control Panel, and click Passwords and then User Profiles. 2. To enable User Profiles, select Users can customize and then click OK. 3. Check the UpdateMode value in the following registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Update If this value is 0, policies will not be applied. If this value is 1, the Automatic Policy mode is in effect and when the user is validated on the domain, the validating domain controller's NETLOGON share will be checked for the existence of the Config.pol file. If this value is 2, the Manual Policy mode is in effect, and when the user is validated on the domain, the Windows 95-based machine will check the path specified in the value NetworkPath for the existence of the Config.pol file. Note that the default mode for a Windows 95-based machine is Automatic. 4. Restart the computer and have the user log on. The policy file will be downloaded from the configured location and applied. MODIFYING POLICY SETTINGS ON STAND-ALONE WORKSTATIONS ===================================================== If you need to modify settings of a Windows NT 4.0-based workstation user who is not a member of the domain and thus will not be able to use the policy file located on the domain, you have three options available to you: - You can create a policy file for stand-alone workstations where users log on locally, or - You can change policy settings remotely, or - You can change policy settings locally. Procedures for each option are described next. Note that you must have administrator rights to the stand-alone workstations in question. To Create a Policy File for Stand-alone Workstations ---------------------------------------------------- 1. Log on as administrator, and create a policy file that includes Computer and User objects with appropriate settings for the computer and users respectively. The user objects may include the Default User or user accounts from the local workstation, but global group objects will be ignored if added to the policy file. Windows NT recognizes machine- specific policy settings for the computer if those are specified in the policy file. 2. Place the policy file in a secure directory on the stand-alone computer or on a network share to which the user has at least Read permissions. 3. In the workstation registry, locate the UpdateMode value in the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update 4. Update the data to a hex value of 2. 5. In the same registry subkey, modify the NetworkPath value with the local or UNC path where the policy file resides. If this path does not exist, add it as a data type of REG_SZ. For example, if the policy file is named Ntconfig.pol and is placed in the root directory of Windows NT, NetworkPath should contain the path c:\Winnt\Ntconfig.pol. 6. Have the user log on to the workstation. Windows NT will read the policy file specified by NetworkPath and then apply the appropriate policy to the computer or to the user. NOTE: UNC paths may be used in the NetworkPath value. This is beneficial to those administrators who want to centralize the policy file in use. The ability of Windows NT to take advantage of and apply System Policies to local workstation users is not operable in Service Pack 3, but will be available in Service Pack 4 and future service packs. This does not affect the retail build of Windows NT 4.0 and Service Packs 1 and 2, where this feature is operable. To Change Policy Settings Remotely ---------------------------------- 1. Log on as administrator, open the System Policy Editor, and from the File menu, select Connect. 2. Type the computer name of the workstation to be modified, and click Enter. A dialog will appear displaying the user name of the currently logged on user for whom the changes will apply. If the user is not currently logged on, click Cancel. (The user must be logged on for the changes to take effect.) 3. If the user is logged on, click OK. 4. The icons Local Computer and Local User will be displayed. 5. Modify these just as you would modify a normal policy file. Save your changes. The next time the user logs on, the changes made to the computer and the user settings will be in effect on the remote machine. To Change Policy Settings Locally --------------------------------- 1. Log on as an administrator, and copy the Poledit.exe, Common.adm, and Winnt.adm files to the Windows NT-based workstation where the changes for the computer or user need to be made. 2. Log on with administrative permissions as the user for whom the modifications will apply. 3. Open Poledit.exe and load the templates that were copied to the local computer. 4. From the File menu, select Open Registry. 5. The icons Local Computer and Local User will be displayed. 6. Modify these just as you would modify a normal policy file. Save your changes. The next time the user logs on, these changes will be in effect. 7. Close the System Policy Editor and remove this tool from the workstation by deleting the Poledit.exe file and any .adm files used. These changes modify the registry entries that control the behavior of Windows NT on the target computer. A policy file is not created when this procedure is used. This procedure is the same for Windows NT Workstation 4.0 and Windows NT Server 4.0. CREATING A CUSTOM .ADM FILE =========================== The content of this section is also documented in the Windows 95 Resource Kit and the Windows 32-bit Software Developer's Kit, which are available on the Microsoft Developer's Network or through Microsoft Sales. This section refers extensively to the following .adm files: - Common.adm-This contains registry settings common to both Windows NT 4.0 and Windows 95. - Winnt.adm-This contains registry settings specific to Windows NT 4.0. - Windows.adm-This contains registry settings specific to Windows 95. To Create A Custom .Adm File ---------------------------- 1. Create a backup copy of the Winnt.adm file in the %systemroot%\ Inf directory. 2. Use a text editor to open the Winnt.adm file. The first entry of this file is CLASS xxxx, where xxxx could be either: - MACHINE = This section includes all entries available in the Local Computer/DefaultComputer icon. - USER = This section includes all entries available to modify user- specific settings. These are the only two classes that are valid within the System Policy Editor. The System Policy Editor checks the syntax of each .adm file when the files are loaded, and displays a message if any errors are found. 3. Choose the CLASS in which you want your custom entries to appear. 4. Create categories by using the keyword CATEGORY followed by a space and !!variable. The System Policy Editor requires that anything preceded by !! must have a string defined in the [strings] section of the .adm file. This allows the editor to use variables to define long strings of text that will appear in the user interface a single time, even if these strings are used in multiple locations in the .adm file. For example, to open a category you would use: CATEGORY !!MyNewCategory To close the category after filling in the options, you would use: END CATEGORY ; MyNewCategory These can be nested to create sub-categories as follows: CATEGORY !!FirstCategory CATEGORY !!SecondCategory CATEGORY !!ThirdCategory ... ... END CATEGORY ; ThirdCategory END CATEGORY ; SecondCategory END CATEGORY ; FirstCategory Be sure to specify the text for the variables you used above. In this case, in the [strings] section of the .adm file, you would need to include: FirstCategory="My First Category" SecondCategory="My Second Category" ThirdCategory="My Third Category" 5. Within each category, define the registry key that will be modified. To do this, use the keyword KEYNAME followed by the registry path to the key that contains the value you want to change. Note that due to the CLASS you are in, you do not need to specify HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER. For example, you can use: KEYNAME System\CurrentControlSet\Services\LanManServer\Parameters 6. Identify the policy that specifies which options the user can modify. Use the keyword POLICY for this, followed by !!variable. For example: POLICY !!MyFirstPolicy Be sure to define MyFirstPolicy in the [strings] section of the .adm file. Complete the policy specifics, and finish with an END POLICY statement. 7. Define the options available within the policy. ?Use the keyword VALUENAME to identify the registry value that an administrator can modify. For example: VALUENAME MyFirstValue Remember that the VALUENAME needs to be within a PART if the option is selected within the lower pane of the System Policy Editor (see the discussion of PART and the code example below). If not specified otherwise, the value will be written in the following format when any administratory checks or unchecks the option: Checked: REG_DWORD with a value of 1 Unchecked: Removes the value completely Other options can specify what the user selects from and what gets written to the registry. - Use the keyword PART to specify options, drop-down list boxes, text boxes, and text in the lower pane of the System Policy Editor. PART is similar to CATEGORY, and uses the syntax: PART !!MyVariable FLAG ... END PART where FLAG is one or more of the following: - TEXT -Displays text only, for example: PART !!MyPolicy TEXT END PART - NUMERIC -Writes the value to the registry with data type REG_DWORD, for example: PART !!MyPolicy NUMERIC VALUENAME ValueToBeChanged END PART - DROPDOWNLIST -Displays a list box of options to choose from, for example: PART !!MyPolicy DROPDOWNLIST VALUENAME ValueToBeChanged ITEMLIST NAME "First" VALUE NUMERIC 1 NAME "Second" VALUE NUMERIC 2 NAME "Third" VALUE NUMERIC 3 NAME "Fourth" VALUE NUMERIC 4 END ITEMLIST END PART - EDITTEXT -Writes the value to the registry with data type REG_SZ, for example: PART !!MyPolicy EDITTEXT VALUENAME ValueToBeChanged END PART - REQUIRED -Generates an error if the user does not enter a value, for example: PART !!MyPolicy EDITTEXT REQUIRED VALUENAME ValueToBeChanged END PART - EXPANDABLETEXT-Writes the value to the registry with data type REG_EXPAND_SZ, for example: PART !!MyPolicy EDITTEXT EXPANDABLETEXT VALUENAME ValueToBeChanged END PART - MAXLEN -Specifies the maximum length of text, for example: PART !!MyPolicy EDITTEXT VALUENAME ValueToBeChanged MAXLEN 4 END PART - DEFAULT -Specifies the default value for text or numeric data, for example: PART !!MyPolicy EDITTEXT DEFAULT !!MySampleText VALUENAME ValueToBeChanged END PART or PART !!MyPolicy NUMERIC DEFAULT 5 VALUENAME ValueToBeChanged END PART - MIN and MAX -These specify the lowest and highest valid values respectively, for example: PART !!MyPolicy NUMERIC MIN 100 MAX 999 DEFAULT 55 VALUENAME ValueToBeChanged END PART - Use the keywords VALUEOFF and VALUEON to write specific values based on the state of the option, for example: POLICY !!MyPolicy KEYNAME .... VALUENAME ValueToBeChanged VALUEON "Turned On" VALUEOFF "Turned Off" END POLICY or POLICY !!MyPolicy KEYNAME .... VALUENAME ValueToBeChanged VALUEON 5 VALUEOFF 10 END POLICY 8. Save and test your file. Note that if you modify an .adm file while the System Policy Editor application is running, you will need to reload the file. From the Options menu, select Policy Template, and press OK. This reloads the structure, and your new entries will be available. (You do not need to perform this step if you modify a file before starting the System Policy Editor; the reload is done automatically each time the System Policy Editor starts.) CONFIGURING SYSTEM POLICIES BASED ON GEOGRAPHIC LOCATION ======================================================== You may choose to enforce certain environment settings based upon geographic site location or vicinity. At least two methods are available to do this. - Generate a System Policy that contains settings for specific computers. In each of the machine-specific settings, configure the Remote Update path to a specific regional server that will be maintaining the regional System Policy file. When the user logs on at the Windows NT-based workstation for the first time, because the default mode is Automatic, the workstation will check the validating domain controller for a policy file. The policy file it finds will point the policy update configuration to another server. Note, however, that this does not work for the first logon. When the user next logs on, Windows NT checks the remote path and continues to use that path until the System Policy file on the remote server directs otherwise. - Manually configure each of the workstations in a given region or site to use a remote update path, and change the remote update mode from the default of Automatic to Manual. CLEARING THE DOCUMENTS AVAILABLE LIST ===================================== As an alternative to removing the Documents option from the Start menu, you can set and clear the documents available by clearing the MRUList value in the registry. Use this registry key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Explorer\RecentDocs Value: MRUList Note that you should not delete the value; instead, replace MRUList with a blank string. BUILDING FAULT TOLERANCE FOR CUSTOM SHARED FOLDERS ================================================== If you want to create a user environment that includes a Custom Shared Programs Folder and a Custom Shared Desktop, you need to place the source folders for these shared items on a central server for all users to access. However, this involves some degree of risk if the server is unavailable. If that occurs, the user's Programs menu and desktop would not contain the appropriate folders, shortcuts, and files. To build fault tolerance into this configuration, you can take advantage of the distributed file system (Dfs) available for the Windows NT Server 4.0 operating system platform. Dfs, which runs as a service, can provide a share that will refer the client to multiple servers for the same path. For example, on a Dfs server, the administrator has defined that users connecting to the UNC path \\Dfsserver\Dfsshare\Customfolder, will be returned a response with three different servers, \\Server1\Customerfolder, \\Server2\Customerfolder, and \\Server3\Customerfolder, all of which contain the same data. The client machine, which can be either a Windows NT- based 4.0 machine or a Windows 95-based machine with the Dfs client software, randomly selects one of these servers and uses that path to generate the custom shared folders for the user. If one of the servers is unavailable, the client has the other two servers to select from. Note that the Dfs host server must be running for this fault tolerant structure to work. (Although Dfs software currently supports a single host server, Microsoft is developing a fault-tolerant version of Dfs for a future release of Windows NT.) Additional query words: wpaper ====================================================================== Keywords : Technology : kbWinNTsearch kbWinNTWsearch kbWinNTW400 kbWinNTW400search kbWinNT400search kbWinNTSsearch kbWinNTS400search kbWinNTS400 kbWin95search kbZNotKeyword3 Version : :4.0 Issue type : kbinfo ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2001.