Tools for Managing GPOs - Windows 2000 Group Policy

Q 6.1: How can I create customized tools for my administrators who need to manage Group Policy Objects?

A:

The principal interface for editing Group Policy Objects(GPOs) is the Microsoft Management Console (MMC) Group Policy snap-in. Although the tool does not provide a tremendous amount of flexibility, you can use the customization features within the MMC to create some custom tools for your administrators.

Create Locked Down Tools

The MMC gives you the ability to create locked down “tools” (.msc files) that you can distribute to your administrators. The advantage of creating these custom tools is that you can expose only those management interfaces that a set of administrators needs to do their job. This feature can be useful for distributing GPO administration tasks as well. For example, instead of giving your administrators access to the Active Directory Users and Computers snap-in and expecting them to navigate to the correct container object in which the GPO they need to manage is linked, you can give them a custom MMC tool that exposes only the GPO or GPOs they need to manage.

Let’s suppose you have a group of administrators that needs to administer three GPOs linked to your Active Directory (AD) domain. You want to create a tool that exposes only those three GPOs to them. Following these steps, you can create a custom MMC tool to accomplish this goal.

1. From the Start menu, select Run, and in the Run dialog box, type mmc.exe

to bring up a blank MMC console.

2. From the MMC Console menu, select Add/Remove snap-in, and click Add.

3. From the list of available standalone snap-ins, navigate to Group Policy, and click Add.

4. From the Select Group Policy Object dialog box, click Browse to browse available GPOs in your AD domain.

5. Select the GPO you want to add to the MMC console. Repeat steps 3 and 4 for all GPOs you want to add.

6. Once you’ve added all the desired GPOs, you need to lock down the console tool so that your administrators can’t change it once you give it to them. To do so, open the Console menu, and select Options.

7. From the Options dialog box, you can give your console a name and choose the mode that the tool will be opened in. In this case, choose User mode—limited access, single window from the Console mode drop-down list.

8. Check the Do not save changes to this console check box, as Figure 6.1 illustrates, then click OK to complete the option setting.

Figure 6.1: Viewing the options for locking down an MMC console tool.

9. Finally, save the console file with a unique name (for example, GPOAdmins.msc).

You can then distribute the .msc file to your Group Policy administrators.

Note that this .msc file can be run only from a Windows 2000 (Win2K) or Windows XP workstation. It cannot be run from a Windows NT 4.0 workstation.

The resulting tool looks like the one that Figure 6.2 shows.

As you can see in Figure 6.2, the Console menu is no longer present. The administrator using this tool cannot add any other MMC snap-ins and basically can only administer the three GPOs listed.

Limit Tools Even More

You can provide an even more limited MMC console. For example, you might have a GPO that uses the software installation feature to deploy applications. To illustrate this point, suppose you have an administrator who is solely responsible for deploying software through that one GPO, and you don’t want to expose any other policy settings within that single GPO to the

administrator. You can follow a slight variation of the earlier process to form such tool. First, follow steps 1 through 5 to add the GPO into a new MMC console. Once it’s been added, drill into the appropriate software installation node. With the software installation node highlighted, right-click and select New window from here on the context menu. Ensure that the software installation node window is maximized such that it takes up all the real estate on the MMC console and blocks visual access to any other policy settings within the GPO. Next, set the console options for the tool as Figure 6.1 shows to lock down what the user can do using the settings I showed in step 7. Then save the tool to an .msc file. Figure 6.3 shows what the resulting tool will look like.

Figure 6.3: Viewing a locked down GPO tool focused on a single policy function.

Using the tool that Figure 6.3 shows, users can neither modify additional GPO policy settings nor can they even tell which GPO they are setting software installation policy for. This setup can be useful when you need to delegate GPO administration tasks to a user who has little technical skill and just needs to follow simple directions to deploy software.

Q 6.2: Can I script the creation of Group Policy Objects?

A:

The short answer to this question is no. Neither Windows 2000 (Win2K) nor Windows XP

