Skip to main content

Troubleshooting Group Policy

Through Group Policy, you can apply a wide variety, and number of user configuration settings and computer configuration settings to users and computers in Active Directory. If your Active Directory environment includes a hierarchy with many different organizational unit (OU) levels, with group policies applied at these different levels within the hierarchy, you can most certainly anticipate that you are going to be troubleshooting Group Policy behavior and Group Policy settings.
There are going to be situations when the settings of Group Policy are going to be producing an expected result. Group Policy settings are contained in Group Policy Objects (GPOs), which are in turn linked to sites, domains, or OUs in Active Directory. The GPOs linked to sites, domain, and OUs in Active Directory are then applied to user objects and computer objects that are located within these container type objects. GPOs are processed in a synchronous manner.
What this means is that the processing of one GPO must be completed before the next GPO is processed. Depending on the manner in which the GPOs are configured and linked, the GPO processing time at computer startup, or user logon could become quite substantial. This typically occurs in large environments when the Group Policy settings have to be conveyed across the network, and over slow WAN links. Group Policy also stops processing certain policies when it detects a slow link connection.troubleshooting group policy Troubleshooting Group Policy
While you would need to be familiar with troubleshooting issues specific to Group Policy settings, you would also at times need to troubleshoot network connectivity issues and examine the underlying operating system which Group Policy depends on. These elements could also be affecting the behavior of a GPO. Remember that Group Policy interrelates with other system components as well.
The common Group Policy issues that need to be resolved are listed below:
  • GPOs are not being processed at the site level, domain level, or OU level.
  • GPOs are not being applied to users and computers because they cannot be accessed by the appropriate user objects or computer objects.
  • GPOs are being applied to the incorrect users and computers.
  • When Group Policy settings are being applied, computer startup and use logon times are unacceptably long due to the GPO processing time.
  • There may be occurrences when GPO inheritance produces the incorrect results. The Block Policy Inheritance option and No Override option could be configured incorrectly.
  • Folder redirection is not occurring as it should be.
  • System folders are being redirected to the incorrect locations.
  • The incorrect configuration of the Offline File Feature could result in files and folder not being available when the network connection is lost, and files not being synchronized.
  • When Group Policy is used to deploy software, users may have the incorrect NTFS and share permissions to access the network share where the installation packages are being stored. This results in the user not being able to install any published or assigned applications.
  • Applications that were published in Active Directory do not appear in Add/Remove Programs in Control Panel.
  • Applications which were assigned to a computer are not being installed.
Just by looking at the common Group Policy issues which could occur, you can see that Administrators have to be familiar with Group Policy troubleshooting techniques. Windows Server 2003 includes a number or tools and utilities which you can use to troubleshoot GPO behavior, software deployment, and security policies.
The tools and utilities which you can use to assist in troubleshooting Group Policy are listed below:
  • Resultant Set Of Policy (RSOP) Wizard
  • Gpresult.exe
  • Gpupdate.exe
  • WinPolicies
  • GPOTool
  • Event Viewer
  • Log Files

Troubleshooting Group Policy Infrastructure

As mentioned previously, the underlying operating system and network connectivity can influence whether Group Policy settings are applied to users and computers. The system components within the underlying operating system that you should examine when Group Policy fails are listed below:
  • The DNS service should be running, and configured correctly on the domain controller(s) within your Active Directory environment. If DNS is not running and configured correctly, your Active Directory clients would be unable to find domain controllers, and ultimately access any GPOs.
  • DNS also plays a role in the folder redirection feature of Group Policy. A client needsDNS to locate the network location of redirected system folders.
  • For a user or computer to fall within the scope of a GPO, the user has to be a member of the site, domain, or OU that the particular GPO is linked to.
  • To access Group Policy templates, clients require access to the SYSVOL share located on the domain controllers. Ensure that clients have the correct permission to access the SYSVOL share. Problems with replication could also result in clients experiencing problems in accessing Group Policy templates.
  • Ensure that Active Directory replication, and file system replication are occurring as should be
The tools that you can use to assist in troubleshooting the underlying operating system components which Group Policy depends on are:
  • Replmon, can be used to verify Active Directory and file system replication.
  • Group Policy Management Console (GPMC) can assist in troubleshooting the GPO behaviour. You can use the GPMC to determine which GPOs are enabled and being processed, and the manner in which GPOs are linked to sites, domains, and OUs.
