realtimepublishers.

com

tm

Tips and Tricks Guide To

tm

Windows 2000 Group Policy

Darren Mar-Elia

Volume 5 Note to Reader: This book presents tips and tricks for eight Windows 2000 and Windows XP Group Policy topics. For ease of use, the questions and their solutions are divided into chapters based on topic, and each question is numbered based on the chapter, including: Chapter 1: GPOs vs. NT 4.0 System Policies Chapter 2: How GPOs Work Chapter 3: Creating and Editing GPOs Chapter 4: Designing a GPO Infrastructure Chapter 5: Administering and Delegating GPOs Chapter 6: Tools for Managing GPOs Chapter 7: Advanced GPO Features and Functions Chapter 8: Troubleshooting GPOs.

Chapter 1: GPOs vs. NT 4.0 System Policies..................................................................................1 Q 1.5: Can Windows 2000 or Windows XP clients process both Windows NT 4.0 System Policies and Group Policy Objects?.................................................................................................1 Chapter 2: How GPOs Work ...........................................................................................................2 Q 2.5: Why are changes to Group Policy Objects always written first to the PDC emulator in Active Directory?.............................................................................................................................2 Chapter 3: Creating and Editing GPOs............................................................................................5 Q 3.5: How can I distribute Group Policy Object changes in a non-Active Directory environment?....................................................................................................................................5 Chapter 4: Designing a GPO Infrastructure.....................................................................................7 Q 4.5: What is the best scheme for allowing my organizational unit administrators to create and edit Group Policy Objects? ..............................................................................................................7 Chapter 5: Administering and Delegating GPOs...........................................................................10 Q 5.5: How can I audit who has made a change to a Group Policy Object? .................................10 Chapter 6: Tools for Managing GPOs ...........................................................................................16 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? .................................................16 Chapter 7: Advanced GPO Features and Functions ......................................................................18 Q 7.5: Can a client machine disable the processing of a Group Policy Object?............................18 Chapter 8: Troubleshooting GPOs.................................................................................................20 Q 8.5: Why am I having trouble enabling security policy such as auditing and event log settings on my domain controllers?.............................................................................................................20

Volume 5

Chapter 1: GPOs vs. NT 4.0 System Policies

Q 1.5: Can Windows 2000 or Windows XP clients process both Windows NT 4.0 System Policies and Group Policy Objects? A: Windows 2000 (Win2K) and Windows XP can process both Group Policy Objects (GPOs)
and Windows NT 4.0 System Policies. However, the rules for which gets processed when depends upon where user and machine accounts reside. An NT 4.0 System Policy file (for example, ntconfig.pol) is only applied when the corresponding user or machine accounts still reside within an NT 4.0 domain. For example, many enterprises, in the midst of migrating from NT 4.0 to Win2K AD, migrate user accounts into Active Directory (AD) but leave machine accounts in NT 4.0 resource domains. In such cases, any computerspecific System Policies (policies that make changes in the registry to HKEY_LOCAL_MACHINE) that youve created in your NT 4.0 domains are applied to the Win2K or Windows XP machine when the AD user logs onto the AD domain from that workstation. However, no user-specific NT 4.0 System Policy settings are processed if the user account resides in an AD domain. To better understand this concept, lets explore the scenario that Figure 1.16 illustrates.

Figure 1.16: Viewing a mixed NT 4.0 and AD environment.

Volume 5 In the example that Figure 1.16 shows, we have a Win2K client machine whose machine account resides in the NT 4.0 domain called Sales. There is a user named Bob, who has an account defined in the AD domain called myorg.tld. Bob logs onto the Win2K client workstation in Sales. Which policies will Bob receive? Because the machine account of the workstation on which Bob is logging on is in an NT 4.0 domain, as soon as Bob logs onto that machine, any machine-specific NT 4.0 System Policy file that exists in the Netlogon share on the myorg.tld AD domain controllers will be processed.
Even on a Win2K or Windows XP client, a user must log onto the machine before the NT 4.0 System Policy is processed. This requirement contrasts machine-specific GPO policy, which only requires a machine restart to trigger processing. In addition, the ntconfig.pol file must reside on the domain controllers of the authentication domainin this case, an AD domain called myorg.tld.