You can script the process of linking a GPO to a container object. This capability is available through the Windows Script Host (WSH) and the Active Directory Service Interfaces (ADSI) COM objects available in Win2K and Windows XP. The Microsoft article “Scripting the Addition of Group Policy Links” at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q248392 provides a sample VBScript WSH script called gpollink.vbs, that lets you add (but not remove) GPO links to container objects.

You have to modify the script to replace generic domain names (for example, mydomain.com) and server names (that is, all instances of servername) with your own domain name and the server name of the Primary Domain Controller (PDC) emulator for your Active Directory (AD) domain. You could choose any domain controller to make the change to the GPO link. But choosing the PDC emulator is preferable because GPO changes, by default, are always made against the PDC emulator role-holder. That script also leverages a Component Object Model (COM) object called IADSTools.DLL that is part of the Win2K Support Tools. IADTools.DLL is a library of functions that let you perform administrative scripting activities on AD and related objects. For example, the line in the script (modified to include my domain name and server name)

Result=DLL.GetGPOs("mar-elia.com","DC1")

uses the IADSTools method called GetGPOs() to return a list of all GPOs defined in the domain called mar-elia.com. DC1 is the name of the PDC emulator for the domain that the function queries. The script then uses another IADSTools method called gponame()

if lcase(DLL.gponame(i))=lcase(askGUID) then

to determine, of the GPOs found earlier, which GPO the user has chosen to link to the container.

The script then uses ADSI to modify the gPLinks attribute on the container object defined by the variable called SDOU to add the new GPO link. By default the script is set up to link GPOs to the domain level, by virtue of the following statement:

Set SDOU=GetObject("LDAP://DC1/dc=mar-elia,dc=com")

However, you can also use the script to add links to organizational units (OUs) or sites by simply modifying this statement. For example, if I want to add a GPO link to an OU called Finance, I would modify the statement to look like the following example:

Set SDOU=GetObject("LDAP://DC1/OU=Finance,dc=mar-elia,dc=com") With the text OU=Finance, the new part of this statement. If I want to link to a site, the process gets a bit trickier because sites are found in a different Lightweight Directory Access Protocol (LDAP) path from domains and OUs. Suppose I have a site called SanFrancisco to which I want to link a GPO. The syntax for the statement would look like the following example:

