Using System Policies

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
On This Page

Setting the Standards for Your Organization
Working with the System Policy Editor
Security Settings and Related System Policies
Applying System Policies to Selected Users or Groups
Using Environment Variables in System Policies
System Policies and the Windows Registry

Setting the Standards for Your Organization

System policies help you control how your users work with Microsoft® Project 2002. You can use system policies to configure Microsoft Project to your own specifications. By using system policies, you determine which options are available to your users.

You create a system policy file and store the file on your server. When users log on to client computers, the system policy file is downloaded, and the system policies are enforced. If you need to change a policy, you update the policy file on the server, and the policy is automatically updated on each client computer the next time users log on.

Because of differences in how the Microsoft Windows® registry works, the Windows 98, Windows NT®, and the Windows 2000 and Windows XP operating systems require different formats for system policies. You can use the same System Policy Editor, however, to create policy files for client computers running under any of these operating systems.

System policies can only be enabled and enforced on computers connected to a network whose primary domain controller is a Windows NT server or Windows 2000 server.

Microsoft Project settings are stored in the project file itself. If a user opens an existing project file that has its own settings specific to Microsoft Project, these settings will not be changed through a system policy. Also, if a user changes Microsoft Project settings from the defaults specified by a system policy, these changes will persist for all new projects opened in that session (while Microsoft Project is still open). Only when the user exits Microsoft Project and restarts it will the system policy be used again as the default for new projects.

Unlike Microsoft Office, you cannot use system policies to enable or disable menu items or shortcut keys. You cannot use policies to control information specific to Microsoft Project in the Properties dialog box (on the File menu).

What Policies Can Do

Using system policies has several advantages. For instance, they enable an administrator to:

  • Specify settings for many dialog box items, including most of the options in the Options dialog box (on the Tools menu) or the Security dialog box (choose Tools, then Macro, then Security).
  • Set Windows Installer to always install applications with elevated privileges.
  • Disable patching of software by Windows Installer.
  • Customize the shared Startup folder for all users.

There are also specific policies to support many of the new Microsoft Project features listed here:

  • Improved security policies
  • The Project Guide pane
  • Save My Settings Wizard
  • Language settings
  • Collaboration
  • Corporate Error Reporting tool
  • Web Archives
  • Default encryption values for passwords
  • Policies can accept environment variables

Microsoft Project Policies

Microsoft Project has enhanced and improved system policies.

As part of the support for policies in Microsoft Project 2000 and Microsoft Project 2002, policies are consolidated in a separate subkey in the Windows registry: HKEY_CURRENT_USER\Software\Policies.

In Microsoft Project 2000, policies were stored in application-specific Software subkeys, such as HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\MS Project.

Safer Policies

In Windows 2000 and Windows XP, you can set an Access Control List (ACL) to lock the Policies subkey in the Windows registry. (The HKEY_CURRENT_USER policies branch is locked by default on Windows 2000). This step prevents users from changing a policy configuration setting by modifying security settings to nodes in their registry. Or, if you prefer, you can set security permissions manually using the regedt32 utility in both Windows 2000 and Windows NT 4.0 Service Pack 6a or later.

Working with the System Policy Editor

System policy files are created by using the System Policy Editor. The editor requires the loading of ADM templates created for use with the System Policy Editor from the Policy Template option (on the Options menu). When the ADM templates necessary for creating a policy file are loaded, selecting the New Policy option (on the File menu) creates two policy profiles. The Default Computer profile is used for controlling policies associated with the HKEY_LOCAL_MACHINE registry node, and the Default User profile is used for controlling policies associated with the HKEY_CURRENT_USER registry node.

After these two policy profiles are created, the administrator must make the necessary changes to enable and enforce policies on each computer connected to the network, or for each user who logs on to the network. Enabling a policy is accomplished by setting a leaf in the policy profile properties tree to selected (checked). You disable a policy by clearing the setting (unchecked). A setting that is dimmed is ignored by the System Policy Editor.

