For Administrative Templates policy settings, the Group Policy Object Editor provides explain text directly in the Web view of the console. You also can find this explain text by double-clicking the policy setting and then clicking the Explain text tab. In either case, this text shows operating system
requirements, defines the policy setting, and includes any specific details about the effect of enabling or disabling the policy setting.
New policy settings
Windows Server 2003 includes more than 200 new policy settings. The new Windows Server 2003 policy settings allow administrators to control the behavior of:
• System restore, error reporting, PC Health.
• Terminal Server.
• Networking such as SNMP, QoS, personal firewall, and dialup connections.
• DNS and net logon.
• Roaming user profiles and Group Policy.
• Control panel.
To filter settings based on the “supported on” information: Open the Group Policy Object Editor, click View, and then click Filtering. Select the versions you want to show and click OK.
Note Showing only policy settings that can be fully managed is the default setting. You can also show
policy settings by supported-on information and show only configured policy settings. In Windows Server 2003, the command Only show configured policy settings is now contained in the Filtering dialog box, shown above.
True Policy Settings Compared with Group Policy Preferences
In Windows 2000 and later, all shipping policy settings set registry keys and values in one of the following locations:
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies.
• HKCU\Software\Policies (preferred location).
• HKCU\Software\Microsoft\Windows\CurrentVersion\Policies.
Policy settings that are stored in these specific locations of the registry are known as true policies. Storing settings here has the following advantages:
• These trees are secure and cannot be modified by a non-administrator.
• When Group Policy changes, for any reason, these trees are cleaned, and the new policy settings are then rewritten.
This prevents the behavior that was often present in Windows NT 4.0, whereby System Policies resulted in persistent settings in the user and computer registry. The policy remained in effect until the value was reversed, either by a counteracting policy or by editing the registry. These settings are stored outside the approved registry locations above and are known as preferences.
All the policy settings in the System.adm, Inetres.adm, Conf.adm, Wmplayer,adm, and Wuau.adm files use registry settings in the Policies trees of the registry. This means that they will not cause persistent settings in the registry when the GPO that applies them is no longer in effect.
By default, only true policy settings are displayed in the Group Policy Object Editor. The following .adm files are loaded:
• System.adm: contains operating system settings
• Inetres.adm: contains Internet Explorer restrictions
• Conf.adm: contains NetMeeting settings
• Wmplayer,adm: contains Windows Media Player settings
• Wuau.adm: contains Windows Update settings
Note Because of the persistent nature of non-policy settings, they should be avoided.
It is still possible for administrators to add an additional .adm file that sets registry values outside of the Group Policy trees mentioned previously. These settings might be more appropriately referred to as preferences because the user, application, or other parts of the system can also change them. In this case, the administrator is ensuring that this registry key or value is set in a particular way. Although it is possible to add any .adm file to the namespace, if you use an .adm file from a previous version of Windows, the registry keys are unlikely to have an effect; or they actually set preference settings and mark the registry with these settings; that is, the registry settings persist.
Creating Custom .adm Files
It is possible to create new .adm files. For example when an application adds Group Policy support, a new .adm file may be necessary to describe the location of the appropriate registry keys and the UI exposed by the Group Policy Object Editor. Through the Group Policy Object Editor, the administrator can optionally add in additional .adm files to the GPO which, by default, will then be copied to the domain controller into the GPO directory.
To view custom .adm files in the Group Policy Object Editor:
• Right click any administrative template node, select View and then click Filtering. In the filtering dialog box, clear the check box for Only show policy settings that can be fully managed and click OK.
Viewing Group Policy Preferences
By default only the settings that are contained in the genuine Group Policy trees (the trees that correspond to the reserved Group Policy registry areas) are visible in the console.
To eliminate use of non-policies, you can enable the policy setting, Enforce Show Policies Only, available in User Configuration\Administrative Templates, under the System\Group Policy nodes. If you enable this setting, the Show Policies Only command is turned on, and administrators cannot turn it off. As a result, Group Policy displays only true settings; preferences do not appear. If you disable this setting or do not configure it, the Show Policies Only command is turned on by default, but
administrators can view preferences by turning off the Show Policies Only command.
In Group Policy, preferences are indicated by a red icon to distinguish them from true policy settings, which are indicated by a blue icon.
Impact of GPO Replication
By default, when you add a new domain to the console, GPMC uses the PDC emulator in that domain to help ensure that all administrators are using the same domain controller. For managing sites, GPMC uses the PDC emulator in the user's domain by default. You can change the default choice of domain controller using the Change Domain Controller dialog box in GPMC. If you are located at a remote site with a slow connection to the default domain controller, you may want to do this.
It is important for administrators to consider the choice of domain controller in order to avoid replication conflicts particularly because both Active Directory and FRS use multi-master replication. This is especially important to consider because GPO data resides in both Active Directory and on Sysvol, and two
independent replication mechanisms must be used to replicate GPO data to the various domain controllers in the domain. If two administrators are simultaneously editing the same GPO on different domain
controllers, it is possible for the changes written by one administrator to be overwritten by another administrator, depending on replication latency.
Important
If multiple administrators manage a common GPO, it is recommended that all administrators use the same domain controller when editing a particular GPO, to avoid collisions in FRS.
Because the Group Policy template is replicated to all domain controllers, the size of the .adm files can have an impact on network bandwidth, particularly where domain controllers are separated by slow links.