In the previous example, only computer-specific System Policy will be processed. If a Default Computer or machine-specific policy has been defined in the NT 4.0 System Policy, that policy will be processed. No user-specific System Policy will be read, even if it is defined, because the user account in this example resides in an AD domain, and thus will only process user-specific Group Policy. Its also worth noting that if an NT 4.0 user account logs onto a Win2K or Windows XP machine that resides in an NT 4.0 domain, no GPOs (other than the local machine GPO) are processed only NT 4.0 System Policy is processed. Also remember that if you want NT 4.0 System Policy to be processed in a mixed AD and NT 4.0 domain environment, you need to make sure that your policy filentconfig.polis found in the Netlogon share of the domain controllers in the authentication domain (the myorg.tld domain in the previous example). On NT 4.0 domain controllers, this location is typically in %systemroot%\system32\repl\import\scripts. On AD domain controllers, Netlogon is shared only for backward compatibility as part of the replicated SYSVOL structure and can be found under %systemroot%\sysvol\sysvol\<domain name>\scripts. If you place your ntconfig.pol files in this folder, they will automatically be replicated to other AD domain controllers in the domain. Finally, if you decide that you dont want NT 4.0 System Policies to be processed for certain machines or users, you can always disable System Policy processing by changing the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update\UpdateMode registry subkey from 1 to 0.

Chapter 2: How GPOs Work

Q 2.5: Why are changes to Group Policy Objects always written first to the PDC emulator in Active Directory? A: Because it is possible for two people, working in different geographic regions, to write
changes to a single Group Policy Object (GPO) from two different domain controllers, Microsoft sought to provide a way to minimize collisions. By default, when you open the Microsoft Management Console (MMC) Group Policy snap-in focused on an Active Directory (AD)-based GPO, the copy of the GPO you are actually editing resides on the PDC emulator domain controller in your AD domain. The reason is that the GPO editor tool will always try to edit the copy of a GPO on the PDC emulator for that domain to limit collisions between two people
2

Volume 5 editing the same GPO. For example, if a systems administrator in New York and a systems administrator in San Francisco both try to edit the Default Domain Policy at the same time, they will both be focused on the PDC emulator domain controller to make the change. In that case, the first user to edit the GPO will put a lock on that GPO. When the second user attempts to edit that same GPO, the user will get an error message similar to the one that Figure 2.11 shows.

Figure 2.11: Viewing the error received when two people try to edit the same GPO at the same time.

This setup is a good thing because it ensures that two people editing the same GPO cant overwrite each others changes, which is especially important if the changes being edited are security policies. You can actually see which domain controller you are currently focused on while editing a GPO from the MMC Group Policy snap-in tool. The current domain controller will appear in brackets to the right of the GPO name in the left pane of the tool (see Figure 2.12).

Figure 2.12: Viewing the currently focused domain controller (yquem.mar-elia.com) while editing a GPO.

However, there may be circumstances in which you want to override this behavior and edit a GPO while focused on a different AD domain controller. In such a case, you change which domain controller the Group Policy MMC tool focuses on when you edit GPOs by choosing View, Domain Controller Options from the MMC menu. Figure 2.13 shows the list of your options.
3

Volume 5

Figure 2.13: Viewing the options for focusing editing of GPOs.

As you can see in Figure 2.13, the default choice is to connect to the PDC emulator. However, you can choose the second option, which will connect to whichever domain controller your Active Directory Users and Computers or AD Sites and Services MMC tools are currently focused on. Typically, when you open these tools, they connect to the closest domain controller to you, which is normally a domain controller within the same AD site as your administrative workstation. If you select the third choice, the next time you open the Group Policy MMC snapin, the tool will randomly select a domain controller to connect to within the same site from which youre connecting.
When you choose any of these three options, you need to stop and restart your Group Policy tool for the changes to take effect. In addition, the changes are in effect only for the Group Policy MMC snapin on the machine on which you make the change. The choice does not follow your user ID to another machine unless you have a Group Policy Administrative Template policy in place to enforce the choice across a group of users or machines.