After creating a policy file, rename it and copy it to the NetLogon folder of the primary domain controller. If the policy is for use with Windows 98, name the file Config.pol. If the policy file is for operating systems based on Windows NT (including Windows 2000 and Windows XP), name the file NTConfig.pol. When the file appears in this folder, the domain controller automatically activates and enforces the policy settings. When users log on to the network, the system policy file is read and enforced at the user's computer. Changes to an existing policy are automatically propagated to users the next time they log on to the network.

Because of subtle differences in how the Windows registry works for the Windows 98, Windows Millennium Edition (Windows Me), Microsoft Windows NT, and the Windows 2000 and Windows XP operating systems, you need to create groups of policies to enforce for each operating system. The System Policy Editor can be used with all of these Windows operating systems. The Group Policy snap-in can only be used with Windows 2000 and Windows XP. See the Group Policy snap-in Help for information on how to activate policies using the Active Directory™ directory service in the Windows 2000 and Windows XP environments.

Using Policy Templates

Policy templates are the starting point for all policies. Find the ADM templates you need and then create a policy file based on the available policy settings within the templates. You can add several ADM files to the policy editor and set the entire configuration of a user's computer with just one policy file.

A policy setting is tri-state: if the policy is checked, it is enforced; if the policy is empty (clear), it is not enforced (turned off); if the policy is dimmed, it implies that the registry setting is ignored on the user's computer. In other words, if the policy is set to dimmed, and the policy is either set or not set on the user's computer, the registry entry is left alone on the user's computer.

By using the Group Policy snap-in available with Windows 2000 and Windows XP, you can give a policy one of three settings in the Properties dialog:

  • Not Configured
  • Enabled
  • Disabled

All of the system policies for an application are listed in the corresponding policy template (ADM file).

Microsoft Project Enforces System Policies

When you set a policy to be turned off for an element of an application, such as a menu command or toolbar button, that element appears dimmed in the user interface. Users will not be able to use or reset that option. With previous versions of Microsoft Project, users could change a setting back to enabled, even if the element had been turned off by system policies.

Microsoft Project now enforces and respects policy settings, even if a user happens to edit a registry setting on the fly. When Microsoft Project restarts, it reviews policies and reinforces settings, rather than waiting for the user to log on again and revalidate the policy settings.

Special Policy Configurations

The System Policy Editor allows you to create policies for unique situations. You can create policies for one user, one computer, or a group of users. If you need to enforce a set of policies for one user, you can create a policy that will be applied when the user logs on. You can also create specific policies for more than one user, user group, a computer, default computers, and default users within one policy file. See the System Policy Editor Help for more information on creating special policy profiles. See the Group Policy snap-in Help for more information on configuring policies for Windows 2000 and Windows XP.

See also

The System Policy Editor you should use to set policies for Microsoft Project is the same one that is included in the Office XP Resource Kit Toolbox.

For more information, see System Policy Editor and Templates in the Deployment and Administration Tools section of the resource kit toolbox.

Security is an important subject for today's businesses. The increase in malicious hacking of corporate computers has forced businesses worldwide to develop better methods of protecting their data and systems. As a way to help administrators enable the security features of Microsoft Project, Microsoft has created system policies that force the use of security features and are available in the Office policy template.

Security settings can be enforced in one of four registry areas within two branches of the registry — Local Machine (HKLM) and Current User (HKCU).

Local Machine (associated with the Default Computer policy profile in the System Policy Editor)

  • HKLM\Software\Policies\Microsoft\…
  • HKLM\Software\Microsoft\…

Current User (associated with the Default User policy profile in the System Policy Editor)

  • HKCU\Software\Policies\Microsoft\…
  • HKCU\Software\Microsoft\…

