• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Group Policy Operational Overview

    Computer policies have a lot in common with corporate policies. As anyone from the HR department will tell you, a corporate policy can only be effective if it meets a few guidelines:

    • The policy must be in a form that can be clearly and simply communicated to the recipient.

    • The action required by the policy must fit the capabilities of the recipient.

    • The recipient must be reminded frequently of the policy so that observance does not lapse.

    The discussion in the next few sections examines how group policies in Windows Server 2003 meet these guidelines.

    Purpose of Group Policies

    At their simplest level, group policies provide a way to efficiently manage large numbers of computers. An exact definition of "manage" can be a little elusive. For example, business schools teach that people cannot truly be "managed." They may allow themselves to be guided, goaded, cajoled, or dragged in the direction of a particular goal, but they never lose their waywardness.

    Computers are more malleable than people, but the principle remains the same. You don't manage computers; they let themselves be managed. As you'll see, each Windows Server 2003, Windows XP, and Windows 2000 client has a set of services that know how to process the instructions distributed in group policies. It is up to you as administrators to get the right instructions to the right clients at the right time.

    In the next few sections, you'll see how group policies are generated, how clients know where to find them, how they are downloaded, and what happens when they are processed. Armed with this information, you'll then see how to implement each type of policy and how to troubleshoot them if they don't work as advertised.

    Group Policy Components

    Group policy deployment in an enterprise quickly becomes a maze of twisty little passages, all different. In my opinion, Microsoft made this adventure much harder than necessary by attaching a lot of highfalutin terminology to group policy components. I'll give a brief introduction to each one and then examine them in detail.

    • Group Policy Object (GPO). Don't bother searching through Active Directory looking for an "object" with a name or class of GPO. Microsoft uses the term Group Policy Object as an umbrella to identify the two components of a group policy: the Group Policy Container and the Group Policy Template. Container objects in Active Directory such as sites, domains, and organizational units (OUs) can be linked to a GPO. This applies the GPO settings to user and computer objects under that container.

    • Group Policy Template(GPT). A GPT is the set of instructions that implements a set of policies. For example, policies that update the Registry are stored in a GPT file called Registry.pol. File-based GPTs are stored in policy folders under the Sysvol folder on each domain controller. Figure 12.1 shows an example.

      Figure 12.1. Typical Sysvol folder showing group policy folders and a Group Policy Template (GPT) file.


    • Group Policy Container(GPC). A GPC is an Active Directory object that lists the names of the GPTs associated with a particular GPO. Windows clients use the information in a GPC to determine which GPTs to download and process. (Microsoft documentation sometimes uses the terms GPO and GPC interchangeably.)

    • Client-side extensions (CSE). Various functions at a Windows client can be managed by group policies. These functions have services that know how to obtain and process group policies targeted at them. These services are called client-side extensions, or CSEs, and they come in the form of Dynamic Link Libraries, or DLLs. For example, folder redirection policies are processed by a CSE called Fdeploy.dll.

    • Group Policy Editor(GPE). The GPE is an MMC (Microsoft management console) snap-in that creates and manages GPOs. Figure 12.2 shows the GPE for the Default Domain Policy, one of two GPOs installed in every domain.

      Figure 12.2. Group Policy Editor console showing the contents of the Default Domain Policy.


    • Computer policies and user policies. Policy settings in a GPO can apply to either computer objects or user objects. Computers download their policies when they start up. Users download their policies when they log on to the domain. Much of the complexity in deploying group policies comes from the dual nature of the GPO.

    • Group policies and local policies. Not all policies are downloaded from the domain. Each client has its own stockpile of local policies that take effect when the machine is not a member of a domain or when a user logs on to the local SAM (Security Account Manager database) rather than logging on to a domain.

    Now let's look at the operational details of these components to get a better idea of how they work together to support group policy creation, deployment, and management.

    Group Policy Objects

    The term Group Policy Object is an umbrella phrase that references the two constituents of a group policy: Group Policy Containers (GPCs) and Group Policy Templates (GPTs). It's convenient to think of a GPO as an independent entity simply because these two pieces should always be synchronized.

    Viewing and Modifying GPOs

    You can view the GPOs linked to a particular Active Directory container by opening the Properties window for the container in AD Users and Computers (or AD Sites and Services, in the case of site policies) and selecting the Group Policy tab. Figure 12.3 shows the GPO list for an example OU.

    Figure 12.3. Properties window for an OU showing the group policy list.


    Every Active Directory domain has two default GPOs:

    • Default Domain GPO. This GPO contains security settings that affect all the computers in a domain. The GPO is linked to the Domain object.

    • Default Domain Controller GPO. This GPO contains security settings and configuration settings that affect domain controllers. The GPO is linked to the Domain Controllers OU.

    Ordinarily, group policies affect only those objects in the container linked to the GPO (or any child containers, thanks to inheritance). The Default Domain Controller GPO policies work a little differently. This GPO contains many critical security policy settings that are vital to the proper operation of a domain controller. Therefore, the Default Domain Controller GPO policies literally chase down domain controller objects wherever they sit in Active Directory. The Domain Controller OU only acts as an anchor point for the GPO.

    Applying Group Policies with GPUPDATE

    Ordinarily, a new User-side group policy does not take effect until the user logs off and back on, and a new Computer-side group policy does not take effect until you restart the computer. Group policies are also applied in the background as part of a periodic refresh.

    If you want to apply a new group policy immediately, you can do so using the GPUPDATE utility. Just open a command prompt and enter gpupdate. This utility replaces the special Secedit switches used in Windows 2000 to apply group policies. You can specify User or Computer-side policies with the /target switch with the syntax gpupdate /target:user or gpupdate /target:computer.

    If you apply a User-side group policy that requires a logoff/logon to actually see the policy take effect, you can use the /logoff switch with the syntax gpupdate /target:user /logoff. If the policies applied during this update do not affect a client-side extension that requires a logoff, then no logoff is performed.

    If you apply a Computer-side group policy that requires a restart to actually see the policy take effect, you can use the /boot switch with the syntax gpupdate /target:computer /boot. If the policies applied during this update do not affect a client-side extension that requires a restart, then no restart is performed.

    The GPUPDATE utility normally only downloads and applies group policies that have changed since the last download. This conserves bandwidth. If you want to download and apply all policies, use the /force switch with the syntax gpupdate /force.

    GPO Version Numbers

    The system tracks changes to a GPO by incrementing a version number attribute each time the GPO is changed. This version number has an interesting format because the system tracks updates to Computer Configuration policies separately from updates to User Configuration policies with the same version number. Here is the convention used to increment the GPO version number:

    • When you make a change to a Computer Configuration policy setting, the GPO version number increments by 1.

    • When you make a change to a User Configuration policy setting, the GPO version number increments by 65536.

    The system identifies the two components of the GPO version number as a revision level for each component. When a client evaluates the GPO version number, it first divides the value by 65536. The result is the User revision level. The remainder is the Computer revision level. For example, a GPO version number of 131075 would yield a User revision level of 2 and a Computer revision level of 3.

    You can view the revision levels associated with a GPO by opening the Properties window for a GPO. Figure 12.4 shows an example.

    Figure 12.4. GPO Properties window showing revision levels for both parts of a GPO.


    GPO Version Number Storage

    There is no actual GPO to store the version number. A GPO consists of a GPC and a GPT, and a copy of the version number is stored in each as follows:

    • The GPC object in Active Directory stores the version number in a VersionNumber attribute. Here is a partial attribute list from a GPC that shows this attribute:

      versionNumber: 65538;
      gPCFunctionalityVersion: 2;
      gPCFileSysPath: \\company.com\SysVol\company.com\Policies\
      gPCMachineExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}
      gPCUserExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}
      gPCWQLFilter: [company.com;{F76FB374-E3B3-434E-953D-0FDDFB634FCF};0];
    • The GPT version number is stored in a Gpt.ini file at the root of the policy folder in Sysvol. Here is a sample listing:

    Troubleshooting GPO Synchronization

    The GPC and GPT version numbers should always be the same within the same GPO. And the contents of the two GPO components should always be the same on any given domain controller. Any persistent difference means that a replication error has occurred.

    The GPT and GPC version numbers can differ for a short time thanks to the different replication methods used to propagate changes:

    • GPC changes are replicated using the Active Directory (AD) replication engine. Updates take as much as 15 minutes to propagate within a site and up to 3 hours to propagate between sites.

    • GPT changes in Sysvol are replicated using the File Replication Service (FRS). The FRS works much more quickly than AD replication. Under most circumstances, changes to Sysvol are replicated immediately.

    To avoid problems caused by the slow GPC replication in relation to the GPT updates, a client downloads the contents of an updated GPT even if the version number does not match the associated GPC. This means there is no overt indication of a discrepancy between GPC and GPT version numbers. You need to check the version numbers periodically.

    The best utility for tracking down version discrepancies between GPT and GPC, and discrepancies between the GPO contents of separate domain controllers, is GPOTOOL from the Resource Kit. You should run this utility each night using the Task Scheduler and save the results to a file that you review the next day.

    For a quick consistency check of GPC and GPT version numbers, you can use the Replication Monitor (Replmon) utility from the Support Tools. Right-click the server icon and select SHOW GROUP POLICY OBJECT STATUS from the flyout menu. Figure 12.5 shows an example.

    Figure 12.5. GPO synchronization status shown by Replmon.


    Diagnostic Logging for the File Replication Service

    If you think your problems with maintaining consistency between GPT and GPC versions between domain controllers is due to a failure of the File Replication Service, try enabling debug logging for FRS. This requires a Registry change. Add the following value (a data entry of 5 imposes the most complete logging):

    Key:   HKLM | System | CurrentControlSet | Services  NtFrs | 
    Value: DebugLogSeverity (REG_DWORD)
    Data:  5

    Client-Side Extensions

    If you're a parent or you were raised by a parent or you know a parent (did I miss anyone?), you have a pretty good idea of how group policies operate.

    When you tell a five-year-old, "Don't scuff your shoes in the dirt," you expect the shoe-scuffing behavior to stop pretty darned quick. You don't need to explain how to lift the feet higher or how to maintain balance while one foot is farther from the ground than the other because the child already possesses these skills. Your short, simple directive should elicit the desired behavior. (See the troubleshooting topics scattered throughout this chapter for advice on what to do if your computers start behaving like real five-year-olds.)

    Windows Server 2003 has 11 functions that are managed to some extent by group policies. With two exceptions, remote installation services (RIS) and software restrictions, each of these functions has a service running at the client that processes the group policies. These services are called client-side extensions, or CSEs. Each CSE runs as part of a Dynamic Link Library, or DLL. Table 12.1 lists the functions controlled by group policies and their associated CSEs.

    Table 12.1. Group Policy Types and Client-Side Extensions

    Group Policy Type

    Implementing DLL

    Administrative Templates (Registry)


    Folder redirection


    Logon/logoff (startup/shutdown) scripts


    Security settings


    Software Installation


    Disk Quotas


    EFS Recovery and PKI


    Internet Explorer Maintenance


    IP Security (IPSEC)


    Remote Installation Services (RIS)

    See Note 1

    QoS Packet Scheduling


    Software Restrictions

    See Note 2

    Wireless Networking


    Note 1: RIS policies have no client-side extension. A RIS server obtains the contents of the policy when the Binary Negotiation Layer (BINL) service gets a connection request from a RIS client. The policy determines which OSC files the RIS server will include as part of the Client Installation Wizard.

    Note 2: Software restrictions are implemented directly by the operating system in response to Registry entries put in place by the policy. There is no separate client-side extension.

    You don't need to memorize the CSEs, but it is a good idea to remember that each one has certain special handling methods for the group policies it receives. These special handling methods include the following:

    • Background refresh

    • Synchronous processing

    • Slow link processing

    • Forced updates

    • Script processing

    Following are details about the special handling methods and how to configure them.

    Registry Tip: Client-Side Extension List

    The list of client-side extensions can be found at HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon | GPExtensions.

    The list uses the ClassID (another term for GUID) to identify the CSEs. With one exception, the (Default) value of the CSE key contains the friendly name. The exception is the Administrative Templates policy, shown in bold in the list that follows, which has no default value for the key:

    {25537BA6-77A8-11D2-9B6C-0000F8080861} = Folder Redirection
    {35378EAC-683F-11D2-A89A-00C04FBBCFA2} = <Administrative 
    {3610eda5-77ef-11d2-8dc5-00c04fa31a66} = Microsoft Disk Quota
    {426031c0-0b47-4852-b0ca-ac3d37bfcb39} = QoS Packet Scheduler
    {42B5FAAE-6536-11d2-AE5A-0000F87571E3} = Scripts
    {827D319E-6EAC-11D2-A4EA-00C04F79F83A} = Security
    {A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B} = Internet Explorer 
    {B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A} = EFS recovery
    {c6dc5466-785a-11d2-84d0-00c04fb169f7} = Software Installation
    {e437bc1c-aa7d-11d2-a382-00c04f991e27} = IP Security
    {0ACDD40C-75AC-47ab-BAA0-BF6DE7E7FE63} = Wireless

    Use this list when you enable debugging to trace a problem with group policies. Some of the debug traces identify a CSE by its ClassID rather than by its friendly name.

    If you look through the CSE list in Regedit, you might notice that four of the CSEs are controlled by the same DLL. Gptext.dll contains the functions for QoS Packet Scheduler, IPSec, Wireless, and scripts. This has no operational impact, but it can be confusing when you review debug logs.

    Background Refresh

    Computer policies are applied when a computer starts up. User policies are applied when a user logs on. That seems pretty straightforward, but it's only half the story. Policies can change throughout the workday, and you don't want to force your users to log off or restart. For this reason, each CSE periodically requests updates to its group policies.

    By default, domain controllers refresh their policies every 5 minutes, while member servers and desktops refresh their policies every 90 to 120 minutes. (The exact interval varies to prevent the clients from descending on their logon servers at the same time.) Two policy types do not refresh in the background because doing so would cause instability or confusion:

    • Folder redirection

    • Software distribution

    Script policies are processed during a background refresh but do not take effect until the user logs off and back on again. (Or until he stops and restarts, in the case of computer scripts.)

    Software restriction policies are refreshed in the background and take effect immediately. However, you may experience odd behavior due to the way the system implements software restrictions.

    When a client process starts, it reads the software restrictions in the Registry. It caches the restrictions to speed up subsequent processing. This means that running process will not see a new restriction until the process re-initiates. Because most applications launch from Explorer, this re-initialization generally requires a logoff. (You can stop and restart Explorer from Task Manager, but this is not something your average user is likely to do.)

    There is an exception to the logoff requirement for software restriction policies. The command-line (CMD) console works independently of Explorer, so when a new software restriction arrives in a background refresh transaction, it makes itself felt at the command line but not from the Explorer shell. This can lead to confusion, so prepare yourself for a few Help Desk calls from your power users if you implement software restriction policies.

    Synchronous Processing

    When the client-side extensions download and process their policies, they need time to do their work. Users see this as a delay in their morning logon, and one of the key design elements in Windows XP (and Windows Server 2003, though to a lesser extent) was to minimize those logon delays. To understand how Microsoft chose to minimize delays due to group policy processing, we need to take a look at the two processing alternatives:

    • Synchronous. Using this processing alternative, all client-side extensions must finish their work before control is returned to the process that called them. In the case of Computer-side policies, the calling process is Winlogon. In the case of User-side policies, the calling process is Userenv. The term "synchronous" is a little counterintuitive because you typically think of synchronous as meaning "at the same time." In this context, synchronous means that processes occur in sequence.

    • Asynchronous. Using this processing alternative, control is returned to the calling process as soon as all client-side extensions have been notified to begin processing.

    Changing the Background Refresh Interval

    You can change the default background refresh intervals with the following two group policies located under Computer Configuration | Administrative Templates | System | Group Policy:

    • Group Policy Refresh Interval for Computers

    • Group Policy Refresh Interval for Domain Controllers

    In addition to the normal 90- to 120-minute refresh interval, clients also refresh their security policies every 16 hours. During this refresh, the client downloads all security policies regardless of whether they have changed.

    Unlike the 5-minute and 90-minute background refreshes, which are controlled by values under the volatile Policies key in the Registry, the 16-hour (960-minute) refresh is hard-coded into the Registry under the Winlogon | Parameters key. The Registry entry that controls the interval is as follows:

    Key:   HKLM | Software | Microsoft | Windows NT | CurrentVersion 
    graphics/ccc.gif| Winlogon |
    GPExtensions | {82...}
    Data:  MaxNoGPOListChangesInterval
    Value: 3c0 (960)

    The end result of synchronous processing is that the user is not prompted with a logon window until all the Computer-side policies have finished processing and is not given a desktop until all User-side policies have finished processing. This is the default processing alternative for Windows 2000 except for User-side logon scripts, which are processed asynchronously.

    The end result of asynchronous processing is that the user is given a logon window while Computer-side policies are still processing, and then is given a desktop while User-side policies are being processed. This speeds up access to the desktop and is the default processing alternative in Windows XP and Windows Server 2003.

    Asynchronous processing can cause anomalous behavior if computer settings or items in the user environment rely on settings you've placed in group policies. For this reason, two policy types are singled out for special handling: folder redirection and software deployment. If you want your scripts to run in sequence, or you want them to finish before the users see their desktops, enable a group policy called Run Logon Script Synchronously.

    Be sure to test your scripts thoroughly if you enable this policy. If a script hangs, the users get log-jammed out of their desktops. The maximum processing time for each individual script is 10 minutes, and all group policies must finish within 60 minutes. That's a long time to wait on a hung script.

    The 60-minute limit cannot be modified by group policy or Registry hack. The 10-minute processing time for individual scripts can be modified with a group policy called Maximum Wait Time For Group Policy Scripts. The policy is located under Computer Configuration | Administrative Templates | System | Scripts.

    Slow Link Processing

    Just when you thought group policy deployment couldn't get more confusing, consider the plight of clients that make remote connections across a slow link such as a dial-up line or an ISDN/DSL line.

    Group Policy Processing and Network Initialization

    Another trick that Microsoft used to speed up logons was to deliver the desktop to a user prior to completely initializing the network. This significantly speeds up the logon process, but it has unfortunate side effects for group policies.

    With delayed network initialization checking, for example, you must perform two logons to implement a software deployment policy. The first sets the policy, and the second downloads the software package.

    Another example is using the advanced features in a folder redirection policy to select a particular group. In this configuration, you must perform three logons: one to set the policy, one to detect the group, and one to implement the folder redirection.

    You can revert back to standard Windows 2000 network checking behavior with the Always Wait For The Network At Computer Startup And Logon policy. This policy is located in Computer Settings | Administrative Templates | System | Logon.

    Each client-side extension has a different way of processing policies across a slow link. The following policy types are always processed regardless of the link speed:

    • Security policies (including EFS and IPSec policies)

    • Administrative Template (Registry) policies

    • Software restrictions

    The following policy types are not processed over a slow link unless specifically configured to do so:

    • Quota settings

    • Folder redirection

    • Logon/logoff (startup/shutdown) scripts

    • Internet Explorer Maintenance

    • QoS Packet Scheduling

    • Software Installation

    You can override the slow link behavior of a CSE using the Allow Processing Across A Slow Network Connection setting for the associated policy under Computer Configuration | Administrative Templates | System | Group Policy.

    Forced Updates

    By default, a client conserves bandwidth and shortens logon time by downloading and processing only group policies that have changed since the last download.

    A client determines if it has the most current GPO by checking the version number assigned to the two GPO components:

    • The Gpt.ini file at the root of the policy folder in Sysvol

    • The GPC object in Active Directory

    Changing the Slow Link Processing Cutoff Speed

    Windows Server 2003 defines a slow link as a connection running slower than 500Kbps. The system determines a connection speed by sending a series of ICMP (Internet Control Management Protocol) Echo Requests (pings) with a good-sized payload to the gateway, then measuring the return time of the Echo Reply.

    If you have users who connect to the office using a VPN (Virtual Private Network) over a fast DSL line or with a cable modem, they may exceed a 500K connect speed and download group policies. You might not want this to happen for a variety of reasons. A 500K connection is pretty fast for Internet work but painfully slow for downloading software. Also you might also not want to implement new policies on users at home where they do not have ready access to the corporate Help Desk.

    You can adjust the cutoff speed that defines a slow link using a group policy called Group Policy Slow Link Detection. The policy is located under Computer Configuration | Administrative Templates | System | Group Policy.

    Each time a client downloads the contents of a GPO, it saves the version number from the GPC. The value is stored in the Registry under HKLM | Software | Microsoft | Windows | CurrentVersion | GroupPolicy | History.

    The next time the client scans for GPOs, it examines the version number in both the Gpt.ini and the GPC. If either version number is higher than the last version number stored in the Registry, the client processes the GPO.

    You can force a client to ignore version numbers when processing GPOs. This causes the client to download all policies even if they have not changed. This is done using a group policy called Process Even If The Group Policy Objects Have Not Changed. You must specify this policy for each individual CSE. The policies for the CSEs are located under Computer Configuration | Administrative Templates | System | Group Policy.

    Script Processing

    In Windows 2000, User-side logon scripts run asynchronously even though all other policies, including Computer-side startup scripts, run synchronously. In Windows Server 2003 and XP, as we've seen, all policies run asynchronously. If you want your User-side logon scripts to finish running before the users see their desktops, enable a group policy called Run Logon Script Synchronously. The policy is located under User Settings | Administrative Templates | System | Scripts.

    Be sure to test your scripts thoroughly if you enable this policy. If a script hangs, the users will not get access to their desktops for a considerable amount of time. A script is given 10 minutes to finish. If it is still hung, the system stops processing it and continues on to the next script. If that script hangs as well, then there is another 10 minute delay.

    All group policies must finish within 60 minutes. This time limit cannot be modified by group policy or direct Registry change. You can change the 10-minute processing time for individual scripts with a group policy called Maximum Wait Time For Group Policy Scripts. The policy is located under Computer Configuration | Administrative Templates | System | Scripts.

    Group Policy Templates

    The parameters that make up a specific policy are contained in one or more Group Policy Templates, or GPTs. Most GPTs come in the form of files that are downloaded and processed by the clients. There are two exceptions. PKI policies and IPSec policies are stored directly in Active Directory. The GPT files are stored in Sysvol on each domain controller.

    Forcing Policy Processing Using the Command Line

    If you enter gpupdate/force from the command line, the client ignores version numbers and downloads all policies regardless of the CSE setting.

    With the exception of the binary .aas files used in software deployment, GPT files are simple text files. There is no rocket science at work here. Group policies do not use sophisticated client/server interactions. The client downloads a text file and does what the file says. In some ways, a Windows client is a little like Liza Dolittle in My Fair Lady when she sings

    Words! Words! Words! I'm so sick of words!
    I get words all day through;
    First from HIM, now from you!
    Is that all you blighters can do?

    Table 12.2 lists each group policy type and its associated GPT.

    Table 12.2. Group Policy Types and Their GPT Files

    Group Policy Type

    GPT File

    Registry (Administrative Templates)


    Folder redirection


    Logon/logoff (startup/shutdown) scripts

    Script.ini and the script files themselves

    Security settings


    Software deployment

    *.aas files

    Disk Quotas

    Registry.pol (Note 1)

    EFS Recovery and PKI

    Certificates stored in Active Directory (AD)

    IP Security (IPSec)

    Policies stored in AD

    Internet Explorer Maintenance


    Remote Installation Services (RIS)


    QoS Packet Scheduling

    Not Applicable

    Software restrictions

    Registry.pol (see Note 1)

    Note 1: Quota and Software restriction settings are distributed in Registry.pol, then processed separately.

    GPT Creation

    Here's an example to show how the Group Policy Editor creates GPT files. Let's say you create a GPO called Desktop Lockdown and you link this GPO to an OU called Phoenix. You define three policy settings in the GPO:

    • A Registry setting that hides the My Network Places icon on the desktop.

    • A security setting that gives authenticated users the ability to set the time on their local desktops.

    • A folder redirection setting that moves everyone's My Documents folder into a folder with the user's name under a share called \\Server\Docs.

    When you create this GPO, the GPE creates a GPC object in Active Directory and a policy folder under Sysvol\<domain_name>\Policies. It assigns the same name to the policy folder and the GPC. It derives the name using the same algorithm used to create Globally Unique Identifiers (GUIDs). This ensures that policies remain unique even if their friendly names change. The friendly name is just an attribute of the GPC object in Active Directory.

    The policy folder in this example would contain three GPT files:

    • A Registry.pol file containing a NoNetHood entry.

    • A GptTempl.inf file containing an entry that assigns SeSystemTimePrivilege to well-known SID S-1-5-11.

    • An Fdeploy.ini file with the following contents:

      My Documents=11
      [My Documents]
      s-1-1-0=\\server1\docs\%username%\My Documents

    The new policy folder and its GPT files now replicate to the other domain controllers in the domain via the File Replication Service, or FRS. The FRS propagates changes to Sysvol immediately. It does not follow the 5-minute notification rules within a site or the polling frequencies defined for site links between bridgehead servers.

    Group Policy Containers

    A Group Policy Container (GPC) is an object in Active Directory. It has attributes that identify the GPT files associated with a particular policy and the CSEs required to process those GPTs. Here is a partial attribute list from the Default Domain Policy GPC:

    cn: {31B2F340-016D-11D2-945F-00C04FB984F9};
    displayName: Default Domain Policy;
    gPCFileSysPath: \\company.com\sysvol\company.com\Policies\
    gPCFunctionalityVersion: 2;
    gPCMachineExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}
    gPCUserExtensionNames: [{3060E8D0-7020-11D2-842D-00C04FA372D4}
    gPCWQLFilter: [company.com;{F76FB374-E3B3-434E-953D-0FDDFB634FCF};0]; 1>

    Following is an explanation of the attributes:

    • The GPCFileSysPath attribute tells a client where to find the Group Policy Template files associated with the policy.

    • The GPCMachineExtensionNames attribute specifies the ClassID of the client-side extensions the client will use to process the GPT files for computer policies.

    • The GPCUserExtensionNames attribute specifies the ClassID of the client-side extensions the client will use to process the GPT files for user policies.

    • The GPCWQLFilter attribute specifies details about any WMI filters that have been applied to the Group Policy Object.

    GPC objects are stored in the Domain naming context under cn=Policies, cn=System,dc=<domain_name>,dc=<root>. It is important to keep in mind that separate domains in a forest maintain their own list of GPCs. The Domain naming context is not replicated to other domain controllers (except for global catalog servers, but those replicas are read-only). This imposes two operational restrictions when linking group policies with Active Directory containers:

    • Avoid linking a GPO in one domain to a container in another domain.

    • Avoid creating site policies in a multidomain forest.

    The upcoming sections help explain why those configurations could cause you problems.

    Cross-Domain GPO Links

    GPT files associated with a GPO reside in Sysvol on domain controllers in the same domain as the GPC object in Active Directory.

    If you link a GPO in one domain to a container in another domain, clients affected by the GPO must connect to a domain controller in the second domain to download the GPT files. This requires additional authentication. If the domain controller is at another location in the WAN, the transaction is slowed even further.

    If you have a multidomain forest and you want to apply a consistent set of policies, you should create the policies in each domain. This increases the administrative workload because you must edit multiple GPOs each time you want to change a policy for the enterprise; but the alternative is to have your clients reach out across the WAN each morning to get their enterprise policies.

    Site Policies in a Multidomain Forest

    Site information is stored in Active Directory in a completely independent naming context from domain information. Site information is stored in the Configuration naming context, where it is replicated among all the domain controllers in a forest. Domain information, on the other hand, is stored in a Domain naming context where it is only replicated among domain controllers in the same domain.

    Unfortunately, there are no provisions for storing site group policy information in the Configuration naming context. The GPC component of a group policy can only be stored in a Domain naming context. This has a couple of ramifications:

    • Any number of domains in a forest can be present in any given site, so Microsoft chose to store GPCs for all site policies in one Domain naming context, the root domain. The root domain is the first domain in the forest.

    • Because only domain controllers in the root domain store GPCs for site policies, the associated GPT files are only stored in Sysvol on domain controllers in the root domain.

    The combination of these two engineering decisions restricts the functionality of site policies in a multidomain forest (see Figure 12.6). This diagram shows how site policies would be assigned in a forest with several domains.

    Figure 12.6. Site policies in a multidomain forest.


    The diagram shows two domains, NA and PACRIM, with domain controllers and users in two sites, LA and Tokyo, respectively. Both the LA and Tokyo sites have group policies. Remember that Group Policy Template (GPT) files for site group policies are stored in Sysvol on domain controllers in the root domain of the forest, regardless of the site location and the domains associated with the site.

    When an NA domain client in the LA site logs on, the client downloads GPT files for the LA site policies from an NA domain controller. Because there is an NA domain controller in the LA site, it does not take long to download the GPT files.

    Life is not so sweet for a client in the PacRim domain who logs on in the Tokyo site. The GPT files for Tokyo site policy are stored on NA domain controllers, the root domain of the forest. The Tokyo client must reach out across the WAN to download the GPT files from an NA domain controller in the LA site. If the underlying WAN connection is a 56KB satellite leased line, users in Tokyo end up waiting quite a while for their logon requests to process.

    So, if you have a multidomain forest and you want to implement site policies, put a domain controller from the root domain of the forest at each site with site policies or ensure that you have a fast WAN link to the closest site that contains a forest root domain controller. (Clients determine the closest site using referrals from domain controllers, which are able to check the site topology based on the IP addresses associated with the IP Subnet objects linked to each Site.)

    Policy Hierarchy

    GPOs are linked to container objects in Active Directory. This is how clients determine the list of group policies assigned to them. Only three container types in Active Directory can have links to GPOs:

    • Sites

    • Domains

    • Organizational units (OUs)

    Active Directory keeps track of these policy links with a GPLink attribute in the container object. Here is a partial attribute list for an OU named Phoenix that has two group policy links:

    ou: OU=Phoenix,DC=Company,DC=com
    gPLink: [LDAP://CN={91C0A3BC-141E-49BF-AD3B-2DA7905DBF09},CN=Policies,CN=System, 
    graphics/ccc.gifDC=Company,DC=com;0][LDAP://CN={205D4BEE-ACC2-465A-9ABA-D84575D72523}, CN=Policies,
    gPOptions: 0;
    • The GPLink attribute contains the distinguished name of any GPCs that have been linked to the container. Remember that policy names use a GUID format to ensure their uniqueness. A container can have links to multiple GPOs, and a GPO can be linked to multiple containers.

    • The GPOptions attribute contains a setting for the Block Policy Inheritance option covered later in this chapter. (A value of 0 means that inherited policies are not blocked. A 1 means that blocking is enabled at this container.)

    Clients know the containers in their distinguished name paths, so they can query Active Directory for any GPCLink attributes in those containers. Armed with that information, the clients assemble group policy settings from each GPO according to the following precedence (see Figure 12.7):

    • Local policiesthat is, policies defined at the local computerhave the least precedence.

    • GPOs linked to site containers are next in line.

    • GPOs linked to a domain container take precedence over site and local policies.

    • GPOs linked to an OU take precedence over everything that comes before.

    • GPOs linked to the OU closest to the user or computer object have precedence over GPOs linked to OUs further up the tree.

    Figure 12.7. Diagram of policy inheritance.


    The initials LSDOU are commonly used to represent this precedence. This policy preference order implements an inheritance hierarchy. You can override this hierarchy in one of two ways:

    • You can set a policy setting that contravenes the same setting in a GPO linked to an OU higher in the tree.

    • You can set an attribute in Active Directory that blocks the inheritance of all GPOs linked higher in the tree.

    As you can imagine, both of these options have architectural and managerial ramifications. Let's see what they are.

    Policy Tracking in the Registry

    GPOs downloaded by a client are tracked in the local Registry under the key HKLM | Software | Microsoft | Windows | CurrentVersion | Group Policy | Shadow. Each policy is assigned a sequential number starting with zero. This sequence is determined by the precedence of the GPOs. The higher number has the higher precedence.

    Records of all GPOs downloaded by a client are tracked in the Registry key HKLM | Software | Microsoft | Windows | CurrentVersion | Group Policy | History.

    Overriding Policy Inheritance

    It is possible to override policy inheritance at a particular OU. When this is done, objects in that OU (and any child OUs) stop receiving policy settings from containers higher in the tree.

    Refer to Figure 12.7 in the last section. Let's say that you have created a GPO and linked it to the domain container. In this GPO, you define a security policy called Message Text For Users Attempting To Logon. This policy displays an informational message at logon. Your message includes a notification that all computing equipment belongs to the company and the company reserves the right to examine any and all data on the computer.

    You link this GPO to the domain container because you want every user in the organization to see the message at each logon so they cannot claim they didn't know the restrictions.

    Administrators in the Phoenix OU get tired of hearing their users complain about this message. They decide to block it for their OU. This small mutiny is relatively simple to accomplish. The administrators open the Properties window for their OU in AD Users and Computers and check the Block Policy Inheritance option in the Group Policy properties. Figure 12.8 shows an example.

    Figure 12.8. OU properties, Group Policy showing the Block Policy Inheritance option.


    After the Phoenix administrators make this change, the users in Phoenix stop getting the notice when they log on. This pleases the users but it does not please the company auditors when they pay a little visit the next week. The auditors report the infraction to management, and you, as a top-level administrator, are instructed to quell the mutiny. You use your privileges as Domain Administrator to uncheck the Block Policy Inheritance option in the Phoenix OU.

    A few days later, after the brouhaha has died down, the Phoenix administrators sneak in early one morning and check the Block Policy Inheritance option once again. You notice their action a few days later and you uncheck the option. They check it. You uncheck it. This goes on for a while, then you notice that the Phoenix administrators appear to have finally capitulated. They make no changes to the Block Policy Inheritance option.

    You take a closer look and discover that the Phoenix administrators have set a policy option in another GPO linked to the Phoenix OU that disables the Message Text For Users Attempting To Logon policy setting. Because this GPO is linked to an OU closer to the users than the domain container, it takes precedence and blocks the notification message.

    I don't know about where you come from, but in southern New Mexico we have a name for this kind of contest and we generally resolve it with six guns at high noon in front of the rowdiest saloon on Main Street. If you live in a more congenial climate, you might be interested in the following, less drastic, option.

    Overriding Policy Blocks

    You have the option, as a Domain or Enterprise Administrator, to set an option for a GPO high in the tree that overrides any policy inheritance blocks put in place farther down the tree. This is done as shown in Procedure 12.1.

    Procedure 12.1 Overriding a Policy Block

    1. Open the Properties window for a top-level container such as the domain container or an upper OU.

    2. Select the Group Policies tab.

    3. Highlight the GPO for which you want to force inheritance.

    4. Click the Options button.

    5. Select the No Override radio button as shown in Figure 12.9.

      Figure 12.9. Options window for an OU container showing the No Override option for a particular group policy.


    6. Click OK to save the change.

    With the No Override option in place for a GPO, all policy settings defined by that GPO become mandatory for computers and users farther down the tree. Administrators can set the Block Policy Inheritance option, but it is ignored. And if the local administrators try to override a particular setting with one of their own, they'll discover that the various policy settings in your high-level GPO are dimmed in the Group Policy Editor so they cannot be modified.

    Resultant Set of Policies (RSoP) Calculations

    GPOs can be linked, filtered, blocked, and unblocked in myriad ways. Microsoft took a big step toward simplifying group policy management by including a tool in Windows Server 2003 that it licensed from Full Armor Software, www.fullarmor.com. The tool is called FAZAM, for Full Armor Zero Administration Management.

    As with most third-party technology licensed by Microsoft, the RSoP features taken from FAZAM represent a subset of the commercial package. The portion of the FAZAM tool licensed by Microsoft permits calculating and logging a Resultant Set Of Policies (RSoP) based on the location of a particular user or computer object in Active Directory.

    You can use RSoP calculations to see what happens with group policies if a specified user logs on to a specified computer. The calculation takes into account the location of the user's object, the computer's object, the site name, and any filters imposed based on group membership or hardware type.

    Windows Server 2003 and XP also keep a log of the last set of RSoP calculations performed for any client who logs on at the computer. You can use the RSoP tool to view the contents of this log for any computer in the domain. The log is located in the CIM (Common Information Model) repository. See the upcoming section, "WMI Filtering," for more information.

    RSoP Planning

    The RSoP viewer can be launched in several ways. The simplest way is shown in Procedure 12.2.

    Procedure 12.2 Running the RSoP Wizard in Planning Mode

    1. Right-click a user or computer object in AD Users and Computers and select ALL TASKS | RSOP (PLANNING) from the flyout menu. This launches the RSoP Wizard starting with the Computer and User Selections window. Figure 12.10 offers an example.

      Figure 12.10. RSoP WizardComputer and User Selections window.


    2. Under Computer Information, select the Container radio button, then click Browse and select the OU holding the user's account object.

    3. At this point, the wizard has enough information to calculate an RSoP, so you could select the Skip To The Final Page... option and click Next. However, let's look at additional options that can help you diagnose potential problems.

    4. Click Next. The Advanced Simulation Options window opens. You can select the following:

      • Slow Network Connection. This simulates the kind of GPO processing that would take place across a dial-up, ISDN, or DSL connection.

      • Loopback Processing. This simulates the Computer Configuration and User Configuration swaps that would take place if a loopback processing policy were in effect for the computer object.

      • Site. This selects the site where the user logs on.

    5. Click Next. The Alternate Active Directory Paths window opens. This permits you to select a different OU for the user and computer account.

    6. Click Next. The User Security Groups window opens. The window lists the groups that have the user as a member. You can select additional groups or remove groups for planning or diagnostic purposes.

    7. Click Next. The Computer Security Groups window opens. The window lists the groups that have the computer as a member. You can select additional groups or remove groups for planning or diagnostic purposes.

    8. Click Next. The WMI Filters for Users window opens. The window lists the linked WMI filters. You can select different filters for diagnostic purposes.

    9. Click Next. The WMI Filters for Computers window opens. The window lists the linked WMI filters. You can select different filters for diagnostic purposes.

    10. Click Next. The Summary Of Selections window opens. Use the Back button to change your selections, if necessary. You can also choose to process the selections on a different domain controller if you want to compare the results between DCs.

    11. Click Next. When the wizard completes processing, a Finish window appears. Click Finish to see the RSoP window.

    The RSoP viewer resembles a standard Group Policy Editor window except that it contains only the policy settings from GPOs that met the selection criteria. There is also an excellent RSoP viewer that comes as part of the Help and Support center. This gives a listing in XML that gives all the details of the group policies that have been applied to the computer. You must have local administrator privileges on the machine to run this tool.


    If you prefer the convenience of a command-line tool for viewing RSoP calculations, try the GPRESULT utility. Unlike the GPRESULT in the Windows 2000 Resource Kit, the Windows Server 2003 version performs the same calculations as those performed by the RSoP Wizard. You can also use it to view the contents of the RSoP log.

    A GPRESULT listing is too long to show here, but it includes all the information necessary to trace each policy setting back to its originating GPO and linked container. You can run GPRESULT in planning or logging mode.

    RSoP Logging

    You can select the (Logging) option in the RSoP viewer to view the contents of the RSoP calculations performed for any client on any computer. You must have administrator rights on the computer where you are viewing the log. Proceed as shown in Procedure 12.3.

    Procedure 12.3 Running the RSoP Wizard in Logging Mode

    1. In AD Users and Computers, right-click a computer object and select RESULTANT SET OF POLICY (LOGGING) from the flyout menu. The RSoP Wizard opens with the Computer Selection window open.

    2. Click Next. The User Selection window opens. Highlight the user name whose RSoP results you want to view.

    3. Click Next. The Summary Of Selections window opens.

    4. Click Next. The wizard retrieves the user's log entries from the selected computer and displays them in the RSoP viewer.

    By comparing the RSoP results the client actually got to those that you get when you ran the user through the RSoP (Planning) calculations, you can see if there is a discrepancy and resolve it.

    Additional Troubleshooting Tools

    If you configure a group policy but it doesn't seem to work quite as you expected, check these items:

    • Event Viewer. Look in the Application log for entries from the Userenv service. Warnings from this service are your first indication that something went wrong with group policy downloads.

    • Access rights. One common problem with group policies is security access rights. Always make sure that the user has rights to the policy you're trying to apply. The easiest way to check this is to use the appropriate AD console to open the Group Policy properties for the associated container and then select the Security tab. The user should be a member of a group with Read and Allow Group Policy privileges.

    • Incorrect policy links. Another common problem when configuring group policies is "losing the map," as they say in fighter pilot training. You may have linked the policy to one container but are testing it with a user account from another container. Or someone may have put another policy in place higher in the policy hierarchy than yours and is either overwriting your entry or blocking it completely.

    • GPOTOOL. As I covered in the GPC topic, the GPOTOOL utility can help you trace inconsistencies between the version numbers of the GPTs and GPCs associated with a particular GPO.

    • Network problems. Make sure the client is communicating with a domain controller, a global catalog server, and a DNS server. A failure to connect to any of these components can cause problems with group policy. You can run the NETDIAG utility to see if there are any errors.

    • Debug Userenv. As a last-ditch effort to find the problem, you can enable group policy logging. Add a Registry value to the Winlogon key to enable logging:

      Key:   HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon
      Value: UserEnvDebugLevel
      Data:  0x10002 (Hex) of type Reg_Dword

      Restart the computer after adding the value. The log file is located in \Windows\Debug\Userenv.log. Be prepared with a cup of coffee and some patience. The log contains a lot of information.

    Computer Policies and User Policies

    GPOs are divided into two parts:

    • A Computer Configuration section that contains policy settings that apply to computer objects.

    • A User Configuration section that contains policy settings that apply to user objects.

    The Group Policy Editor displays these two sections as two top-level icons.

    Some policy settings appear in both sections. When there is a conflict between settings for the same policy in the Computer Configuration and User Configuration sections, the Computer setting takes precedence. This is true even if the policy settings are in two different GPOs.

    Consider an example where an OU named Phoenix contains both user and computer objects. There are two GPOs linked to the Phoenix OU:

    • A GPO named Phx-Computers

    • A GPO named Phx-Users

    Each GPO contains a policy under Task Scheduler called Prohibit New Task Creation. When this policy is enabled, the Add Scheduled Task icon does not appear in the Scheduled Tasks applet in Control Panel.

    The Phx-Users GPO has the policy under the User Configuration settings. The Phx-Computers GPO has the policy under the Computer Configuration settings. Here is how the policy is handled:

    • In the Phx-Users GPO, the policy has been disabled, meaning it is possible to create new scheduled tasks.

    • In the Phx-Computers GPO, the policy has been enabled, meaning it is not possible to create new scheduled tasks.

    With this configuration, when a user in Phoenix logs on at a computer in Phoenix, the user would not see the Add Scheduled Task icon in the Scheduled Tasks applet. New task creation is disabled because the Computer Configuration policy takes precedence over the User Configuration policy.

    If an administrator changes the policy setting in the Phx-Computers GPO from Disabled to Not Configured, as soon as a background refresh occurs at the desktop, the user will see the Add Scheduled Task icon.

    Loopback Processing

    The last section covered the situations where policy settings under Computer Configuration override the same policy settings applied under User configuration. There is another situation where the system must determine precedence based on the location of the policy setting.

    Consider a scenario similar to the last example, but now there are two OUs under the Phoenix OU:

    • The Users OU holds the user objects in Phoenix. It is linked to the Phx-Users GPO.

    • The Computers OU holds the computer objects in Phoenix. It is linked to the Phx-Computers GPO.

    The GPOs have a variety of settings. The specifics for the settings are not important in this example:

    • The Phx-Users GPO has two policy settings: a security policy under Computer Configuration and a software distribution policy under User Configuration.

    • The Phx-Computer GPO has two policy settings: an audit policy under Computer Configuration and a logon script policy under User Configuration.

    When a user in the Users OU logs on to a computer in the Computers OU, the resultant set of policies would include the following:

    • The software distribution policy from the Phx-Users GPO

    • The audit policy from the Phx-Computers GPO

    This makes sense under ordinary circumstances. But there are some situations when it makes sense to apply the User Configuration settings from GPOs linked to containers holding computer objects. The most common reasons are walk-up workstations, lab computers, or terminal servers where you want to maintain a consistent look-and-feel of the desktop and the software distributions regardless of who logs on.

    In those situations, you can configure the system to apply the User Configuration settings from GPOs linked to containers holding computer objects. This is called loopback processing.

    You can enable loopback processing using a group policy called User Group Policy Loopback Processing Mode. The policy is located under Computer Configuration | Administrative Templates | System | Group Policy. The default setting is no loopback processing.

    You can enable loopback processing in two modes:

    • Replace mode. This mode tells the client computer to ignore User Configuration policies coming from GPOs linked to the user's containers and apply User Configuration policies from GPOs linked to the computer's containers.

    • Merge mode. This mode tells the client computer to first apply User Configuration policies from GPOs liked to the computer's containers, then apply User Configuration policies from GPOs linked to the user's containers. This gives precedence to the user's policy settings.

    If loopback processing were enabled in Replace mode, the client would get this resultant set of policies:

    • The audit policy from Phx-Computer

    • The logon script policy from Phx-Computer

    The User Configuration policy from the user's side is ignored because of loopback processing. The Computer Configuration policy from the user's side is ignored regardless of the loopback processing setting.

    If loopback processing were enabled in Merge mode, the client would get this resultant set of policies:

    • The audit policy from Phx-Computer

    • The logon script policy from Phx-Computer

    • The software distribution policy from the Phx-Users GPO

    The Computer Configuration policy from the user's side is ignored regardless of the loopback processing setting.

    You should avoid loopback processing except for specialized environments. They can make group policy troubleshooting very complex. Be sure to create separate OUs to hold the computer objects. You may want to physically identify computers affected by loopback processing (such as a sign on the monitor) so users are not surprised when they don't get their normal settings.

    Group Policy Editor

    The contents of Group Policy Objects are managed using the Group Policy Editor, or GPE. The GPE is an MMC snap-in that appears in a variety of locations.

    The most common place you will see the GPE is when you open the Properties | Group Policy window for a site, domain, or OU object. When launched in this manner, the GPE displays only those GPOs linked to the container.

    You can also build a custom MMC console and load the GPE snap-in into the console. When you do this, you'll be prompted for the name of the GPO you want to edit. Click Browse to open the Browse For A Group Policy window, then select the All tab to see a list of the GPOs in the domain. Figure 12.11 offers an example.

    Figure 12.11. Browse For A Group Policy window showing the list of Group Policy Objects in the Company.com domain.


    You can load the GPE snap-in multiple times into the same MMC console. Each time you load it, you can select a different GPO to manage. This is an ideal way to manage large numbers of GPOs from a single interface.

    You can also point a custom console at a specific group policy or you can point it at a specific computer or both. These options use the /gpcomputer and /gpobject command-line switches. This is how Microsoft provides specialty consoles like the Local Security Settings console and the Domain Security Policy console. For example, here is the Target field from the shortcut that loads the Domain Security Policy console:

    C:\WINDOWS\system32\dompol.msc /gpobject:"LDAP://CN={31B2F340-016D-11D2-945F-

    As we'll see in the next section, the Dompol.msc console also takes advantage of an MMC feature that permits loading specific GPE extensions.

    Special Configuration for Using Command-Line MSC Switches

    If you want to use the /gpcomputer and /gpobject command-line switches to control an MMC console, you must set the following option for the group policy when you load the GPO into the console using the Add/Remove Snap-in window:

    Allow The Focus Of The Group Policy Snap-In To Be Changed When 
    graphics/ccc.gifLaunching From The
    Command Line

    Selecting Group Policy Editor Extensions

    The Group Policy Editor depends on several support files to supply editing capabilities for the various policy types. Table 12.3 lists the GPT files and their GPE extensions. If you get an error when opening a folder within a GPE, look for a problem with the respective editor or the files it tries to access.

    Table 12.3. GPT Files and Their GPE Extensions

    GPE Files

    GPE Extension









    *.aas (software deployment)




    If you build a custom MMC console for editing group policies as covered in the previous section, you can tailor the console by selecting individual editor extensions. Do this by selecting the Extensions tab in the Add/Remove Snap-In window, then uncheck all the extensions you don't want to load. Figure 12.12 shows an example for a custom console that only loads the Logon\Logoff Scripts extension.

    Figure 12.12. Add/Remove Snap-In window for a custom console showing a limited selection of policy editor extensions.


    PDC Emulator and the Group Policy Editor

    When you edit a GPO, the Group Policy Editor reads the GPC and GPT elements from a specific domain controller. By default, it selects the domain controller that holds the PDC Emulator role master token. This is true regardless of the focus of the AD Users and Computers (or AD Sites and Services) console when you open the GPE.

    For instance, if you open AD Users and Computers at a workstation with a logon server of DC-37, the focus of the console will be at DC-37; but when you open the properties of a Group Policy Object for a container in the domain, the GPE will automatically read its information from the PDC Emulator, not from DC-37.

    At first glance, this preference for modifying group policies at a single domain controller seems to violate the principle of multiple master replication. After all, changes to any replica of Active Directory or Sysvol will replicate to all other domain controllers, right?

    The GPE prefers to work at a single domain controller in a domain because it is possible that two administrators could change policies in the same GPO during the same replication cycle. If this happens, changes made by one administrator will be overwritten during replication.

    If you launch the GPE when the PDC Emulator is not available, you'll be prompted to select another domain controller or to wait until the PDC Emulator can be contacted. There's nothing wrong with modifying a GPO on another domain controller as long as you're sure that you are the only administrator working on that GPO. If you have any doubt, it's better to wait.

    Changing the Default GPE Domain Controller

    If you use domain controllers other than the PDC Emulator to modify GPOs, you can set a group policy to change the domain controller selection criteria. The policy name is Group Policy Domain Controller Selection. It is located under User Configuration | Administrative Templates | System | Group Policy.

    This policy has three options:

    • Use the Primary Domain Controller. This is the default option if the policy is not configured.

    • Inherit From The Active Directory Snap-Ins. This puts the focus of the editor on the same domain controller used by the console, AD Users and Computers, or AD Sites and Services, that launched the editor.

    • Use Any Available Domain Controller. This option permits the editor to use the first available domain controller. This is generally the logon server of the administrator using the tool.

    You may have noticed that one seemingly obvious option is missing. You cannot simply select a different domain controller for everyone to use. If you want everyone to use the same domain controller, you must transfer the PDC Emulator role master to that server.

    Group Policies and Local Policies

    In addition to downloading group policies from a domain controller, servers running Windows Server 2003 and XP desktops have their own local store of policies in a hidden folder called \Windows\System32\GroupPolicy. The local computers also host the underlying data stores that group policies control, and local changes are often written directly to these data stores.

    Policies overlay each other as they are applied, with the final set of policies getting the highest precedence. Local policies are always applied first, so they are like indigenous peoples who get overridden by marauding group policies as they sweep in from the domain.

    If you manage a standalone desktop or server, you can change the local policies using the Local Policy Editor console, Gpedit.msc. The GPT files created by Gpedit.msc are stored in \Windows\System32\GroupPolicy.

    Group policies downloaded from the domain are cached locally. For this reason, a user on a laptop that is disconnected from the network will continue to use the last set of group policies downloaded from the domain. This is important to remember because several group policies absolutely rely on cached information to function properly. An example is the Encrypting File System (EFS), which looks for a cached copy of the file recovery certificate from the domain Data Recovery Agent (DRA) when a user encrypts a file. If the domain DRA certificate is not available, the user cannot encrypt a file.

    Because of group policy precedence, it is possible for local policies to become masked so that you forget they exist. They lie dormant in the Registry or the Secedit database and appear when the computer is disjoined from the domain or a user logs on to the local SAM instead of the domain.

    Targeting Group Policies

    In their default configuration, the settings in a GPO affect every user and computer object under the linked container. If you prefer a more tactical approach to assigning group policies, you'll appreciate being able to target policies by filtering out anyone who should not get the policy. Windows Server 2003 has two filter criteria:

    • A user's or computer's group membership

    • Hardware and operating system configurations exposed by Windows Management Instrumentation (WMI)

    Filtering Group Policies Based on Security Groups

    One of the most common misconceptions about group policies is that they are policies assigned to groups. Nothing is further from the truth, of course. Group policies are assigned to user and computer objects based on their location in Active Directory, never to groups.

    You do have the option, though, of filtering a GPO so that it only takes effect if a computer or user is a member of a group. For instance, you may have a general set of desktop configuration policies in a GPO linked to a regional OU like Phoenix. The settings in this GPO suit most users, but the Sales Manager wants her people's desktops to be locked down severely so they stay focused on their quotas.

    You could move the user objects for the salespeople to a separate OU under Phoenix and create a new GPO linked to that OU, but you might have restrictions that prevent you from taking this step. For instance, you might not have sufficient administrative privileges to create a new OU. Or, your organization might have AD design guidelines that do not permit you to create ad hoc OUs. Or, you might want to apply the group policies to users from a variety of OUs.

    In these cases, you could create a new GPO and filter it so that only users in the Sales group apply the policy. This is done by modifying the security descriptor for the GPC object in Active Directory so that only certain groups have access to read and apply the group policy templates identified by the GPC. Figure 12.13 offers an example.

    Figure 12.13. ACL Editor for a group policy showing a single security group assigned the Apply Group Policy permission.


    The simplest way to access the security descriptor for a GPC is shown in Procedure 12.4.

    Procedure 12.4 Configuring a GPO Security Descriptor to Filter Policy Recipients

    1. Right-click the site, domain, or OU linked to the Group Policy Object and select PROPERTIES from the flyout menu.

    2. Select the Group Policy tab.

    3. Highlight the group policy you want to filter and click Properties. The Properties window opens.

    4. Select the Security tab.

    5. Change the contents of the ACL to meet your filtering needs. Assign Apply Group Policy permissions to any groups you want to receive the policy.

    6. Click OK to close the editor and save the changes.

    If you elect to use filtering to target a GPO to a particular group or groups, keep in mind that the filter only applies if the objects representing the users in the group fall within the scope of the GPO. For instance, in the previous example, if you move a salesperson's user object out of the Phoenix OU and into the Atlanta OU, the user no longer gets the Sales Lockdown policy.

    WMI Filtering

    WMI, Windows Management Instrumentation, is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) initiative of the Desktop Management Task Force (DMTF). Figure 12.14 shows a schematic diagram of the WMI components.

    Figure 12.14. WMI components used in WMI filtering for group policies.


    Here are the components:

    • Managed objects. WMI collects information from a wide variety of devices and applications. Examples include hard drives and CPUs and memory and network adapters. These objects are abstracted by COM objects called providers that collect the information reported by the managed objects.

    • Common Information Model (CIM). WMI stores information obtained from providers of managed objects in a repository called the Common Information Model, or CIM. This repository is less like a database and more like an auditorium where objects spit out information when they're called on. The top of the CIM repository is \root\cimv2.

    • Common Information Model Object Manager (CIMOM). The CIM information repository is exposed by the CIM Object Manager, or CIMOM. CIMOM is responsible for processing input from the providers and communicating with applications that want information stored in the CIM repository.

    • WMI Query Language (WQL). Because WMI is Microsoft's WBEM implementation, the information exposed by CIMOM is accessed via a language designed by Microsoft called the WMI Query Language, or WQL. The WQL provides read-only access to the CIMOM. Updates are done programmatically through the providers.

    • Event triggers. In addition to responding passively to queries, the CIMOM can proactively send messages and take actions in response to events occurring in the CIM repository. Group policies do not make use of WMI events.

    Windows Server 2003 uses WMI in a variety of ways. For group policies, you can use WMI to filter a GPO based on the results of a WQL statement.

    WQL Statements

    WQL syntax is a subset of SQL with extensions for specific classes in the CIM. The most common WQL statement used in WMI filters is a Select statement with Where modifiers that define a result set. Here are a few examples:

    • Return the names of computers that have CPUs faster than 600MHz:

      root\cimv2; SELECT * from Win32_Processor WHERE currentclockspeed < 600
    • Return the names of computers that are running Windows 2000 Professional so you can deploy specific service packs or tools:

      root\cimv2; SELECT * from Win32_OperatingSystem WHERE caption = ""Microsoft Windows 2000 
    • Return the names of computers that are running the Microsoft Client:

      root\cimv2; SELECT * from Win32_NetworkClient WHERE name = ""Microsoft Windows Network"

    Notice the use of double quotes in the select statements. A double quote is a reserved symbol in WQL, so you must double-up the quotes if you need them to be included in the statement sent to CIMOM.

    Rather than go on and on with examples, let me show you a great way to find interesting WMI classes so you can build your own WQL statements.

    The WMI SDK comes with a web-based CIMOM browser called CIM Studio. You can download the WMI SDK from Microsoft at msdn.microsoft.com/downloads. Drill down through the tree to Windows Development | Windows Management Instrumentation.

    CIM Studio is a browser-based utility. Figure 12.15 shows a sample page. You can use CIM Studio to find classes of interest to you by clicking the Find button (binoculars icon above the right pane) and entering a word like "network." This will return all the classes that contain the word "network."

    Figure 12.15. CIM Studio interface.


    Those classes that start with Win32_ give access to providers of operating system information. Double-click one of the Win32_* entries in the pick list to display information about the class in the right pane.

    To see what's stored in the CIM repository for a particular class, select the class, then click the Instances button (fourth button from the right, above the right pane). The pane fills with the results of a generic WQL query that essentially says, "Give me every instance of this class and all their attributes." You can use the column headings to develop your own WQL statements.

    Configuring WMI Filters

    WMI filters cannot be applied to individual elements of a GPO. For instance, you cannot filter just the Administrative Templates portion of a GPO. This means that you manage WMI filters as part of the properties of the GPO itself. Proceed as demonstrated in Procedure 12.5.

    Procedure 12.5 Accessing the WMI Filter Interface

    1. Open the Properties window for the GPO you want to filter.

    2. Select the WMI Filter tab. Figure 12.16 shows an example.

      Figure 12.16. WMI Filter tab for a GPO.


    3. Select the This Filter radio button, then click Browse/Manage. The Manage WMI Filters window opens.

    4. Click Advanced. This exposes the WMI Filter Editor (see Figure 12.17).

      Figure 12.17. Advanced view of the Manage WMI Filters window showing the WMI Filter Editor.


    5. Enter a WQL statement that you have designed to retrieve a set of computers or users that you want to get the policy settings in the GPO.

    6. Click Save to save the WQL statement and then click OK to save the filter.

    7. Test the filter by logging on from a computer that meets the filter requirements to see if you get the policy.

    You can only select one WMI filter for any given GPO. The filter can be as complex as you like, but remember that the clients must execute the statement to its completion. Putting too many select criteria in the statement can negatively impact client logon time.

    WMI Filter Storage

    WMI filters are stored in Active Directory as MS-WMI-SOM object types. SOM stands for Scope of Management. The filter objects are stored under the SOM container, distinguished name cn=SOM,cn=WMIPolicy,cn=System,dc=<domain_name>,dc=<root>.

    Here is a partial attribute list from a filter object that shows the attributes used to store and manage the filter:

    cn: {C3BB1D85-D674-4568-B3BD-BBD4C6EC5A4D};
    msWMI-Author: Administrator;
    msWMI-ID: {C3BB1D85-D674-4568-B3BD-BBD4C6EC5A4D};
    msWMI-Name: Phx-Filter-1;
    msWMI-Parm1: Computers with CPUs faster than 600 MHz;
    msWMI-Parm2: 1;3;10;60;WQL;root\cimv2; select * from Win32_Processor where 
    graphics/ccc.gifcurrentclockspeed > 600;;

    Here are the items of note in the listing:

    • MSWMI-Author stores the name of the user who created the filter. Keep this in mind if you cannot decipher the filter and you want to know the originator's intentions.

    • MSWMI-ID stores the filter name. The name is derived using the GUID algorithm to ensure uniqueness.

    • MSWMI-Name stores the friendly name for the filter.

    • MSWMI-Parm1 stores the filter description.

    • MSWMI-Parm2 stores the WQL statement for the filter.

    Delegating Group Policy Management

    One of the key strengths of Active Directory is the capability it offers to fine-tune the administrative rights you dole out. For instance, you can create an OU for a specific set of users and groups, then delegate admin rights over that OU to local administrators or experienced user representatives (sometimes called "department gurus").

    Delegating the ability to create and manage GPOs is a little trickier than delegating the ability to manage users or computers or shared printers. The dual nature of a GPOthe GPC and GPT componentsmeans that the local administrator must have two privileges:

    • The privilege to create and modify files in Sysvol on a domain controller

    • The ability to create new GPC objects in Active Directory

    These privileges are not given to users by default. You must assign them.

    Assign GPT Access Permissions

    GPTs are saved as files under policy folders in Sysvol. Assigning rights to these files involves setting NTFS permissions on the \Sysvol\Sysvol\<domain_name>\Policies folder.

    This folder is actually a reparse point linked to the \Sysvol\Domain\Policies folder, so you can set permissions there, instead, if you want.

    Start by creating a group for the local administrators. Then assign Read, Write, Create, and Modify permissions for the Policies folder to this group.

    As an alternative, if you want the local administrators to manage a GPO but not create one, you can create the GPO first and then assign permissions on its policy folder.

    These new NTFS permissions represent changes to the folders so they replicate to the other domain controllers via the File Replication Service.

    Delegate GPC Access Permissions

    After you've prepared the GPT permissions, give the admin group permission to create GPOs by adding it to the Group Policy Creator Owners group. This group has permission to create and modify objects in the Policies container in Active Directory, located at cn=Policies,cn=System,dc=<domain_name>,dc=<root>.

    If you have not granted the admin group full control permission to the OU, you must also delegate it Create Link permission on the OU.

      Previous Section Next Section