A good practice is to not mess with this setting unless you have a really good reason. One good reason for focusing a GPO editor on a different domain controller is if the PDC emulator domain controller is currently down or unavailable and you need to make quick changes to a GPO.
You can easily determine which domain controller in your AD domain currently holds the PDC emulator role by using the netdom.exe utility that comes with the Windows 2000 (Win2K) Support Tools. To use netdom.exe to determine the current PDC emulator, type: Netdom query fsmo Where fsmo is the acronym for floating single master operationthe original name for the operations masters roles. When you type this command, the utility will return all five role holders within your current domain and forest: Schema owner Domain role owner PDC role RID pool manager Infrastructure owner yquem.mar-elia.com yquem.mar-elia.com yquem.mar-elia.com yquem.mar-elia.com yquem.mar-elia.com

The command completed successfully. In this case, all five roles are held by one domain controller, which is generally not a good thing!

Volume 5

Chapter 3: Creating and Editing GPOs

Q 3.5: How can I distribute Group Policy Object changes in a nonActive Directory environment? A: Ordinarily, changes to Group Policy Objects (GPOs) rely on an Active Directory (AD)
infrastructure to propagate to and policy all users and machines in a domain or forest. However, there is some allowance for manually distributing some GPO policy to non-AD domain-based machines. As you know, every Windows 2000 (Win2K) and Windows XP system has a local GPO that contains a subset of the policy settings and capabilities available on AD-based GPOs; however, software installation and folder redirection are not supported in local GPOs. Notwithstanding these missing pieces, local Group Policy has many of the important features you might want or need on nonADbased machines (for example, security and administrative templates). There might also be compelling reasons why you dont want to put a particular Win2K or Windows XP machine in an AD domain. For example, many enterprises often opt not to create a domain when they place Win2K servers on DMZ segments exposed to the Internet. In such cases, you can choose not to deploy AD, but you might still want to leverage Group Policy to configure a group of machines. So what can you do? The solution is actually quite simpleyou can copy the contents of a local GPO between machines to ensure that policy changes are deployed consistently across many nonADbased machines. First, you need to know where the policy files for the local GPO are stored. On both Win2K and Windows XP systems, the local GPO can be found in %systemroot%\system32\GroupPolicy. As you can see in Figure 3.10, the contents of the local GPO look very similar to what you find in the Group Policy Template (GPT) portion of an AD-based GPO. (In Windows Explorer, the %systemroot%\system32\Group Policy folder is hidden by default. Make sure you enable the option to view hidden files and folders to see this folder.).

Figure 3.10: Viewing the contents of a local GPO on a Windows XP workstation.

Volume 5 As Figure 3.10 shows, the local GPO contains three folders and a file. The gpt.ini file holds the current version information for the local GPO. The Adm folder holds the .adm template files in use for this GPO. The Machine and User folders contain the current policy settings for this local GPO for the computer and user configuration portions of the GPO. If you drill into both the Machine and User folders, you will find the registry.pol file that contains the current Administrative Template settings as well as other folders for startup and shutdown or logon and logoff scripts and Internet Explorer (IE) maintenance and remote installation options. What you wont find is a file corresponding to per-machine security settings such as account policy, local user rights, or password lockout. The reason is that, unlike Administrative Template policy, which is stored in the registry.pol file, changes to local GPO security settings are made against the live Security Account Manager (SAM) database that resides on the machine. Therefore, as we discuss how to copy local GPO settings from one machine to another, you wont be able to copy security settings across machines using the same mechanism. Indeed, the only way to copy security settings across machines in a non-AD environment is to use a mechanism such as the Microsoft Management Console (MMC)-based Security Configuration and Analysis tool, or its companion command-line versionthe secedit.exe utility. For our example, lets suppose you want to copy Administrative Template policy settings to a group of non-AD machines. The process is fairly straightforward. First, you need to ensure that you have the Administrative Template settings that you desire on your prototype machine. The easiest and quickest way to edit the local GPO is to type gpedit.msc from the Start menu Run text box. Doing so will bring up an MMC tool focused on the local GPO. Next, youll need to edit the Administrative Template policy as you want it to appear on all machines. Make note as to whether youre editing computer-specific policy, user-specific policy, or both. After you finish editing the policies, youre ready to copy your prototype settings to the destination machines. If you edited computer-specific policy only, you will need to copy only the registry.pol file from %systemroot%\system32\GroupPolicy\machine. If you also edited the userspecific policy or only edited the user-specific policy, youll need to copy registry.pol from %systemroot%\system32\GroupPolicy\user. In either case, copy the required registry.pol file from the folders on your source machine to the identical folders on all target machines. Any existing Administrative Template policy set locally on the target machines will be overwritten when you copy the new files. If you created any custom .adm template files on your source machine, youll need to copy them to the target computer(s) in addition to copying the registry.pol files. This step is important to remember because after youve copied the policy files to the target machines, if anyone were to edit those local GPOs, they would not see all the correct policy settings if the adm files that were used to create the source GPO are missing. Copy any custom .adm files from %systemroot%\system32\GroupPolicy\adm to the same folder on the target machine. Then, when an administrator edits the local GPO on the target machines, the administrator will need to ensure that the custom .adm file is loaded. There is one more piece of the puzzle that needs to be completed before your copied policy is functional. Local GPOs keep version information about themselves just as AD-based GPOs do. This information is kept in the gpt.ini file in the root of the local GPO folder. If the version number held in this file (shown as Version in Listing 3.1) is 0, local GPO processing will be skipped during machine startup or user logon. Such is typically the case on new Win2K and Windows XP machines.