The content in this article covers most of the concerns an administrator will have when viewing the Specify Microsoft Project Security Settings page of either the Custom Installation Wizard or the Custom Maintenance Wizard. Most of these settings can also be set using a policy when the appropriate ADM template is added to the System Policy Editor or Group Policy snap-in with Windows 2000 and Windows XP.

Included in this article are policy settings relevant to maintaining a secure user environment related to the operating system user interface.

Adding Microsoft to the Trusted Source List

The trusted source list is managed in four possible places within the registry. Policy settings are in the Policies node of the registry, and are controlled by using the System Policy Editor. The first two registry key entry examples shown below can be set by using the Specify Microsoft Project Security Settings page of the Custom Installation Wizard or the Custom Maintenance Wizard.

Registry key examples:

HKLM\Software\Microsoft\VBA\Trusted

HKCU\Software\Microsoft\VBA\Trusted

HKLM\Software\Policies\Microsoft\VBA\Trusted

HKCU\Software\Policies\Microsoft\VBA\Trusted

Use of the HKLM key prevents users from modifying the trusted sources list.

Adding recognized value names and data to any of these keys instructs Microsoft Project to trust or not trust sources. For example, adding Microsoft Corporation nnnn (where nnnn is a year) as a value name instructs Microsoft Project to trust all sources with a digital signature from Microsoft. It is preferable to use the Specify Microsoft Project Security Settings page of the Custom Installation Wizard or Custom Maintenance Wizard to propagate your request to trust Microsoft certificates, but if it is necessary, you can create a configuration maintenance file (CMW file) by using the Custom Maintenance Wizard, and then, if the setting must be made manually, use the Custom Maintenance Wizard Viewer to view the contents of the file to identify the registry data value. You use the listed value name and data to populate the registry setting.

Setting the value name of the key to No source will be trusted. - your Administrator forces Microsoft Project to not trust any sources. Setting this key disallows the option to let users trust a source. This setting can be controlled by the Custom Installation Wizard and the Custom Maintenance Wizard by using the Ensure users cannot add trusted sources through Microsoft Project check box on the Specify Microsoft Project Security Settings page.

Use of the HKLM node only allows the use of what is in the list, and does not allow users to add entries through the Microsoft Project user interface (the Custom Installation Wizard and the Custom Maintenance Wizard do not use the HKCU node for this key).

Application Security Key

Through the use of the application Security key, you can instruct Microsoft Project to set macro security for each application ,or for the trusting of all installed add-ins. The basic key consists of the following, where <APP> can be any or all of the listed applications (Microsoft Project, Microsoft Word, Microsoft Excel, Microsoft Access, Microsoft PowerPoint, Microsoft Publisher, and Microsoft Outlook®):

The Specify Office Security Settings page of both the Custom Installation Wizard or Custom Maintenance Wizard contain the Trust all installed add-ins and templates check box. When this check box is selected, it creates the non-policy version of the application security key, and adds the value DontTrustInstalledFiles to it. When this policy is set to a value of 1, the registry value instructs the application listed in the <APP> portion of the key to trust all currently installed add-ins and templates (and their respective macros) within specific folders created by the applications. It does not accept all currently installed add-ins and templates on the user's computer, only those installed by specific Microsoft applications. If you use either HKLM or HKCU when setting a registry entry for a policy, you will prevent users from changing the setting.

If you use the Specify Office Security Settings page of either the Custom Maintenance Wizard or the Custom Installation Wizard, and change the default security level for an application, this process equivalent to using the Security dialog box available through the application's user interface. Use of this key sets the macro security level for each application specified in the <APP> portion of the key to the respective value data listed below.

<APP> = Microsoft Project, Word, Excel, Access, PowerPoint, Publisher, Outlook

Common Security Key

You can use the common Security key to instruct Microsoft Project to set ActiveX® security for all applications. This key can be set through either the Custom Installation Wizard or the Custom Maintenance Wizard.

You can use the System Policy Editor to set the equivalent key for Office applications.

