Q 1.1: What are the principal differences between Windows 2000 and Windows XP Group Policy and Windows NT 4.0 System Policy?
A:
Windows NT 4.0 System Policy allows you to set registry values across users, computers, and groups within your NT 4.0 (or Windows 2000—Win2K) domains. Win2K and Windows XP Group Policy include a superset of NT 4.0 System Policy functionality.Flexibility
In addition to the ability to set registry value policy—called Administrative Templates in Win2K and Windows XP Group Policy, Group Policy Objects (GPOs) include the ability to set security configurations, enforce Internet Explorer (IE) browser settings, distribute software applications, and redirect elements of users’ Desktop, My Documents, and Start menu to locations other than their user profiles. Figure 1.1 shows the Group Policy Microsoft Management Console (MMC) snap-in, focused on a Win2K GPO.
Although GPOs provide significantly more policy features than NT 4.0 System Policy provides, GPOs are stored and processed differently than NT 4.0 System Policy is. In NT 4.0, the System Policy file (often called ntconfig.pol) is stored in the Netlogon share on domain controllers within an NT 4.0 domain. When an NT 4.0 user logs onto a workstation in an NT 4.0 domain, the system reads the System Policy file from the Netlogon share, then sets registry values that are specific to a computer, user, or user group according to the policy file. NT 4.0 allows only a single policy file to be processed at a given time. NT 4.0 System Policy could apply to a specific computer (or all computers), a specific user (or all users), or an NT 4.0 domain global group.
In contrast, GPOs are composed of two parts: the Group Policy Container (GPC), which is stored within Active Directory (AD), and the Group Policy Template (GPT), which is stored within the replicated SYSVOL folder on all AD domain controllers in a domain. Whereas System Policy is processed only when a user logs onto an NT 4.0 workstation, GPOs are processed at both
machine startup (at which point machine-specific policy is processed) and user logon (at which point user-specific policy is processed). Again, in contrast to System Policies, you can define a virtually unlimited number of GPOs within an AD domain (though practically speaking, large numbers of GPOs will take a long time to process). And, whereas System Policies apply to individual users, individual computers, and NT security groups, GPOs are processed only by AD users and computers. However, AD security groups composed of either machines or users can filter GPOs’ effects. This filtering capability, in conjunction with the ability to have multiple GPOs processed by a given user or computer, can provide much greater policy flexibility than is available in NT 4.0. Figure 1.2 shows an example of how you can use security groups to filter the effects of a GPO.
Ease of Administration
A single NT 4.0 System Policy can be associated to a single NT 4.0 domain at a given time;
GPOs can be linked, or associated with an AD domain, an AD site (a collection of IP subnets), or an AD organizational unit (OU). When a GPO is linked to a domain, site, or OU, all users and computers that reside under those container objects in an AD infrastructure will process that GPO. Figure 1.3 shows an example of what this setup would look like in a typical AD infrastructure.
Figure 1.3: Viewing GPOs linked to multiple container objects in an AD infrastructure.
Note that in Figure 1.3, multiple GPOs can be linked to each container object (for example, site,
those linked to domains, and finally those linked to OUs. This order of precedence is often referred to as SDOU (as in sites, domains, then OUs).
Note that each Win2K and Windows XP device also has its own local GPO that isn’t associated with an AD infrastructure. This local GPO is actually applied before any AD-linked GPOs.
Administrative Tools
The final significant difference between System Policy and GPOs relates to the tools you use to create and edit each. GPO editing tools are significantly different than the Policy Editor tool (poledit.exe) provided in NT 4.0. GPOs rely on MMC snap-ins for creation and to be edited. The following steps walk you through how to create a new GPO:
1. From the Win2K or Windows XP Administrative Tools program group, choose the Active Directory Users and Computers snap-in to create domain or OU-linked GPOs, or select the Active Directory Sites and Services snap-in to create site-linked GPOs.
2. Highlight the container object (the domain, site, or OU) for which you want to create the new linked GPO, and right-click to expose the context menu for that container.
3. Choose the Properties menu item, and in the resulting window, select the Group Policy tab.
4. Click New. In the Group Policy Object Links dialog box, a new GPO is created and highlighted so that you can change its name (as Figure 1.4 shows).
From this point, all you need to do is change the name of the GPO to be descriptive and, with the GPO highlighted, click Edit to start an MMC Group Policy snap-in tool focused on your new GPO. You can then begin making changes to the GPO.
Q 1.2: What is registry tattooing, and how do Windows 2000 and Windows XP Group Policy Objects prevent it from happening?
A:
Registry tattooing occurs when a Windows NT 4.0 System Policy makes a registry change that is left in place even if the policy no longer applies. Tattooing is a big problem in NT 4.0 System Policy. Its effects cause a variety of problems. For example, suppose you’ve set a number of registry settings in an NT 4.0 System Policy and you want to back them out.Logically, you would think that you could just remove the policy file (for example, ntconfig.pol) from the Netlogon share on your NT 4.0 domain controllers, and users would no longer get that policy. However, such is not the case at all. In fact, the registry settings that System Policy applies are permanent, unless explicitly un-done by a policy that reverses their effect. The effects from these lingering registry settings are called tattooing because the registry is tattooed with those settings.
Tattooing is the process that occurs when an NT 4.0 System Policy applies registry settings that are not removed when the System Policy no longer applies.
Although NT 4.0 doesn’t include an easy mechanisms to undo the tattooing process, Windows 2000 (Win2K) and Windows XP both allow for registry settings to be removed when a Group Policy Object (GPO) no longer applies to a user or computer. However, this statement is not universally true for any registry setting that is set through the GPO Administrative Template policy. Win2K and Windows XP differentiate between policies and something called
preferences. Policies are those Administrative Template policy settings that are set within a particular set of registry keys:
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies
• HKEY_CURRENT_USER\Software\Policies
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies The first two registry keys are set within computer-specific GPO Administrative Template policy. The last two keys are user-specific. Thus, if you set policy that makes changes to values within one of these four keys, that policy will be removed (that is, not tattooed) if the GPO that sets the policy is no longer processed by the computer or user.
If you define an Administrative Template setting that modifies registry values outside of the four keys, such a setting is considered a preference—preferences do tattoo the registry. Microsoft recommends that all applications that use Group Policy-based Administrative Template policy write their policy settings to one of the previously mentioned four keys. Thus, those settings are
Within the Group Policy Microsoft Management Console (MMC) snap-in tool, you can filter the view of Administrative Templates to view only policies that don’t tattoo the registry (that is, those that make changes only to the keys listed earlier) or both policies and preferences. The mechanism to filter the view is different between Win2K and Windows XP, but the effect is the same. In Windows XP, from the Group Policy MMC snap-in, highlight and right-click either the Administrative Templates node in either Computer or User configuration. From the resulting context menu, select View, then choose Filtering from the sub-menu. The dialog box that Figure 1.5 shows will appear.
Figure 1.5: Viewing the filtering options in the Windows XP-based Group Policy editor tool.
In Figure 1.5, there is an option that says Only show policy settings that can be fully managed.”
The term “fully managed” is Windows XP’s way of saying that the policy setting does not tattoo the registry. If you clear this check box, you will see both policy settings as well as preferences.
The MMC Group Policy tool differentiates policies and preferences by associating different colors to the icons representing each. In Figure 1.6, I’ve created a custom .adm template file that sets a preference within the registry. You can see that my preference Set current GPO version for User has a red icon associated with it.
Figure 1.6: Viewing a preference, indicated by a red icon, within the Group Policy MMC tool.
The other policy items in Figure 1.6 have blue icons associated with them indicating that they are non-tattooing policies.
Win2K’s Group Policy MMC tool works the same as in Windows XP. However, the menu item that you use to filter the view of policies and preferences is different. Namely, from the Win2K Group Policy MMC tool, highlight an Administrative Templates node, right-click, select View from the context menu, and clear the Show Policies Only check box to view both policies and preferences.
So now we know the effects of tattooing. To better understand the actual process, let’s look at how it works behind the scenes. The specific registry keys and values that are modified within GPO-based Administrative Template policy is controlled by the .adm template files associated with that GPO. Listing 1.1 shows a snippet from an .adm template file in Windows XP.
CATEGORY !!Logon
#if version >= 4
EXPLAIN !!Logon_Help
#endif
POLICY !!NoWelcomeTips #if version >= 4
SUPPORTED !!SUPPORTED_Win2kOnly
#endif KEYNAME
"Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
EXPLAIN !!NoWelcomeTips_Help VALUENAME "NoWelcomeScreen"
END POLICY
Listing 1.1: Viewing a snippet from a Windows XP .adm template file.
In Listing 1.1, the NoWelcomeScreen registry value is being modified under the registry key Software\Microsoft\Windows\CurrentVersion\Policies\Explorer. From Listing 1.1, this key is under the path listed as one that protects from tattooing. Now, as you probably know, an
Administrative Template policy can take three states—not configured, enabled, or disabled (see Figure 1.7).
When a state is set to not configured, the registry value specified within the .adm file has not been set. For example, in Listing 1.1, a not configured setting would mean that the
NoWelcomeScreen registry value does not exist on machines that are processing the GPO on which that policy is defined. If the policy is enabled, the registry value is created and the data within the value is set according to the .adm file. In some cases, it may mean simply setting the value to 1 or 0. In other cases, it may be filling the value with some text string, but in either case, making the policy enabled means that the registry value exists and is set to some value. If the policy is set to disabled, the registry value is set to the opposite value, as specified by the .adm file, from the enabled state. Again, looking at the .adm snippet in Listing 1.1, this policy dictates that the NoWelcomeScreen value is created and set to 1 when the policy item is enabled and 0 when its not.
When a policy item defined in the .adm template file does not explicitly call out what the values should be for the enabled and disabled states, the default is to take a REG_SZ type value of 1 for enabled and a REG_SZ type value of 0 for disabled.
If an Administrative Template policy item such as the one that Listing 1.1 shows makes changes to the “magic” keys in the registry that prevent tattooing, that value will change from enabled or disabled when the GPO is processed by the computer or user to not configured if the GPO no longer applies to the computer or user. However, if the policy item does not make a change to one of the “magic” keys, whatever change it makes to the registry—be it enabled or disabled—
will remain even after the GPO has been removed or no longer applies to the computer or user.
To get rid of it, you would need to explicitly set that preference to not configured to remove the tattooed registry value. So, as you can see, there is a significant reduction in the policy
maintenance you have to do on a system if you use policies instead of preferences.
Q 1.3: How do .adm files differ between Windows NT 4.0 and Windows 2000 and Windows XP?
A:
Microsoft has added quite a few new features to the Administrative Template .adm“language” between Windows NT 4.0 and Windows XP. Most of the new features are in the form of new keywords that enable new Group Policy features and functions. For example, in Windows 2000 (Win2K), Microsoft added the EXPLAIN tag to allow for the text explanations that you find in the Group Policy Microsoft Management Console (MMC) snap-in (see Figure 1.8).
Figure 1.8: Viewing the Explain text associated with an Administrative Template policy.
Listing 1.2 shows an example of how the EXPLAIN tag is called within an .adm file.
POLICY !!NoSecurityMenu KEYNAME
"Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
EXPLAIN !!NoSecurityMenu_Help VALUENAME "NoNTSecurity"
END POLICY
Listing 1.2: An example of the EXPLAIN tag used in Win2K and Windows XP .adm files.
In Listing 1.2, the EXPLAIN tag references some text, defined using a label (in this example,
!!NoSecurityMenu_Help), which is usually defined at the end of an .adm file within a section called out by the [strings] tag. Within the [strings] section, each label is defined to equal a text string that defines what that label means. It’s this text string that is shown in the Group Policy editor tool to explain a policy item. Win2K and Windows XP EXPLAIN tags improve upon the NT 4.0 System Policies by providing an explanation of what a given policy actually does and how you can use it. If you create custom .adm files, you should strongly consider creating accompanying EXPLAIN tags that explain your custom policy.
In addition to the EXPLAIN tag, Win2K and Windows XP include some additional logic within the .adm file to test the version of policy editor tool that is loading the .adm file. Because the NT 4.0 policy editor won’t understand newer tags supported in Win2K and Windows XP, .adm files created for these newer Windows versions use special logic to test for the version of the policy
#if version <= 2
Note that in Listing 1.3, the first statement is #if version <= 2. This statement checks to see whether the version of policy editor tool is equal to or less than version 2. Version 2 corresponds to the NT 4.0 policy editor tool (poledit.exe) or earlier policy tools. If the NT 4.0 policy editor tool attempts to load and use an .adm file created for Win2K or Windows XP, the only policy entry you will see is that shown in Figure 1.9.
Figure 1.9: Viewing the effects of loading a Win2K .adm file using the NT 4.0 policy editor tool.
The sections of text that you see in Listing 1.3 after the version check are there to create the screen you see in Figure 1.9. That is, the various labels such as GPOnly_Tip1 thru Tip5 contain the text shown in the Settings for System.adm section of the dialog shown in this figure. Listing 1.3 is saying that if the version is 2 or less (that is, the NT 4.0 system policy editor tool), show the text specified by the various tips, which basically explains that you need a newer version of the policy tool to view the contents of the .adm file.
If the NT 4.0 policy editor tool is version 2, it stands to reason that version 3 is the Win2K MMC-based Group Policy snap-in, and version 4 is the GPO snap-in that comes with Windows XP. In Win2K- and Windows XP-based .adm files, you will see version checks for versions 3 and 4 as well.
Windows XP also includes a new twist. Windows XP lets you view and filter Administrative Template policy items based on which platform is required by a given policy. For example, if you have an .adm policy that works only on Windows XP, you want to know that setting the policy will have no effect on Win2K machines that process the policy. To do so, .adm files in
POLICY !!ShutdownReason #if version >= 4
SUPPORTED !!SUPPORTED_WindowsXP
#endif
EXPLAIN !!ShutdownReason_Help
KEYNAME "Software\Policies\Microsoft\Windows NT\Reliability"
PART !!ShutdownReason_Box DROPDOWNLIST REQUIRED VALUENAME "ShutdownReasonUI"
ITEMLIST
NAME !!ShutdownReason_Never VALUE NUMERIC 0 DEFAULT
NAME !!ShutdownReason_Always VALUE NUMERIC 1 END ITEMLIST
END PART END POLICY
Listing 1.4: Viewing the use of the SUPPORTED tag in an XP .adm file.
The SUPPORTED tag is not a hard restriction. That is, unlike the version checks, it doesn’t prevent the Win2K version of the Group Policy editor tool from loading a Windows XP .adm file and setting policies. In fact, a Win2K Group Policy editor will simply ignore the SUPPORTED tag because the tag is always surrounded by the statement #If version >= 4, which indicates to the Group Policy tool reading the file that the section within the #if and #endif clauses be read only by a Windows XP (version 4) version of the Group Policy editor tool.
For Windows XP, the SUPPORTED tag allows two capabilities. The first is that, on the main dialog box of each policy item, the SUPPORTED tag is read to indicate which version of the OS the current policy supports (see Figure 1.10).
In addition, Windows XP uses the SUPPORTED tag to let you filter policy items based on their OS requirement. From the Group Policy MMC snap-in tool, if you highlight the Administrative Templates node (either per computer or per user), and select View, Filtering, you will see the dialog box that Figure 1.11 shows.
Figure 1.11: Using the SUPPORTED tag within the Windows XP Group Policy editor tool to allow filtered views of .adm policy.
From the dialog box that Figure 1.11 shows, you can view Administrative Template policy items that are specific to a particular OS so that you know which policies will affect which clients on your network.