Volume 5
[General] gPCFunctionalityVersion=2 gPCMachineExtensionNames=[{35378EAC-683F-11D2-A89A00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{53D6AB1D-2488-11D1A28C-00C04FB94F17}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1D2488-11D1-A28C-00C04FB94F17}] Version=196639 gPCUserExtensionNames=[{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE7020-11D2-842D-00C04FA372D4}][{35378EAC-683F-11D2-A89A00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}][{A2E30F80-D7DE11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}]
Listing 3.1: Viewing the contents of a local GPOs gpt.ini file.

In Listing 3.1, the version number shown is 196639. When youre copying local registry.pol files to target machines, you also need to edit the gpt.ini file on those machines to ensure that the value is not 0. Although GPOs use a fairly elaborate scheme to calculate versions (the version number is incremented 1 for each computer-specific change and 65536 for each user-specific one), you dont need to worry about whether you provide the correct version number as long as it is a non-0 value. To be safe, set the version value to 65537 (65536+1) so that both user and computer sides of the GPO have changed. This setting will ensure that the local GPO is processed on the next cycle.

Chapter 4: Designing a GPO Infrastructure

Q 4.5: What is the best scheme for allowing my organizational unit administrators to create and edit Group Policy Objects? A: Delegation of Group Policy Object (GPO) administration is a delicate balancing act. On the
one hand, you want to allow organizational unit (OU) administrators the ability to manage Group Policy within their environment. On the other hand, Group Policies that are meant for a single GPO can impact an entire Active Directory (AD) domain. Thus, its important to balance what an OU administrator can do with what is best for the AD. Remember that delegation of GPO administration falls into roughly three pieces: Delegation of the initial creation of a new GPO Delegation of editing and deletion of existing GPOs Delegation of the ability to link and unlink GPOs from container objects such as sites, domains, and OUs

To delegate the ability to create a new GPO, you must place the user or group who needs that capability in the Group Policy Creator Owners group. After the GPO has been created, the user or group needs the Read, Write, and Create All Child Objects permissions to be able to edit the GPO. Read, Write, and Delete All Child Objects permissions are required to be able to delete the GPO (see Figure 4.11).

Volume 5

Figure 4.11: Viewing a GPOs permissions that grant edit and delete capabilities.