The value name UFIControls can be set for any of these keys to the following values and respective actions:

See documentation on ActiveX control development for information on safe mode for ActiveX controls. Look for the following object and method: IObjectSafetyImpl::SetInterfaceSafetyOptions. The IObjectSafety interface allows a client to retrieve and set an object's safety levels. For example, a Web browser may call IObjectSafety::SetInterfaceSafetyOptions to make a control safe for initialization or safe for scripting.

The use of safe mode for an ActiveX control instructs it to run, but not process data. This should force the control to read in the data, but not change the data in any way or write it back out. However, not all controls are designed with a safe mode, and therefore, may process data even though you instructed the control to use safe mode.

Setting the Unsafe ActiveX Initialization to combo box to "Initialize using control defaults. User will be warned." in either the Custom Installation Wizard or the Custom Maintenance Wizard adds the UFIControls value to the common security key, and adds a data value of 3.

Setting the Unsafe ActiveX Initialization to combo box to "Prompt user to use persisted data or control defaults." in either the Custom Installation Wizard or the Custom Maintenance Wizard adds the UFIControls value to the common security key, and adds a data value of 5.

This section includes samples of system policies for security-related configuration options of Microsoft Project and related applications. Most of these policies do not affect security directly, nor do they directly change Microsoft Project; however, they do limit the exposure of critical portions of a network, operating system, or user interface to destructive changes by users. By setting these policies, an administrator can reduce the amount of data users must consider, or reduce the choices users must make while they interact with the system. As a result, productivity can increase by not having to support some features, and by streamlining the user interface of the operating system. The policies in this section are available with the listed templates.

It is highly recommended that administrators examine the policy templates for the operating systems with which their users are working. Several policies provide methods to control and enforce the configuration of the operating system and reduce the probability of a user creating a problem. These policies limit the access of users to features of the operating system that they do not need to change.

Windows NT, Windows 2000, and Windows XP

The following list of policy templates and system policies highlights some of the more important system policies you can use to limit the user environment in Windows NT, Windows 2000, and Windows XP operating systems:

  • Common.adm - Shell | Restrictions
  • Common.adm - System | Restrictions
  • Winnt.adm - Windows NT Shell | Restrictions

System policies related to Windows 2000and Windows XP are also found in the Conf.adm and System.adm policy templates.

Common.adm - Shell | Restrictions

  • Remove Run command from Start Menu
  • Hide drives in My Computer
  • No "Entire Network" in "My Network Places"
  • Remove Shut Down command from Start menu

Common.adm - System | Restrictions

  • Run only allowed Windows applications

Winnt.adm - Windows NT Shell | Restrictions

  • Remove the "Map Network Drive" and "Disconnect Network Drive" options

Windows 2000 Only

The following list highlights some of the more important system policies you can use to limit the user environment in the Windows 2000 operating system:

  • System.adm - Administrative | Start Menu & Taskbar
  • System.adm - Administrative | Windows Components | Windows Explorer | Common Open File Dialog

System.adm - Administrative | Start Menu & Taskbar

  • Do not keep a history of recently opened documents

System.adm - Administrative | Windows Components | Windows Explorer | Common Open File Dialog

  • Hide the Common Dialog Places Bar
  • Hide Common Dialog Back button
  • Hide the drop-down list of recent files

An Explanation of Sample System Policies

Provided in this section is an in-depth explanation of the policies presented earlier in this topic. Each explanation provides the registry key, value name, data type, and associated data necessary to enforce the policy.

Remove Run command from Start Menu

When this policy is enabled, Windows 2000 and Windows XP remove Run from the Start menu and disable launching the Run dialog by pressing the Windows Key + R.

If an application has a "run" function that allows users to start a program by typing in its name and path in a dialog, the application disables that functionality when this policy is enabled.

Template: Common.adm

Path: Shell | Restrictions

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Value name: NoRun

Data type: REG **_**DWORD