Set SDOU=GetObject("LDAP://DC1/

CN=SanFrancisco,CN=Sites,CN=Configuration,dc=mar-elia,dc=com") The SanFrancisco site is located within the Configuration naming context of the domain mar-elia.com. Thus, the LDAP path to the site looks a bit different from the domain and OU examples. Now let’s run the script to see how it works. From the command line, simply type

C:\> cscript gpollink.vbs

Microsoft (R) Windows Script Host Version 5.1 for Windows

Default Domain Policy

The SDOU you will be modifying is:

LDAP://DC1/CN=SanFrancisco,CN=Sites,CN=Configuration,dc=mar-elia,dc=com

Successfully added a link to this SDOU for the GPO (Desktop Lockdown Policy)

Listing 6.1: Viewing the output from the gpollink.vbs script.

The script also returns the path to the container object to which you’re linking. Next, you’re prompted by a pop-up input box to enter the friendly name of the GPO that you want to link to.

The friendly name is the name that you see when you’re editing the GPO (for example, Desktop Lockdown Policy) rather than the globally unique identifier (GUID) name of the GPO. Assuming that the script finds the name of your GPO, it creates the link on the container object and returns a success message.

This script only adds GPO links to a container object—it does not remove them. However, with some clever string manipulation, you could modify the same script to do the removal process as well. The link that builds the gPLink attribute

currentGPLIST=currentGPLIST & "[LDAP://CN=" & DLL.gpoguid(i) &

",CN=Policies,CN=System," & DLL.getdefaultnamingcontext("Yquem")

& ";0]"

could be manipulated using the regular expression function within WSH to remove the GUID for the chosen GPO.

Expect later releases of Windows as well as third-party products to provide the ability to script the creation and editing of GPOs. This ability will most likely come in the form of Windows Management Instrumentation (WMI) objects that allow script-based manipulation of GPOs.

Q 6.3: Which tool can I use to force Group Policy Object processing from the command line?

A:

Windows 2000 (Win2K) offers only limited capability to force Group Policy Object (GPO) processing from the command line. Win2K comes with a command-line tool called secedit.exe.

Ostensibly, secedit.exe is part of the security configuration toolset, but when you run secedit on a Win2K device, it can force a reprocessing of GPO settings. For example, using the command

Secedit /refreshpolicy machine_policy

forces the computer to reprocess all machine-specific GPOs that affect that computer. (If you use user_policy instead of machine_policy, user-specific GPOs are processed.) Of course, by default, GPOs that have not changed since the last processing cycle will not be reprocessed by the

computer, but nevertheless, secedit can trigger reprocessing. GPO policy items such as folder redirection and software installation are not actually triggered to run using secedit. These extensions cannot run via a background refresh, and thus aren’t triggered just by using secedit.

Windows XP includes a new command called gpupdate.exe that allows more complete support for refreshing GPO-based policy. With gpupdate.exe, we get a more full-featured command-line mechanism for triggering GPO processing. Gpupdate lets you target a refresh of user or machine policy just as secedit does. In addition, gpupdate provides options that let you force a refresh of all policy settings, regardless of whether the GPO has changed since the last processing cycle.

You can also use gpupdate to handle those policy settings—such as software installation and folder redirection—that require a system restart or user logoff/logon in order for those policies to be applied. Listing 6.2 shows the command-line options available to gpupdate.exe.

Syntax: GPUpdate [/Target:{Computer | User}] [/Force] [/Wait:<value>]

[/Logoff] [/Boot] [/Sync]

Listing 6.2:Viewing the syntax for the gpupdate tool.

The force option, as I mentioned, lets you force GPO processing to occur for all applicable policy settings even if the GPO(s) did not change since the last time it (or they) was processed.

The Wait option simply lets you tell gpupdate how long, in seconds, to hold control of the command shell before releasing it back to the user. This option does not control how long GPO processing actually takes, but rather tells gpupdate to not relinquish command until either the time you specify has expired or all GPO processing has completed. The Logoff option instructs gpupdate to process all applicable GPOs and, if there are any policies that require a logon event to actually become visible, this option forces a user to logoff. Similarly, the Boot option does the same thing for policies that require a system restart (such as machine-based software

installation). After all applicable GPOs are processed, if a reboot is required, the system will reboot. Finally, the Sync option is a very useful one in that it lets you override asynchronous GPO processing (also known as fast logon optimization in Windows XP) for the next processing cycle only. By calling the Sync option, the next time a computer starts or a user logs on to a machine, all applicable GPOs process synchronously (one after the other) rather than in parallel.

This feature is useful if you suspect that asynchronous processing is causing problems and you need to test that fact.

Finally, it’s important to note that even though secedit and gpupdate provide command-line mechanisms for refreshing policy, such refreshes are still logged in the Application event log as they would be during normal GPO processing.

Q 6.4: Can I create a tool that gives me a consolidated view of all my Group Policy Objects at once?

A:

Yes, using the features of the Microsoft Management Console (MMC), you can easily create a tool that gives you access to all of your Group Policy Objects (GPOs) within a single view. I find it very useful to be able to have a single view of all the GPOs that I need to manage, regardless of where they’re linked within my Active Directory (AD) infrastructure. As you know, using the Active Directory Users and Computers or AD Sites and Services MMC snap-in tools, you usually have to hunt around to get to each GPO in which you’re interested. By

creating a custom MMC console that shows all the relevant GPOs in a single view, you can save time and ensure that you are always working on the right GPOs. The following step-by-step instructions describe how you can create such a tool:

1. To begin, open a blank MMC console by typing mmc

from the Start menu Run dialog box in either Windows 2000 (Win2K) or Windows XP.

2. From the Console menu in Win2K (File menu in Windows XP), choose Add/Remove Snap-in, then click Add.

3. Scroll down the list of available snap-ins to the Group Policy snap-in, and click Add.

4. When you get to the Select Group Policy dialog box, click Browse to search for a GPO in your AD. If you don’t know where the GPO(s) of interest are linked, choose the All tab to show all GPOs defined in AD (see Figure 6.4).

Figure 6.4: Viewing all GPOs defined in an AD domain.

5. Select a GPO to add from the list, and click OK, then click Finish.

6. Before returning to the console, add another Group Policy add-in, and repeat Steps 4 and 5 for the rest of the GPOs you want to manage.

7. When you’ve added all instances of GPOs to manage, click OK from the Add/Remove

8. The final step is to save your tool. From the Console menu (or File menu in Windows XP), choose Save, then give the tool a name. The resulting file will have an .msc extension.

Figure 6.5 shows a consolidated GPO management tool (called MYGPOs.msc) that I created.

Figure 6.5: Viewing a consolidated GPO management tool using the MMC.

As you can see in Figure 6.5, I have five GPOs loaded in my tool. Each of these GPOs may be, and indeed are, linked at different levels of the AD hierarchy but are visible and available to me within this single MMC window. I can expand and edit each GPO as I would normally, and have all the GPOs of interest available next to the others if I need to compare one or the other. I can also use the MMC’s Favorites feature to store frequently used views of each of the GPOs.

For example, let’s suppose that I frequently need to go in and modify the user-specific Windows Explorer policies within the Administrative Templates policy in the Desktop Lockdown GPO. I can create a favorite that takes me quickly to this policy item by first expanding into the required node (in this case User Configuration, Administrative Templates, Windows Components,

Windows Explorer). Then, from the Favorites menu on the MMC toolbar, I can choose Add Favorites to add this policy item to the Favorites list (see Figure 6.6).

I can use this favorites feature for any type of policy within my console tool. After I’ve created my favorites, I can use the Favorites tab to navigate quickly and easily right to the policy item I need to edit. For example, in Figure 6.7, I’ve created three favorites, which I’ve named first by identifying the GPO, then by the policy item.

Figure 6.7: Using MMC favorites to navigate quickly to policy items of interest.

As you can see in Figure 6.7, the actual policy items appear in the right-hand results pane when I highlight each favorite. This feature is super handy for frequently edited GPO settings, and I highly recommend pre-creating these custom MMC tools for GPO administrators. It will make your lives much easier over time!

Q 6.5: Do I have any control over how quickly the SYSVOL (Group Policy Template) portion of a Group Policy Object is replicated to other domain controllers?

A:

The short answer to this question is that you have limited control over SYSVOL replication, as compared with Active Directory (AD) replication. The File Replication Services (FRS) is used to replicate SYSVOL to domain controllers in an AD domain. FRS relies on inter- and intra-site AD connection objects that are built by the Knowledge Consistency Checker (KCC) to replicate content between domain controllers. However, FRS content will not necessarily replicate on the same schedule as AD objects. Often, between domain controllers within sites, file replication happens very quickly, as soon as a file has changed and the domain controller has notified its replication partners. Between sites, replication is typically scheduled based on the Site Link configuration found in the Microsoft Management Console (MMC) AD Sites and Services snap-in tool. Dependsnap-ing upon how many files have changed and the schedule you’ve created for AD site links, you might experience delays before FRS data is in sync everywhere.

Unfortunately, you don’t have much control over the actual replication topology or the schedule that is used to replicate changes. Unlike AD replication, for which you can use the AD Sites and Services snap-in to force a replication trigger between domain controllers, FRS doesn’t provide

2000 (Win2K) Service Pack 2 (SP2), FRS does not compress file changes when replicating between sites, as AD does.

What little you can tweak in FRS is the schedule as to when FRS replication can and cannot occur. To change this schedule, open the Active Directory Users and Computers MMC snap-in, make sure that the Advanced view is enabled, and within your AD domain, drill into System\File Replication\Domain System Volume (SYSVOL Share). If you right-click this node and select Properties from the context menu, the system will present you with the SYSVOL properties

In document Windows 2000 Group Policy (Page 127-148)