In Figure 4.11, you see that the Finance Admins group has the ability to both edit and delete the existing GPO called Finance Admins Lockdown. The ability to link or unlink a GPO to a container object is controlled by permissions on the AD container object itself. Specifically, to link and unlink a GPO to a site, domain, or OU, the user or group needs the Read and Write gPLink and Read and Write gPOptions permissions on the object. Typically these are obtained by granting the user or group Read and Write permissions on the container object. You can also grant the gPLink and gPOptions permissions individually through the AD Access Control List (ACL) editor within the Microsoft Management Console (MMC) Active Directory Users and Computers or AD Sites and Services snap-ins. Right-click the container object in question, and choose Properties from the context menu. Then choose the Security tab to bring up the ACL editor. The easiest way to grant the Read and Write permissions I mentioned earlier is to immediately click Advanced to choose the advanced ACL editor. Then add the user or group to which you want to grant permissions, select the Properties tab, and select the appropriate permissions, as Figure 4.12 shows.

Volume 5

Figure 4.12: Granting GPO linking and unlinking permissions on a container object.

After you have worked out how to delegate the various tasks around GPO creation, maintenance, and use, the next question is, What is the best approach to use in granting these rights? The answer depends on your environment, but there are a couple of approaches that you can take. The first approach is to delegate the linking and unlinking process to only your OU administrators. In this scenario, some central group is responsible for creating and editing GPOs, then you leave it up to the OU administrator to decide which of those GPOs they want to link to their OU. For GPOs that need to be linked to the domain and site level, the central group is again responsible for handling those tasks. In this scenario, you need only delegate the linking and unlinking permissions to the OU(s) involved, and grant all creation and editing permissions to your central group. The advantage of this approach is that you have total control over the creation and editing of GPOs within your AD domain. Although GPOs can be linked to containers within a domain, they are available to the entire domain. Thus, it might be a good thing to be able to control who can create or edit GPOsespecially if you consider the worst-case scenario. Suppose you grant an OU administrator the ability to create GPOs in your AD domain. Then, either knowingly or not, that administrator decides to see how many GPOs he or she can create in your domain. Perhaps the administrator creates hundreds or even thousands! The result is that every domain controller in your AD domain will need to replicate the Group Policy Container (GPC) and Group Policy Template (GPT) for each of those GPOs. Although this situation might

Volume 5 not be a huge problem in most cases, you might have parts of your network that cant afford the extra replication overhead of such activity. To take it one step further, suppose a malicious OU administrator were to create a GPO that contains a logon script that is 5GB in size! This logon script must be replicated to all instances of the GPT on all domain controllers for that GPO. Again, not only might the network traffic bring some of your links to their knees, but in some cases, replication of this logon script could cause servers to run out of disk space. The point is that an OU administrator that has limited rights over your domain could wreak havoc over that domain if granted the ability to create or edit GPOs at will. If youre not worried about such a scenario, you could grant a select group of OU administrators the ability to create and/or edit GPOs. Or you could simply grant those administrators the ability to edit certain GPOs while keeping others off limits. (Permissioning GPOs is not an all or nothing operationyou can grant permissions to edit a select group of GPOs and leave others to the purview of your central group.) If you maintain central control over the creation of GPOs and limit the editing of certain GPOs to certain administrators, you can more easily ensure that any one administrator will not run hog wild on your AD infrastructure. Theres one more point to keep in mind as you decide who gets to do what within your GPO environment. A single GPO can be linked to multiple container objects (multiple OUs). Thus, if you have a GPO that is providing policy for multiple OUs, you need to ensure that you arent granting editing rights to each of the administrators of those OUs without requiring some kind of coordination between the two. If you dont require this kind of coordination, you could have OU administrators overwriting each others changes or making policy changes that significantly impact each others users. The simple way around this scenario: When you have GPOs that will be linked at the OU level, never share those GPOs among multiple OUs. This setup, however, means that you will have to manage more GPOs in your overall infrastructure than if you were sharing.

Chapter 5: Administering and Delegating GPOs