Value data:

0 // Display the Run option

1 // Do not display the Run option

Hide drives in My Computer

When enabled, this policy removes the icons representing the selected disk drives from My Computer, Windows Explorer, My Network Places**,** and the Windows common dialogs.

Microsoft Project, as well as any Office application, hides any of the listed drives when this policy is enabled. This includes any buttons, menu options, icons, or other visual representation of drives in Microsoft Project and in other Office applications. This does not prevent the user from accessing drives by manually entering drive letters in dialog boxes.

Template: Common.adm

Path: Shell | Restrictions

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Value name: NoDrives

Data type: REG **_**DWORD

Value data:

0 // Display drives

1 // Do not display drives

No "Entire Network" in "My Network Places"

When enabled, this policy removes all computers outside of the user's workgroup or local domain from lists of network resources in Windows Explorer and My Network Places.

When this policy is enabled, applications that allow users to browse network resources must limit browsing functionality to a local workgroup or domain.

Template: Common.adm

Path: Shell | Restrictions

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Network

Value name: NoEntireNetwork

Data type: REG **_**DWORD

Value data:

0 // Show

1 // Remove

Remove Shut Down Command from Start menu

This policy prevents the user from using the Windows user interface to shut down the system.

When this policy is enabled, applications that enable the user to shut down Windows must disable this capability.

Template: Common.adm

Path: Shell | Restrictions

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Value name: NoClose

Data type: REG **_**DWORD

Value data:

0 // disabled

1 // enabled

Run Only Allowed Windows Applications

When this policy is enabled, users can only run applications listed in the value data field of this registry key. Applications with the ability to run and start other applications are also restricted to the applications appearing in this value data field.

This restriction does not apply when launching applications via OLE/COM/DCOM. If you use ShellExecuteEx, Windows 2000 and Windows XP will handle this automatically.

The only exception to this restriction is for OLE/DCOM, where an installation of Microsoft Internet Explorer is displaying a file in its native format (Word, Excel, and so on) within the browser. Use the executable names (including extension) in the Data field, separated by a semicolon.

Template: Common.adm

Path: System | Restrictions

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Value name: RestrictRun

Data type: REG_SZ (string)

Value data:

WinWord.exe;Excel.exe;PowerPnt.exe

Remove "Map Network Drive" and "Disconnect Network Drive"

When this policy is enabled, users are prevented from using Windows Explorer and My Network Places to connect to other computers or to close existing connections.

When this policy is enabled, applications do not provide buttons, menu options, icons, or any other visual representation that enable a user to map to or disconnect from network drives.

Template: Winnt.adm

Path: Windows NT Shell | Restrictions

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\

Value name: NoNetConnectDisconnect

Data type: REG **_**DWORD

Value data:

0 // Display

1 // Remove

Do Not Keep History of Recently Opened Documents

When this policy is enabled, the system does not save shortcuts to most recently used (MRU) documents in the Start menu.

When this policy is enabled, applications must not keep any MRU lists.

Template: System.adm

Path: Administrative | Start Menu & Taskbar

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Value name: NoRecentDocsHistory

Data type: REG_DWORD

Value data:

0 // Display shortcuts in MRU list

1 // Do not display shortcuts in MRU list

This policy affects Office applications in the following ways:

  • Does not show MRU lists while the policy is enabled.
  • Does not save new entries into MRU lists (freezes the list) while the policy is enabled, which means that after the policy is turned off, the MRU list will not contain any files used while the policy was on, but will contain files used before the policy was enabled.
  • If there is an MRU option in the Options dialog box, it is dimmed while the policy is enabled.
  • After the policy is turned off, the user MRU settings and the application policy MRU settings are restored to the state before the policy was enabled.
  • If both the application MRU policy and the system MRU policy are enabled, the system policy setting is used.

Hide Common Dialog Places Bar

