Anyone who has ever administered group policies in a Windows 2000 Server environment knows that the process can be both confusing and frustrating. Although Microsoft’s hierarchical approach to group policy implementation makes sense at a logistical level, the management interface is lacking, to say the least. Fortunately, this is one of the major problems that Microsoft has addressed in Windows Server 2003. When Microsoft releases Windows Server 2003, it plans to simultaneously release a brand new Group Policy Management console that provides a single interface for managing group policies across the entire enterprise.

What is the Group Policy Management Console?
The Group Policy Management Console is Microsoft’s all-in-one solution for working with group policy objects. It consists of a Microsoft Management Console (MMC) Snap-In, and a set of script interfaces for managing group policies via script.

To get an idea of why the Group Policy Management Console will be such a great tool, consider this: Administrators today use a variety of different tools to implement group policy settings. Such tools include things such as:

  • Active Directory Users and Computers
  • Active Directory Sites and Services
  • The Resultant Set Of Policy Snap-In
  • The Access Control List (ACL) Editor
  • The Delegation Wizard

Each of these tools exposes some fragment of the total group policy functionality. The Group Policy Management Console combines all of the group policy functions currently available through these tools and combines them into a single interface. The utility also includes things like backup, restore, copy, and import functionality.

Just because the Group Policy Management Console integrates functionality from all of the different tools that I mentioned earlier, it isn’t intended as a replacement for these tools. Remember that group policies are designed to control security. While security settings are certainly available through tools like Active Directory Users And Computers or Active Directory Sites And Services, those tools’ primary functions are related to administration, not security. Therefore, you’ll still use the tools that I listed in the same manner that you always have.

In case you’re wondering, the Group Policy Snap-In was replaced by the Group Policy Object Editor in Windows Server 2003. However, the Group Policy Management Console didn’t overwrite the Group Policy Snap-In. All of the Group Policy Object Editor’s functionality has been rolled into the Group Policy Management Console, but that doesn’t mean that you can’t still use the Group Policy Snap-In if you want.

A preview of what’s to come

At the time that this article was written, the Group Policy Management Console was available only in beta form. According to the Microsoft Web site, Microsoft intends to release the final version of the Group Policy Management Console simultaneously with the release of Windows Server 2003. Although the Group Policy Management Console won’t be included with Windows Server 2003, it will be a free add-on. When the time comes, you’ll be able to acquire the product from the Windows Server 2003 section of the Microsoft Download Center.

System requirements
The Group Policy Management Console’s system requirements are a little strange to say the least. For example, the product supports Windows 2000, but won’t run on Windows 2000. The new Group Policy Management Console can be used to manage group policies in both the Windows 2000 and Windows Server 2003 version of Active Directory. This means that you’ll be able to take full advantage of the tool’s new management capabilities even if you aren’t planning to upgrade to Windows Server 2003.

The catch is that the utility won’t run on the Windows 2000 operating system. Instead, you can only run the Group Policy Management Console on machines running Windows Server 2003 or Windows XP. If you’re planning on running the utility under Windows XP, there are some additional system requirements that you need to be aware of.

You’ll only be able to run the Group Policy Management Console under Windows XP if you’ve installed Service Pack 1 and the Microsoft .NET Framework support. There is also a post-Service Pack 1 hot fix that must be installed prior to installing the utility. The hot fix was previously available on the Microsoft Web site in Knowledgebase article Q326469. However, Microsoft has temporarily removed the hot fix. According to the Web site, the necessary hot fix will be included with the Group Policy Management Console download.

In case you’re wondering, the Group Policy Management Console will be localized. When the product is complete, versions will be available in English, Japanese, French, and German. The current beta release is available in English and Japanese only. Additionally, the Group Policy Management Console will be fully supported by Microsoft Primer Support Service, once released.

Key features and capabilities
The Group Policy Management Console includes an MMC Snap-In and a set of scripting utilities. The main idea behind the MMC Snap-In is that it exposes group policy settings in the way that users tend to use them rather than in the way that the technology is designed. For example, the group policy settings relating to users are kept in a different area of the Active Directory from the group policy settings related to Sites And Services. Therefore, Microsoft initially created two different tools (Active Directory Users And Computers and Active Directory Sites And Services) to deal with the two different areas of the Active Directory. The new Group Policy Management Console combines the security-related functionality found in both of these and other tools and rolls it into a single snap-in.

The new utility will also feature backup and restore capabilities. Previously, if you wanted to back up and restore group policy settings, you had to perform an authoritative restore on the entire Active Directory. This meant that other things, like user accounts or printer definitions, were also reverted to the time that the backup was made. The new utility, however, allows you to restore only the group policy settings for a domain.

Yet another new feature is the generation of HTML reports related to group policy settings and the resultant set of policy data. You can even save or print these reports.