Q 5.5: How can I audit who has made a change to a Group Policy Object? A: Unfortunately, one of the limits of the Group Policy Object (GPO) infrastructure is that there is no really straightforward way to audit who has made which change to a GPO. What is required is that you set up Windows security auditing on the Active Directory (AD) and SYSVOL to be able to track who has made a change to the pieces of the GPO.
It would be nice if Microsoft provided a way to audit GPO changes at the level that you think about when working with GPOs. In other words, Id like to know if Joe Admin made a change to the Desktop Lockdown GPO, and if so, what that change was. Unfortunately, as a result of the structural nature of GPOsthe fact that they are really two pieces in the Group Policy Template (GPT) and Group Policy Container (GPC)it is very difficult to audit GPO operations out-of-the-box because there isnt any one thing that you can audit. However, Ill show you how you can use native tools to achieve some level of auditing so that you can narrow who made which change to which GPO. First, you need to ensure that auditing is enabled on your AD domain controllers. Auditing is enabled on domain controllers by editing the special Default Domain Controllers Policy GPO that is installed by default in every AD installation and linked to
10

Volume 5 the Domain Controllers organizational unit (OU). To enable AD auditing, start the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, right click the Domain Controllers OU, and choose Properties from the context menu. Next, choose the Group Policy tab, highlight the Default Domain Controllers Policy, and click Edit. Within the GPO, drill into Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policies. From here, double click the Audit Directory Service Access item, select the Define these policy settings check box, then select the Success and Failure check box. (You dont have to select the Failure option, but doing so will let you know who tried but failed to access a GPO.) Figure 5.11 shows what this configuration will look like.

Figure 5.11: Enabling AD auditing on the Default Domain Controllers Policy.

After youve enabled AD auditing and this policy has replicated and been processed on all domain controllers (and especially the PDC emulator), any changes you make to your GPOs will be audited. Enabling AD auditing only effectively catches access to the GPC portion of the GPOnot the GPT. However, this level of auditing is usually effective to track who is accessing a GPO, because the GPC and GPT are automatically accessed each time you open or edit a GPO using the MMC snap-in tools. What this auditing wont catch is specific changes made to files within the GPT. For that, you need to enable the Audit Object Access item that Figure 5.11 shows, then enable auditing on the actual GPO. After youve enabled general auditing through the Default Domain Controllers Policy, you need to customize GPO auditing on a per-GPO basis to determine what kind of auditing is actually performed. By default, all GPOs are set up with the Everyone group enabled for a variety of access logging. Just to review, the process of setting up a System Access Control List (SACL)
11

Volume 5 involves telling Windows for which user or group you want to log access and which operations youre interested in logging. To access auditing settings within a GPO, you need to bring up the ACL editor on the GPO. If you are already editing the GPO, you can access the ACL editor by right-clicking the GPOs name within the MMC snap-in tool, and choosing Properties from the context menu. Next, choose the Security tab, then click Advanced. Finally, click the Auditing tab to access the auditing SACLs window (see Figure 5.12).

Figure 5.12: Viewing a GPOs SACLs (auditing settings).

If I highlight the Everyone group in the window that Figure 5.12 shows, then click View/Edit, I can see which types of AD access are being audited, as Figure 5.13 shows.

12

Volume 5

Figure 5.13: Viewing detailed AD auditing options within the ACL editor.

And, if I select the Properties tab in this dialog box, the tab will shows me which attributes on the GPC are being audited for access. If I am setting up auditing on a particular GPO that is linked to an OU, I might want to remove the Everyone entry from the auditing list and only audit access by the OU administrators who would regularly be accessing that GPO. Typically, when a change is made to a GPO with AD auditing enabled, there are event log entries written to the Security log on the domain controller on which the changes are being made (typically at the PDC emulator by default). Thus, you can go to that server after a GPO has been edited and view the logs to determine who has been in that GPO. For example, as Figure 5.14 shows, you see that the user administrator made a change to the GPC that has the GUID shown.

13

Volume 5

Figure 5.14: Viewing a security event log entry showing auditing of a GPO.

If I were to scroll down the description in the window that Figure 5.14 shows, you would see that the event shows that the administrator wrote a new value to the versionNumber attribute on that GPC. Such is the extent of the GPO auditing that is available to you within AD. You are left to determine which GPO is represented by that GUID, and what kind of change was actually made. In the latter case, you can glean a bit more info by enabling auditing on the SYSVOL portion of the file system that holds the GPT portion of a GPO. To enable file system auditing for GPOs, the best thing to do is log on to the PDC emulator in your domain and open Windows Explorer in %systemroot%\sysvol\sysvol\<domain name>, where <domain name> is the name of your AD domain. From this point, right-click the Policies folder, and choose Properties from the context menu. Next, choose the Security tab, and click Advanced. Finally, click Auditing to see what auditing has been enabled on this folder. Unlike the GPO itself, no auditing is set up by default on the Policies folder.
You can also setup auditing of the GPT on a particular GPO by drilling into the Policies folder and locating the GUID-named folder of the GPO in question.

