Because the final application of Group Policy settings depends heavily on the domain controllers replicating the GPOs, there are many areas where the process can fail. This is not to say that Active Directory is unstable; rather, there are many areas that can be configured incorrectly, which can break the application of Group Policy settings.
This section focuses on the many aspects of configuration that are on the server side or for which the server is responsible. Smaller problems will arise due to the server, but we will look only at the most common problems that make Group Policy fail to apply to clients.
It is common for Group Policy settings to fail to apply to computers and users in branch offices where the WAN link is not reliable. If the WAN link is unavailable, a user who has never logged on to the computer before will be unable to logon if there is no local domain controller to authenticate him. However, if the user has logged on successfully before, he will be able to log on using his cached credentials even if the WAN link is down and a domain controller is available, but there are several policy settings that can restrict this kind of behavior. If you find that certain Group Policy settings are not being applied to certain users, it might be because those users have logged on using cached credentials.
The first option you can configure using policy is to limit the number of logons that can be cached on the client in case the domain controller becomes unavailable. This setting can be found under the Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options node. The policy setting is named Interactive Logon: Number Of Previous Logons To Cache (In Case Domain Controller Is Not Available), as shown in Figure 17-17. If this policy is set to 0, no cached logons are allowed, which will make the logon attempt fail should the WAN link go down and no domain controller be available.
The other option configurable by policy is for use with roaming profiles. This setting is located under the Computer ConfigurationAdministrative TemplatesSystemUser Profiles node. The setting is named Wait For Remote User Profile, as shown in Figure 17-18. It forces the user to wait for his roaming user profile to log on to the network. The roaming user profile is determined by the domain controller that authenticates the user. If no domain controller can authenticate the user, the roaming profile will not be found. Ideally, this setting should also be configured with Delete Cached Copies Of Roaming Profiles, which is located under the same path, to ensure that the user cannot log on with any cached credentials (because there won’t be any).
If the user successfully logs on with cached credentials, the GPO settings that applied the last logon will still be cached in his user profile. However, any new GPO settings that were configured since the last logon will not be applied to the user. This can result in a security vulnerability, depending on which security settings were configured using Group Policy since the last logon. This is why many companies do not allow logons using cached credentials.
If the Active Directory database becomes corrupt, Group Policy settings are almost guaranteed to fail to apply. If the Active Directory database references the wrong GUID, DNS server, or SRV record, Group Policy might fail to apply to user and computer accounts. In many cases, the computer or user account might fail to log on altogether, presenting an error that the domain the account is trying to authenticate to is no longer available.
In such a case, you must track down the root problem. If the problem is that a domain controller has failed, you can replace either the Active Directory database on this domain controller or the entire domain controller. If the problem is bigger and the entire Active Directory database is corrupt, you must restore a valid copy of the Active Directory database using your backup application and/or use the authoritative restore procedure.
More Info
For more information about nonauthoritative and authoritative restores of the Active Directory database, see "The Active Directory Operations Guide" at www.microsoft.com/technet.
If the computer-based GPO settings are being applied properly but the user-based GPO settings are not, the problem might relate to where the user is being authenticated. If all of the computer, network, and DNS settings are configured properly, it is difficult to bypass the computer-based GPO settings. However, if a user logs on to the local computer and be authenticated by the local Security Accounts Manager (SAM), the user-based GPO settings that reside at the Active Directory level will not apply.
Users log on locally for many reasons. Some administrators use local accounts to bypass GPO security settings. Some users have a local account for reasons that typically yield little benefit. In all cases, if a user is allowed to log on locally, the GPO settings that exist within GPOs linked to Active Directory containers will not apply to the user account.
One solution is to not allow local user accounts in the local SAM of clients and servers. These accounts are seldom needed. Considering the security vulnerabilities that these accounts can lead to, the case for eliminating these accounts and not allowing users to use the local SAM to authenticate is a strong one.
You can even remove the use of the Administrator account in the local SAM by disabling this account. To disable it, you configure a policy setting located at this path: Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options. Under this node, you configure the Accounts: Administrator Account Status policy to be disabled, as shown in Figure 17-19. This completely disables the account—no one can use it for local logons or any other resource access, except for Safe Mode recovery.
The SYSVOL folder contains the configurable files that are associated with GPOs. Here you will find the .adm templates, Registry.pol files, scripts, and more. These files can be manipulated manually, but it is best not to do so. However, manual configuration is not the only way that the SYSVOL files can be misconfigured or corrupted.
Because the application of GPOs depends on the contents of the SYSVOL, incorrect settings within the SYSVOL structure can cause some or all of the settings to fail to apply. The failures might be as small as one setting not applying or as large as no setting from any GPO applying to any object, including domain controllers. Therefore, it is best to avoid going into the SYSVOL structure and modifying ACLs, files, folders, or settings.
The remainder of this section describes some of the ways in which the SYSVOL can be misconfigured or corrupted.
There are many files within the Policies subfolder under the SYSVOL structure. These GPO files are named by GUID, as shown in Figure 17-20. Under each GUID, you will find a collection of files and folders that are logically arranged so the GPO settings can be updated, backed up, and applied correctly. However, if the contents of the files, folders, or text within the files are misconfigured, the GPO settings will most likely fail to apply.
One example of an update to these files is an update to the Registry.pol file. This file contains the updates that are made to the Administrative Templates settings within the GPO. The file contains some text that can be read, plus some text that can’t be updated manually. Even though you can read some of this text, you should not update these files manually. Should an administrator attempt to make a change to the value of a setting within the Registry.pol file, but the value was set incorrectly, as was the syntax after the value. This caused the entire suite of settings within the Registry.pol file to fail to apply. The problem did not end there. Because the file was updated and had a new timestamp, the update replicated to all domain controllers and caused this failure on every computer that was supposed to have the settings within this GPO apply.
The SYSVOL share is essential for Active Directory to function. Included in Active Directory is the application of GPOs. It is easy to go in and remove the SYSVOL share from any domain controller—this breaks all replication to and from that domain controller. If the domain controller that has the SYSVOL broken is used as a replication bridge between two other domain controllers, replication can fail for more than just the one domain controller.
If the SYSVOL share is removed, you will have numerous entries in the Event Viewer logs indicating that much of the Active Directory replication and GPO application is failing. To fix this problem, you must restore the SYSVOL share and ensure that the domain controller is joined back to the replica set. For more information on how to accomplish this, see article 257338 in the Microsoft Knowledge Base.
When you install and configure domain controllers, you might sometimes need to change the system time or time zone. You must be cautious about doing this so files don’t get out of synch when it comes to replication. If the system time on a computer is is changed to a time in the future, all files created after this time will receive the time stamp of that time zone. However, if the time is reset back to an earlier time zone soon thereafter, due to a mistake of some sort, the files that were created in the interim period will have a "future" timestamp. Future time-stamped files do not replicate and cause severe issues for Active Directory and GPO functionality.
To ensure that this does not happen, make sure the time zone and server system time are set properly before any files are changed. Otherwise, you might need to restore Active Directory files or GPO files from a tape backup.
When a GPO is created or modified, those changes must be updated on all of the domain controllers in the domain. If the replication fails or does not finish before the GPOs need to be refreshed, target accounts might not receive the proper GPO settings. There are many reasons that replication and convergence might take a long time or fail. We will go over some of the main reasons that GPOs don’t apply due to replication or convergence issues.
We have seen that there are two parts of a GPO. One part is stored in Active Directory and is referred to as the Group Policy container (GPC). The other part is stored in the SYSVOL and is referred to as the Group Policy template (GPT). When a GPO is created or modified, both parts are updated on the domain controller that performs the update. These changes must then be replicated to other domain controllers before the changes take affect in all accounts in the domain.
The main issue with having two parts of a GPO is that each part relies on a different replication service. The GPC relies on Active Directory replication, which is driven by the Knowledge Consistency Checker (KCC) and Intersite Topology Generator (ISTG) for replicating between Active Directory sites. The GPT relies on the File Replication Service (FRS), which takes care of replicating the SYSVOL contents between domain controllers.
These two replication services do not communicate or rely on each other in any way. Therefore, they replicate on different intervals and at different times. This can cause a difference in GPC and GPT version on any one domain controller before the replication of the two parts synchronizes. During this time, you might find that GPO settings that are applied to accounts are not the latest configured settings.
If this problem occurs with the GPC and GPT being out of sync, you can verify the version number of each portion using the GPMC, as shown in Figure 17-21. This will help you figure out which portion of the GPO is not synchronized on each domain controller. Then you can track down whether Active Directory replication or FRS is just not finished replicating or if there is a bigger problem with replication.
When a GPO is modified on a domain controller that is located in a specific site, it should only take a maximum of 15 minutes to replicate to all of the other domain controllers in that site. So if you are waiting for a GPO setting to show up on a computer, you might need to be patient. If, after 15 minutes or more, the GPO settings are not applying properly, you should confirm that the changes have replicated to all domain controllers within the site. If the changes have not replicated to all of the domain controllers in the site, you should investigate the Active Directory replication and FRS replication services. If the GPO changes have replicated to all domain controllers, you must investigate other possible problems.
Intersite replication adds more complexity to the concept of standard GPO replication. Not only do GPOs need to replicate between domain controllers in the same site, but they must replicate to domain controllers in different sites. Because one of the main reasons for site creation is to control replication, GPO application from site to site can vary over time after a GPO has been updated.
It can be difficult to track down GPO replication problems across sites. You can take the same philosophy for verifying the GPC and GPT versions on domain controllers in the different sites, to see if they have been synchronized. If the versions are not in synch, your first task is to see whether the replication should have occurred already. With replication across sites, the replication interval is set by the administrator when the sites are created. The default site replication interval is 180 minutes, but it can be set as low as 15 minutes and as high as many hours. Therefore, it is a good idea to first check the intersite replication interval to ensure that replication should have occurred.
If replication should have occurred, you must verify that Active Directory replication and FRS replication are working properly. If so, you might have another issue that is causing the intersite replication to fail. Checking the event logs can help you track down these possible problems.
DNS is integral to Active Directory. Without DNS, Active Directory features, functions, and communications will fail. Thus, GPOs rely on DNS to ensure that the client can find the correct domain controller to apply settings. The configurations for DNS with regard to the servers and clients are not complex, but in certain areas the configurations can become incorrect, causing GPOs to fail to apply.
On most networks, clients are configured to receive their IP configurations from the DHCP server. One of the IP configurations they receive is the IP addresses of the primary and secondary DNS servers. This information is manually input into the DHCP server and can be misconfigured or can become incorrect if the DNS server is changed.
If the client receives the wrong DNS server IP address, the client can still authenticate the user. However, in almost every case the GPOs will not apply from the domain controller. No error message will appear, so the problem can be difficult to track down.
Even though a client computer is configured to receive its IP address from the DHCP server, the IP configuration might allow for a manual configuration for the DNS server. If a client is manually configured with the incorrect DNS IP address, GPOs will fail to apply.
This scenario can happen in several ways. For example, users of laptop computers might manually configure their DNS server IP address when they go to a branch office or use their home network. For example, they might configure the IP address of an Internet-based DNS server so they can browse the Web while off the corporate network. Another example is when the local user of the computer does not want GPOs to apply to her. Although this is a breach of corporate security policy, users sometimes misconfigure DNS to bypass GPOs but still gain access to Web resources. To prevent this behavior, you need to enforce the corporate security policy or remove the ability for users to make these modifications on their local computer.
Domain controllers are found by domain computers through DNS. Depending on what the domain computer needs from the domain controller, they might go to DNS to find the domain controller that is running that service. These services are stored in DNS as SRV records. There are SRV records for domain controller services, DFS, Kerberos, and more.
If these SRV records fail to get inserted into DNS for the domain controllers, the application of GPOs to some clients might fail. The SRV records might also be deleted accidentally or by an attacker. If the SRV records are missing for a domain controller, you can stop and start the NETLOGON service for the domain controller to update the SRV records within the DNS server.
Warning
You should stop and start the NETLOGON service when no clients are attempting to authenticate to the domain controller. If the domain controller is not communicating with any network computers, you must toggle the NETLOGON service regardless of the network traffic attempting to communicate with it.