Because the processing of GPOs rely on network connectivity between the client workstation and the domain controller(s) that are members of the sites or domains within Active Directory, a loss of network connectivity can result in no Group Policy settings being processed. A few issues that should be addressed when you are experiencing network connectivity problems are listed below:
  • Verify that the TCP/IP protocol is installed and running within your environment. For GPOs to be processed, the TCP/IP protocol must be running.
  • GPOs are also dependent on the Internet Control Message Protocol (ICMP) for the detection of slow network links. The firewall configuration within your environment would determine whether ICMP packets should be enabled between the domain controllers and network clients.
  • Verify that the time and date on the network client is in sync with the time and date of the domain controllers and the remainder of the network clients. The Windows Time Service is normally used to ensure that the time and date of clients and domain controllers are synchronized. If a client's clock is not synchronized, authentication problems would occur; and the client may not be able to access any GPOs.
You can use the tools listed below to verify network connectivity between network clients and Active Directory domain controllers:
  • Netstat utility
  • Ping utility

Using Resultant Set of Policy (RSOP) to Troubleshoot Group Policy

The Resultant Set Of Policy Wizard and the Gpresult command-line utility can be used to create RSoP queries that would determine the RSoPs for any users and computers which are defined in the RSoP query. The Resultant Set Of Policy feature is new in Windows Server 2003, and can assist in greatly reducing the quantity of time spent on troubleshooting GPOs. Through RSoP, you can query the existing policies which you have linked to a site, domain, or OU; and which are applied to users and computers.
RSoP can generate information on the following Group Policy settings:
  • Administrative Templates
  • Folder Redirection
  • Security Settings
  • Software Installation
  • Scripts
  • Internet Explorer Maintenance
Because numerous GPOs are typically applied in Active Directory, you can use the RSoP feature to determine which policies are applied to the user or computer which you are troubleshooting. RSoP also indicates which Group Policy settings have precedence. RSoP can assist in determining whether security templates have been applied correctly. It also points out instances when any settings are overwritten because of conflicting policy settings.
The four types of information which you can view in the RSoP console are:
  • Individual Group Policy settings
  • The list of GPOs associated with the RSoP query
  • The scope of management associated with the RSoP query
  • GPO revision information
RSoP has two modes:
  • Logging mode: You would use RSoP logging mode to determine which existing policy settings have been applied to a user or computer. Logging mode basically generates information on your existing Group Policy settings. Logging mode should be used for the purposes listed below:
    • Determine how policy settings are being affected by security groups and local policy.
    • Discover failed Group Policy settings and overwritten Group Policy settings.
  • Planning mode: You would use RSoP planning mode to simulate the effects of new Group Policy settings before implementing the GPOs in your production environment. Planning mode should be used for the purposes listed below:
    • To test policy precedence
    • To simulate GPO processing over a slow network link.
    • To simulate loopback processing.
How to create and run an RSoP query to troubleshoot existing policy settings for a specified user and computer:
  1. Click Start, Run, and enter mmc in the Run dialog box. Click OK.
  2. Click Add/Remove Snap-in on the File menu.
  3. Click the Standalone tab, and then click Add.
  4. Select Resultant Set of Policy, and click Add. Click Close.
  5. Click OK.
  6. In the MMC, right-click Resultant Set of Policy and select Generate RSoP Data on the shortcut menu.
  7. Click Next on the initial page of the Resultant Set Of Policy Wizard.
  8. Select Logging mode on the Mode Selection page. Click Next.
  9. When the Computer Selection page opens, select to either run the RSoP query on This Computer, or Another Computer.
  10. You can also select the Do not display policy settings for the selected computer in the results | display user policy settings only checkbox. Click Next.
  11. When the User Selection page opens, you can select that the query use the Current User, or you can choose the Select A Specific User option.
  12. You can also select the Do not display policy settings for the selected user in the results | display computer policy settings only checkbox. Click Next.
  13. Verify the parameters that you set for the RSoP query on the Summary Of Selections page. Click Next.
  14. Click Finish on the Completing The Resultant Set Of Policy Data Wizard page.
  15. The RSoP console would display the data which resulted from running the RSoP query.

Using Gpresult.exe to Troubleshoot Group Policy