For my example, Im going to enable auditing of the entire Policies folder for the group called Finance Admins. When I add this group to my list, I am taken to the list of available auditing options, from which I can choose which kinds of access to audit. As Figure 5.15 shows, I am most interested in auditing the activities that would cause a change in the files or folders that exist in the GPT for a given GPO, so Ive selected the four entries shown.

14

Volume 5

Figure 5.15: Viewing options for enabling SYSVOL auditing of GPT changes.

After I enable this auditing on SYSVOL, any changes that a user makes to a GPO are tracked in the Security event log on all domain controllers in the domain, starting with the PDC emulator. In Figure 5.16, the user jadmin, a member of the Finance Admins group, made a change on a GPO that is recorded in the event log on the PDC emulator.

15

Volume 5

Figure 5.16: Viewing an audit event generated on SYSVOL by a GPO change.

As you can see from the event, the user accessed and made some kind of change to the registry.pol file under the user subfolder of the GPT. This description tells me that jadmin made a per-user Administrative Template policy change to this GPO, though it does not tell me what the change was.

Chapter 6: Tools for Managing GPOs

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
16

Volume 5 configuration found in the Microsoft Management Console (MMC) AD Sites and Services snapin tool. Depending upon how many files have changed and the schedule youve created for AD site links, you might experience delays before FRS data is in sync everywhere. Unfortunately, you dont 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 doesnt provide that kind of interface. You are pretty much at the mercy of FRS to replicate SYSVOL content when files change and based on your AD site topology. Also be aware that prior to Windows 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 dialog box. In this window, click Change Schedule to bring up the SYSVOL schedule, as Figure 6.8 shows.

Figure 6.8: Viewing the FRS replication schedule for SYSVOL.

If you select a square or range of squares in the window that Figure 6.8 shows, you can toggle replication on or off during certain times of the day. This feature gives you some flexibility if youre replicating large numbers of SYSVOL changes and have slow links that you want to remain available during business hours. You could schedule SYSVOL replication to happen after hours in that case. Of course, that means that any changes you make to your GPOs would not be synchronized across all domain controllers until SYSVOL replication is allowed to happen.

17

Volume 5 There is also a utility that you can use to check the status of FRS replication. It is called ntfrsutl.exe and is included in the Win2K resource kit. This tool lets you view the metadata on a particular domain controller to see its state and the state of replication on that server.
Ntfrsutl.exe was updated in Win2K SP2 with some improvements for getting information from FRS. To get this version, you need to extract the full SP2 installation using the /x command, then copy the new version of the utility over the old one.

Chapter 7: Advanced GPO Features and Functions

Q 7.5: Can a client machine disable the processing of a Group Policy Object? A: There is no switch or registry entry that you can throw to easily disable Group Policy Object
(GPO) processing for a machine in an Active Directory (AD) domain that is destined to receive GPOs. However, there are some drastic steps that you can take to disable some or all GPO processing. To understand how you can disable GPO processing, we will explore how GPOs are actually processed. The real workhorse of GPO processing actually resides on the client side. That is, although AD domain controllers house the Group Policy Container (GPC) and Group Policy Template (GPT) that contain the actual policy settings for a given GPO, the code on the client Windows 2000 (Win2K) or Windows XPactually reads those settings and does something with them. That code is called a Client Side Extension (CSE), and is found by default on every Win2K and Windows XP workstation. CSEs are implemented as dynamic-link libraries (DLLs) and are typically found in %systemroot%\system32 on a machine. Win2K and Windows XP also keep a list of registered CSEs for a given machine within the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. Each CSE is registered as a key under the GPExtensions key, as Figure 7.16 shows.

18

Volume 5

