WindowsDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


AddThis Social Bookmark Button

News -- Windows System Policy Editor Top 10 Tips

by Stacey Anderson-Redick
06/01/2000

The system policy editor is a powerful, yet rarely used network tool. Administrators of Windows 9x or Windows NT4 workstations--especially administrators of shared workstations, like those in public libraries, schools, and hospitals--would find policies helpful. In these situations system policies can offer consistent desktops, unavailable Control Panel applets, restricted software packages, and network-wide application settings.

I took my Top 10 list from the questions most frequently asked by visitors to my web page.

  1. Locally enable remote update on the workstation to allow it to download the policy file.

    To use system policies, a Windows 9x workstation must have user profiles enabled. However, for the workstation to download the policy file at all from the network, each Win9x and WinNT workstation must have the Computer policy "Remote update" enabled (checked) in its local registry. If this policy is disabled (cleared), Windows will neglect to search the network for a system policy file.

    Use Regedit.exe or a similar registry editing program to check that the registry key HKLM\System\CurrentControlSet\Control\Update has a hex value of 1 for automatic remote update or a hex value of 2 for manual remote update. A value of 0 will completely disable remote update, and consequently the policy file will not download. If you would rather use the SPE itself in local registry mode, the "Remote update" Computer policy can be set using the admin.adm, common.adm or windows.adm templates, and is found in the category called Network.

  2. Exclude a specific workstation (and its users) from the policy file by locally disabling remote update.

    In certain circumstances, you may not want the users of a particular workstation to be affected by any system policy. The easiest way to accomplish this is to disable the policy "Remote update" in the local registry by setting the appropriate registry key (See tip #1.) to a hex value of 0. After rebooting, this workstation and its users will be effectively excluded from the system policy file since the policy file will no longer be downloaded.

  3. Create, edit and save the policy file using the same platform for which it is intended.

    To be used on a Windows NT workstation, the policy file must be created and saved on an NT4 workstation or NT4 server, and it must be named ntconfig.pol. To be used on a Windows 9x workstation, the policy file must be created and saved on a Windows 9x workstation, and it must be named config.pol. Make sure you create and save the policy file while logged on as a member of the administrator group (Windows NT and Windows 2000 domains) or as a user with administrator privileges or supervisor rights to the system root (NetWare).

  4. For automatic remote update to work correctly, save the policy file to the appropriate network location.

    If the policy file is not in the expected network location, Windows will simply stop looking for it. Using automatic remote update in a Windows 2000 domain, the policy file should be saved to the Netlogon share (%systemroot%\sysvol\DomainName\scripts) of any domain controller (DC). In a Windows NT4 domain the policy file should be saved to the Netlogon share (%systemroot%\winnt\system32\repl\import\scripts) of all validating DCs. On a NetWare network, the policy file should be saved to the sys:\public directory of the preferred server.

  5. To avoid conflicts between the local workstation and the policy file, choose the proper policy setting.

    Each system policy has three possible settings: checked (enabled), cleared (disabled) and greyed (ignored). It is important to note that indiscriminately setting all template options to either the cleared or checked positions may remove required values from the local workstation's registry. For example, setting the Computer policy "Workgroup" (found in the windows.adm template, in the category "Microsoft Client for Windows Networks") to the cleared position will actually delete the workgroup name entirely from the local registry. This will cause the following error message to be displayed at boot up:

    The following error occurred while loading the device VNETSUP: Error 6102: The string specified by the WORKGROUP keyword in the registry was not found.

    Although resetting this policy to the greyed position would allow it to be ignored, choosing the greyed setting would not replace the original registry value. Once a registry entry such as this is removed, it must be manually reset: in this case, either through the Network control panel applet or through a Computer policy.

  6. To reduce boot up time, use load-balancing on Windows 9x workstations that are members of an NT domain.

    If a Windows 9x workstation (using automatic remote update) has the Computer policy "Load balancing" disabled, only the primary domain controller (PDC) will be checked for the policy file. Depending on the location of the PDC, this could take quite some time. With load balancing enabled, the policy file can be downloaded from any validating domain controller. This policy can be found by scrolling down through the "Remote update" policy options (See tip #1.).

  7. DOS-based applications can be added to the allowed programs list by including the associated BAT or PIF filename.

    To add DOS-based applications to the User policy "Only run allowed Windows applications", you must enter either an associated BAT or PIF filename. (Do not add the full pathname.) For example, the list of allowed applications should look something like this:

    Poledit.exe
    Accpac.pif
    Cleanup.bat
    Winword.exe
    Iexplore.exe

    Note that if you do include a DOS application in this list, you must NOT enable the policy restriction "Disable MS-DOS prompt". To do so would restrict all DOS applications, and not simply the command prompt.

  8. Keep the Default User (DU) in mind when tracking down User policy conflicts.

    Remember that the DU policy is always applied first, even if the user has a specific User or Group policy. This means that for any specific Group or User policy option in the greyed position, the corresponding Default User policy may become active. For example, if Bob had the User policy "Disable MS-DOS prompt" in the greyed position, but the DU had this same policy in the checked position, the DU restriction would become active and Bob would consequently NOT have access to the MS-DOS prompt. If you are not using the DU, you can remove this possible source of policy conflicts by completely deleting it from your policy file.

  9. To keep the kids out of system areas, use the SPE at home on your standalone workstation.

    Although it only provides a minimal level of security, system policies can be used on a standalone Windows 9x workstation. In this case, User profiles must be enabled and the policy "Remote Update" must be set to Manual with the full pathname of the policy file specified (e.g. C:\Windows\config.pol). Using the Microsoft Family Logon in addition to a policy file can provide an adequate level of security in small office environments or for home users with young children.

  10. Reduce workstation boot-up time by keeping to a minimum the number of policies in the checked or cleared positions.

    To reduce the amount of time the workstation takes to import the registry changes indicated by the policy file, and as a result reduce workstation boot-up time, leave as many policies as possible in the greyed position. Since policies in the cleared and checked positions are processed, while those in the greyed position are skipped, a policy file consisting of mostly cleared and checked policies may take several minutes to process. However a policy file consisting of mostly greyed policies may only take seconds to download and merge with the local registry.

Stacey Anderson-Redick been a computer network administrator and technician for 12 years.

O'Reilly & Associates will release Windows System Policy Editor on June 23, 2000.