You can use the Gpresult.exe command-line utility available in Windows Server 2003 to create RSoP queries which can collect and report RSoP data or information on users and computers. Gpresult.exe can be used to gather the information listed below which could be useful when you have to troubleshoot Group Policy.
  • Information on the OS, computer and user.
  • Group Policy information, including:
    • When Group Policy was last applied
    • The domain controller which applied Group Policy
    • Information on all GPOs that are applied, and details for these
    • Information on the Registry settings that are applied, and details for these
    • Scripts
    • Software management information and details on published and assigned applications
    • Disk quota information
    • Internet Protocol (IP) security settings
    • Redirected folder information, and details on these.
The syntax of the Gpresult command and its parameters are listed below:
gpresult [/s computer [/u domainuser /p password]] [/user username] [/scope {user|computer}] [/v] [/z]
  • /s computer, defines the IP address/name of a remote computer. The local computer is used by default.
  • /u domainuser, specifies the user account that should be used to run the command. The permissions of the user currently logged on are used by default.
  • /p password, the password of the user account
  • /user username, the user name for which RSoP information should be shown.
  • /scope {user|computer, used to define that user settings or computer settings should be displayed. Both are displayed by default.
  • /v, indicates output to show verbose policy information
  • /z, indicates output to show all policy information

Using Gpupdate.exe to Troubleshoot Group Policy

You can use the Gpupdate.exe command-line utility to perform the following tasks:
  • To refresh GPOs immediately, if it is not being processed correctly
  • To refresh a GPO immediately, after you have made a change to its Group Policy settings.
The Gpupdate.exe command-line utility is new in Windows Server 2003. It replaces the Secedit, refresh policy command which was used in Windows 2000.
The syntax of the Gpupdate command and its parameters are listed below:
Gpupdate [/Target:{Computer | User}] [/Force] [/Wait:<value>] [/Logoff] [/Boot] [/Sync]
  • /Target:{Computer | User}, indicates whether only the computer policy setting or only the user policy settings are refreshed. Both types of policy settings are refreshed by default.
  • /Force, specifies to reapply all policy settings. Only the policy settings that have changed as from the last Group Policy refresh are refreshed by default.
  • /Wait:<value>, specifies the number of seconds to wait for all policy processing to finish. The default value is 600 seconds. A value of 0 indicates to Gpupdate not to wait, while a value of 1 indicates to Gpupdate to wait indefinitely.
  • /Logoff, compels the user to logoff the computer after the Group Policy settings are refreshed.
  • /Boot, results in a reboot after the Group Policy settings are refreshed.
  • /Sync, results in the next policy application to occur synchronously on computer startup, or user logon.

Using the Group Policy Management Console (GPMC) to Troubleshoot Group Policy

The Group Policy Management Console (GPMC) incorporates numerous Group Policy operations into one management console, and therefore enables you to manage Group Policy settings within your environment from one location. The GPMC can be used to examine all sites, domains, OUs and GPOs within your enterprise. The GPMC consists of an MMC, a set of automated scripts which can be run from the command line, and a set of batch files. The scripts included in the Group Policy Management Console (GPMC) can be used to list and view the following GPO information:
  • Information on a GPO
  • All the GPOs in a domain
  • All disabled GPOs
  • View unlinked GPOs in a domain
  • View GPOs by policy extension
  • View GPOs by security group
  • View GPOs with duplicate names
  • View GPOs with no security filtering
  • View scope of management information
Because of the information which you can view using the GPMC, it can be of assistance when you need to troubleshoot GPO behaviour. It allows you toexamine the settings of a specific GPO, and is can also be used to determine how your GPOs are linked to sites, domains, and OUs. To access the GPMC, click Start, Administrative Tasks, and then click Group Policy Management. The Group Policy Results report collects information on a computer and user, to list the policy settings which are enabled. To create a Group Policy Results report, right-click Group Policy Results, and select Group Policy Results Wizard on the shortcut menu. This launches the Group Policy Results Wizard, which guides you through various pages to set parameters for the information that should be displayed in the Group Policy Results report.

Troubleshooting Policy Inheritance

To successfully troubleshoot policy inheritance issues, you need to thoroughly understand how policy inheritance affects the application of Group Policy settings within GPOs. You also need to understand how enabling the Block Policy Inheritance option and No Override option affect policy inheritance. Inheritance signifies that Group Policy settings which affect user configuration and computer configuration are the resultant set of policies inherited from parent containers. Policies are usually passed down from a parent container to its associated child containers. When the policy setting for a parent OU is set to Enabled or Disabled; and the child OU does not have the same policy setting configured, the child OUs inherits the policy setting of its parent OU. The exception being that a Group Policy setting defined for a child OU overrides the same setting which it inherited from its parent OU.
Group policy settings are processed in the order specified below:
  1. Local GPO: Because the local GPO is applied first, it means that policies defined at the local computer have the least priority.
  2. Site GPO: Site GPOs are GPOs which are linked to sites. The order of the different site GPOs are determined and defined by the Administrator.
  3. Domain GPOs: Domain GPOs are applied next. GPOs linked to a domain have precedence over site GPOs and local GPOs.
  4. OU GPOs linked to the OU highest in the Active Directory hierarchy are applied before any other OUs. OU GPOs linked to the OU closest to the user or computer is then applied. When the OU that contains the user or computer has a GPO linked to it; that GPO is applied last.
Block Policy Inheritance can be explicitly specified for a site, domain or OU; and is not applied to any GPOs or GPO links. When enabled for a site, domain or OU; it prevents any Group Policy settings from passing down from higher up in the tree, to the particular site, domain or OU for which it is enabled. The only exception is that any GPO links which have the No Override settings enabled are not blocked, but are applied. When the No Override setting is enabled for a GPO which is linked to a site, domain or OU, no Group Policy settings contained in the particular GPO is overridden by other GPOs. Because of the hierarchical manner in which GPOs are applied, and there happens to be more than one GPO which has the No Override setting enabled, the GPO highest in the tree has precedence.
A few techniques for troubleshooting Group Policy inheritance are listed below:
  • GPOs can only be linked to sites, domains and OU, and then applied to users and computers.
  • Remember that while child OUs, by default inherit the Group Policy Settings of its associated parent OUs; child domains do not inherit Group Policy settings from parent domains.
  • A factor to consider when troubleshooting policy inheritance is that when both the Block Inheritance option and the No Override option are enabled, the No Override option has precedence.
  • Remember that the Block Inheritance applies to the entire site, domain, or OU; and therefore can prevent Group Policy settings from being applied. If you have a situation where a particular GPO is not being applied, verify that the GPO is not being blocked./li>
  • Verify that the user or computer belong to a security group that has the Allow

Popular posts from this blog


The BCD registry file controls which operating system installation starts and how long the boot manager waits before starting Windows. Basically, it’s like the Boot.ini file in earlier versions of Windows. If you need to edit it, the easiest way is to use the Startup And Recovery tool from within Vista. Just follow these steps: 1. Click Start. Right-click Computer, and then click Properties. 2. Click Advanced System Settings. 3. On the Advanced tab, under Startup and Recovery, click Settings. 4. Click the Default Operating System list, and edit other startup settings. Then, click OK. Same as Windows XP, right? But you’re probably not here because you couldn’t find that dialog box. You’re probably here because Windows Vista won’t start. In that case, you shouldn’t even worry about editing the BCD. Just run Startup Repair, and let the tool do what it’s supposed to. If you’re an advanced user, like an IT guy, you might want to edit the BCD file yourself. You can do this

DNS Scavenging.

                        DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997.  Despite many clever methods of ensuring that clients and DHCP servers that perform dynamic updates clean up after themselves sometimes DNS can get messy.  Remember that old test server that you built two years ago that caught fire before it could be used?  Probably not.  DNS still remembers it though.  There are two big issues with DNS scavenging that seem to come up a lot: "I'm hitting this 'scavenge now' button like a snare drum and nothing is happening.  Why?" or "I woke up this morning, my DNS zones are nearly empty and Active Directory is sitting in a corner rocking back and forth crying.  What happened?" This post should help us figure out when the first issue will happen and completely avoid the second.  We'll go through how scavenging is setup then I'll give you my best practices.  Scavenging s

AD LDS – Syncronizing AD LDS with Active Directory

First, we will install the AD LDS Instance: 1. Create and AD LDS instance by clicking Start -> Administrative Tools -> Active Directory Lightweight Directory Services Setup Wizard. The Setup Wizard appears. 2. Click Next . The Setup Options dialog box appears. For the sake of this guide, a unique instance will be the primary focus. I will have a separate post regarding AD LDS replication at some point in the near future. 3. Select A unique instance . 4. Click Next and the Instance Name dialog box appears. The instance name will help you identify and differentiate it from other instances that you may have installed on the same end point. The instance name will be listed in the data directory for the instance as well as in the Add or Remove Programs snap-in. 5. Enter a unique instance name, for example IDG. 6. Click Next to display the Ports configuration dialog box. 7. Leave ports at their default values unless you have conflicts with the default values. 8. Click N