Figure 7.16: Viewing registered CSEs on a Win2K machine.

As you might also notice from Figure 7/16, each CSE also keeps a set of default behaviors that control how it processes GPOs. For example, the NoGPOListChanges value controls whether that CSE will process a GPO even if its version number has not changed since the last processing cycle. Win2K and Windows XP use this list of CSEs in the registry to determine which policy features to process. Thus, in Figure 7.16, if I were to delete the key shown, which, as you can see from the right pane of the registry editor, controls the Folder Redirection feature, that workstation would no longer be able to process Folder Redirection policy. The same holds true for other policy processing. If I delete the key that begins with {8273D19E, I will be disabling security policy processing on that workstation, and thus preventing any security policy from being passed down to the workstation.
You must be an administrator on the local machine to actually delete these keys. Thus, as long as youre not granting users administrative access to your workstations, they wont be able to use this mechanism to foil your security and other GPO-based controls.

There are better ways to prevent a workstation from processing a GPO. As an administrator, you can permission the GPO such that the user or machine does not ever get to process the policy. However, there may be circumstances in which, from the client side, you might need to disable some or all GPO features. By manipulating which CSEs are registered on a workstation or server, you can control which policy features are processed.

19

Volume 5

Chapter 8: Troubleshooting GPOs

Q 8.5: Why am I having trouble enabling security policy such as auditing and event log settings on my domain controllers? A: There is an interesting interplay between the built-in Default Domain Policy and Default Domain Controllers Policy that can cause confusion when trying to enforce domain-wide security policy. Security policy is a tremendous source of confusion within Active Directory (AD), and the cause of many perceived problems. However, the rules are fairly straightforward, and as long as you stay mindful of them, you wont have any problems.
The first rule is: Domain-wide account policy can only be set at a Group Policy Object (GPO) linked to the domain. Typically the Default Domain Policy is used to set account policy because Default Domain Policy is a special system GPO and can never be deleted. However, you can set account policy in any GPO that is linked at the domain level. Domain controllers, regardless of where they reside in your AD (within the Domain Controllers organizational unit OUor elsewhere), will only look to domain-linked GPOs to get their account policy. You can set other account policy for member servers elsewhere in your AD infrastructure, but domain controllers will only respect domain-linked account policy. The second rule is just as useful: By default, the Domain Controllers OU is set to block policy inheritance (see Figure 8.11), meaning that no upstream GPOs can override security policy set within GPOs linked to this OU.

Figure 8.11: Viewing the Block Policy Inheritance feature enabled on the Domain Controllers OU.

20

Volume 5 The exception to this rule is the first ruleAccount policy cannot be set at the Domain Controllers OU level, only at the domain level. All other security policy for the domain should be set in the Default Domain Controllers Policy GPO or another GPO linked to the Domain Controllers OU, including audit policy, event log policy, services security, and so on. The bottom line is that if you try to enable local policies such as auditing for your domain on any GPO other than the ones linked to the Domain Controllers OU, those policies will never be processed due to the Block Policy Inheritance check box being selected on that OU. You will save yourself a lot of troubleshooting time trying to figure out why youre domain controllers dont have auditing enabled by setting auditing policy on a GPO linked to the Domain Controllers OU. You might think that you can simply disable the Block Policy Inheritance option on the Domain Controllers OU to allow security policy to be set elsewhere. In fact, you cant! If you disable this option, security policy processing on domain controllers in that OU will simply fail with an SCECLI event and error flag of 81 (as the Application event log with verbose GPO logging enabled will show). This feature prevents any rogue GPOs upstream from the Domain Controllers OU from undoing any local security policy for your entire domain. But it can cause confusion when you believe that youre disabling the Block Policy Inheritance feature and the only error you get is that none of your upstream policies seem to be applied.

21

Volume 5

Copyright Statement
2002 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtimepublishers.com, Inc. (the Materials) and this site and any such Materials are protected by international copyright and trademark laws. THE MATERIALS ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials, including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials. The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice. The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties. If you have any questions about these terms, or if you would like information about licensing materials from Realtimepublishers.com, please contact us via e-mail at info@realtimepublishers.com

22