Finally, import/export, copy/paste, and scripting features have been included in the Group Policy Management Console. Although you can’t script individual group policy values, the scripting does have a definite purpose. The import/export, copy/paste, and scripting functions all work together to allow you to migrate group policies between domains.

Migrating group policy objects to another domain
The new Group Policy Management Console allows you to migrate group policies from one domain to another. There are lots of situations where such an operation is desirable. For example, if you perfected a new policy in a test domain, it would usually be easier to migrate the policy than to manually re-create it in the new location. Another possible situation is if your company adopted a new set of security standards, you wouldn’t want to have to manually implement those standards across every domain. Instead, it’s now possible to create the new policy in one domain and roll it out to all other domains.

There are a couple of reasons why migrating group policy objects between domains is such a big deal. The first reason is that a group policy is a collection of security settings applied through various mechanisms to various objects. Components of a group policy might exist in the registry, Active Directory, the file system, or just about anywhere else. It isn’t like all of a group policy’s components exist in a single folder that can easily be copied from machine to machine.

The other issue that makes copying group policy objects between domains difficult is that certain group policy settings contain data that simply doesn’t migrate well. The two main types of data that tend to cause problems are security principles and Universal Naming Conventions (UNCs).

Security principles are often found in the form of security identifiers (SIDs). SIDs are unique identification numbers that are applied to each object. For example, objects such as users, groups, and computers all have SIDs associated with them. Because of the unique nature of SIDs, a SID that’s valid in one domain wouldn’t necessarily be valid in another domain.

Just as SIDs can throw a monkey wrench into the process of migrating a group policy object, so too can UNCs. A UNC refers to a path that’s expressed in the \\servername\sharename format. The problem is that a server name and share name that are valid in one domain may not be valid in another domain.

Watch out for these items

The following items contain security principles and can therefore cause problems because they may reference SIDs:

  • Security policy settings found in user right assignments
  • Restricted groups
  • Services
  • The file system
  • The registry
  • Advanced folder redirection policies
  • The GPO DACL
  • The DACL applied to software installation objects

Also, UNC paths, which can lead to problems with group policy object migrations as well, can be found in:

  • Folder redirection policies
  • Software installation policies
  • Login scripts
  • Startup scripts

The Group Policy Management Console takes a lot of the work out of migrating group policy objects to a new domain. However, doing so may still be a fairly involved process. The Group Policy Management Console is capable of performing four functions that are related to policy archival. These functions are:

  • Backup
  • Restore
  • Copy
  • Import

Don’t even try to use the Backup and Restore operations for migrations. It’s impossible to restore a policy backup to a different domain. You can use the Import function with the Backup function as a technique for updating a group policy object’s existing settings, but to do so, a group policy object must already exist in the destination directory, even if the existing group policy object is empty. The Copy function is almost always the tool of choice for migrations, because the Copy process doesn’t require you to have a group policy object that’s already in place in the destination domain.

As you can see, the two main problems associated with migrating group policy objects between domains are the distributed nature of the policy settings and the fact that SIDs and UNCs would be mismatched if the policies were to be copied directly. Fortunately, with a little work, you can use the Group Policy Management Console to overcome both of these problems. Overcoming the problem of distributed information is easy and automatic. Since the Group Policy Management Console already knows where all of the group policy setting information is stored, you don’t have to worry about tracking it down.

Overcoming the information mismatch problem is a little more complicated though. In order to deal with SID and UNC mismatches, you must create a migration table. A migration table is an XML file that maps an old value to a new value. I’m not going to get into the specifics of creating migration tables, because it would be possible to write an entire article on this one step of the process. What I can tell you though is that each entry in a migration table has three values: an object type, a source value, and a destination value.

For example, if a particular group policy was applied to a global group called Test Group in a domain called TEST, and you wanted the policy to apply to the Finance group in the PRODUCTION domain, then the object type would be a global group, the source value would be TEST\TEST GROUP, and the destination value would be PRODUCTION\FINANCE.

After looking at my sample entry in a migration table, the process of creating migration tables may not seem that complicated. The problem is that in the Beta 2 release of the Group Policy Management Console, there was no user interface for creating migration tables. Therefore, if you need a migration table, you must either write some raw XML code, or you can use a script to generate the XML code and then use a text editor to modify the code and fill in the appropriate values. Either way is tedious and complicated.

As you can see, the process of migrating group policy objects from one domain to another can be a real pain in the neck. Before you criticize the Group Policy Management Console too much though, remember that up until now there was no way of migrating a group policy object to another domain. Migrating a group policy object through the Group Policy Management Console is a crude process, but this is first generation software that’s still in its beta testing phase. I think that it’s likely for future versions to include a user interface for creating migration tables.

Good things come to those who wait
As you can see, the Group Policy Management Console should make life much easier for those who manage group policies. Furthermore, this utility could drive down Windows’ total cost of ownership since it will make the management process much easier and more efficient.