The Places Bar allows users to navigate via the common file open/file close dialog directly to the following locations:

  • History folder
  • Desktop
  • My Documents
  • My Computer
  • My Network Places

When this policy is enabled, Windows 2000 and Windows XP remove the Places Bar from the Windows common dialog box.

When this policy is set, applications that provide their own file open/file close dialogs must remove any equivalent functionality from the Places Bar. Applications using the Windows common dialog API automatically comply with this policy.

Template: System.adm

Path: Administrative | Windows Components | Windows Explorer | Common Open File Dialog

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Comdlg32

Value name: NoPlaceBar

Data type: REG **_**DWORD

Value data:

0 // Display Places bar

1 // Do not display Places bar

Hide Common Dialog Back Button

When this policy is enabled, Windows 2000 and Windows XP remove the Back button from the common dialog box, preventing the user from browsing to the previous folder accessed from the dialog box.

When this policy is set, applications with their own file open/file close dialog boxes must remove any Back button functionality. Applications using the Windows common dialog box API automatically comply with this policy.

Template: System.adm

Path: Administrative | Windows Components | Windows Explorer | Common Open File Dialog

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Comdlg32

Value name: NoBackButton

Data type: REG **_**DWORD

Value data:

0 // Display back button

1 // Do not display back button

Hide the Dropdown List of Recent Files

When this policy is enabled, Windows 2000 and Windows XP remove the MRU list from the common dialog.

When this policy is set, applications with their own file/open dialog boxes must not display an MRU list. Applications using the Windows common dialog box API will automatically comply with this policy.

Template: System.adm

Path: Administrative | Windows Components | Windows Explorer | Common Open File Dialog

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Comdlg32

Value name: NoFileMru

Data type: REG **_**DWORD

Value data:

0 // Display MRU list

1 // Do not display MRU list

See Also

The System Policy Editor you should use to set policies for Microsoft Project is the same one that is included in the Office XP Resource Kit Toolbox**.**

For more information, see System Policy Editor and Templates in the Deployment and Administration Tools section of the resource kit toolbox.

All of the system policies are listed in the policy template. For more information about the policies in the template, see the System Policy Reference resource kit article.

Applying System Policies to Selected Users or Groups

You determine which users or groups are affected by a system policy. You can set policies for a single user, for a group of users, or for all users. You can also set policies for a single computer or for all computers. You make these choices in the System Policy Editor when you create a system policy file.

The Microsoft Project 2002 policies you create and distribute are stored as entries in the HKEY_Current_User\Software\Policies subkey in the Windows registry.

Setting System Policies for All Users or All Computers

You can set a policy for all of the users in your domain by double-clicking the Default User icon in the System Policy Editor. You can also set a policy for all client computers in your domain by double-clicking the Default Computer icon. When you double-click one of these icons, the Properties dialog box opens, and you can set the policies for that user or computer. You can set a policy for all users, for all computers, or for both.

Setting System Policies for a Particular User or Computer

You can set a policy for a specific user account by adding the user to the policy file. For example, suppose that your network includes a Guest account and you want to limit a guest user's access to options. You can use a system policy for the Guest account. Similarly, if all your guest users can use the same computer, you can set a policy for that computer.

Setting System Policies for a Group of Users

You can also set policies for groups of users in your domain. For example, all of the users in a particular department may require the same options. If you create a Windows 2000 or Windows XP user group for that department, you can control the options for all users in that group by setting a policy for it.

Sometimes a user is a member of more than one group. To avoid potential conflicts between group policies, you can set relative priorities so that group policies are applied in a particular order. When a user who is a member of several groups logs on, the policy settings from the highest priority group are processed last, so that those settings override the settings from lower priority groups.

Using Environment Variables in System Policies

Windows98, Windows NT 4.0, Windows 2000, and Windows XP all include the capability to use environment variables in the Windows registry to take the place of actual file names, paths, or other changeable values. Environment variables in the Windows registry take the REG_EXPAND_SZ data type.

Although Windows system policies have used environment variables for some time, Microsoft Project 98 did not recognize the data type REG_EXPAND_S Z, so you could not use environment variables in Microsoft Project 98 system policies. However, you can use environment variables in Microsoft Project 2000 and Microsoft Project 2002.

For example, the Default file location policy allows you to specify a default path to the location where you want users to store Microsoft Project files. If you want to store users' Microsoft Project  files under their user names on the network, you can use a network drive and the following environment variable:

X:\%USERNAME%

When you distribute the policy, the environment variable is written to each user's registry. Microsoft Project 2002 recognizes that %USERNAME% is an environment variable and expands it to whatever the %USERNAME% variable is set to on the user's computer. Using the above example, Microsoft Project 2002 expands UserA to X:\UserA, UserB to X:\UserB, and so on.

You could also use any other appropriately defined environment variable to set the default file location to a particular path or folder. Because Microsoft Project 2002 recognizes the REG_EXPAND_SZ data type, you can use environment variables that exist by default in the operating system or that you set on your own.

See Also

Several Microsoft Project 2002 system policies accept environment variables. For a list of these policies, see the System Policies That Accept Environment Variables section of the System Policy Reference resource kit article.

You can use environment variables in place of directory paths or specific user information. For more information, see the Windows NT Server Resource Kit , the Windows NT Workstation Resource Kit, the Windows 2000 Resource Kit, or the Windows XP Resource Kit.

System Policies and the Windows Registry

You use the System Policy Editor to create a system policy file, based on the system policy template, and then store that file on a network server. When users log on to the network, the system policy file is downloaded to client computers, and the Microsoft Windows registry is updated to use the values specified in the system policy file.

Later, you can update client computers by using new system policies, and the Windows registry for each client computer will be updated when the user next logs on.

Where Policies are Stored in the Windows Registry

The Policies subkey mirrors most of the HKEY_CURRENT_USER\Software
\Microsoft\Office\10.0\MS Project subkey. Placing all of the system policies together in the same subkey prevents Windows registry errors, and also makes it possible for administrators to lock the Policy subkey in Windows NT, Windows 2000, and Windows XP.

The following example shows the hierarchy of the Policies subkey in the Windows registry.

HKEY_CURRENT_USER

FakePre-c16cfc95cc6d474183d6326824fa44ef-b850ae092d9b4110ba3c669d8825de9d FakePre-3efb914a4d74418fa41be5b54712bec6-02fab1537bc04ade915f43a9b3646180 FakePre-e188765d04824558bc7ed4ae95a9aafc-9187d1b8ee8b43c4ac4f1011493fa2c9 FakePre-033a4c0760b34110ac4abcfe04cffa87-62808f234df643129ee985510eb3c605 FakePre-9571b90fc3894bdc9231f7282b962115-32cb5a9e3c4b4373b3eab894157ec0a0 FakePre-636c6e9b07aa44f3b236c3686d6c92e4-eb6263d566844705bae8ef9c95a4bd98

Locating the Registry Entry that Corresponds to a System Policy

Each system policy in a policy template corresponds to one or more entries in the Windows registry. If you want to find out exactly what entries in the Windows registry correspond to a particular policy, you can open the policy template in Notepad, and look for that policy.

The policy template files are divided into categories, and each category lists the Windows registry subkey that contains the entries for that category. Each specific policy entry in the template lists the Windows registry value name that the policy affects and the specific Windows registry value data that is set when the policy is turned on or off.

The following table lists the entries that appear in the policy template files when you open the files in Notepad.

Entry

Description

POLICY

Policy you are turning on or off

KEYNAME

Registry subkey that is affected

PART

Specific option you are setting with the policy

VALUENAME

Registry value that is affected

VALUEON

Registry value data that indicates when this policy is turned on

VALUEOFF

Registry value data that indicates when this policy is turned off