Network Management Experience Sharing: Experiences in troubleshooting group policies (1)

For network administrators, the most common complaints about group policies are: "I set a policy, why does it not take effect ?". For some relatively large network environments, group policies can reduce the management of network administrators, but the chances of problems are still relatively high. On the one hand, this is caused by our carelessness in our daily operations, and on the other hand, the final results are inconsistent with our ideas due to the mutual influence of policies.

Key Points of Group Policy Application

Here, I will give some suggestions that Microsoft does not recommend:

1. Do not delete two default policies (default domain policy and default Domain Controller Policy). Many problems occur due to the deletion of these two default policies. Use the Group Policy Management Console (GPMC) tool to back up the two default policies for future restoration. If you delete the default policies directly through GPMC, we will find that it does not work, but readers with a little experience know how to delete them. Since they are not recommended, I hope you will not delete them.

2. group policies cannot be linked to user groups. There are many administrators who first contact the Active Directory. It is often assumed that the Group Policy takes effect for a user group, which is not feasible. Group policies are not policies set for user groups, but a set of policies that can only be linked to sites, organizational units, and domains.

3. Question about the effectiveness of group policies

(1) Effective order

Normal Order: Local Policies → Site Policies → domain policies → parent OU policies → child OU policies.

During use, a "application security policy" prompt is displayed before the logon dialog box appears. This is the process in which the local policy takes effect.

When a conflict occurs, the latest policy settings overwrite other settings. The computer setting is higher than the user setting (even if the user setting is later ). The policy setting of the parent container group conflicts with that of the sub-container, and the group policy setting in the sub-container takes effect. Multiple Policies of the same container take effect in priority order. Therefore, when multiple GPO containers are linked to a container, you may want to take a closer look at their sequence, which may be caused by improper sequence.

(2) effective time

By default, non-Domain Controller computers refresh the policy every 90 minutes, which contains a random 30-minute time offset, the Time Offset ensures that multiple computers are not connected to the same domain controller at the same time. The domain controller refresh every 5 minutes to ensure that the urgently updated group policy settings (Security Settings) can be implemented in a timely manner, you can change it in "Refresh Interval of Domain Controller group policy" (1 ).

Figure 1 "Refresh Interval of Domain Controller Group Policy"

In Windows 2000, you can use the secedit/refreshpolicy machine_policy or secedit/refreshpolicy user_policy command to force refresh. in Windows XP or Windows 2003, use gpresult/force to force refresh. If the new setting does not take effect, consider whether it is a refreshing interval.

Group Policy General troubleshooting

If you follow the above suggestions and some settings of the result group policy still do not take effect as expected, we need to troubleshoot the problem.

1. First, make sure that the client obtains the relevant policies. For example, if you want all computers in the domain not to display the username of the last logon to ensure security, but it does not take effect on all clients, it indicates that this policy may not be obtained by the client. From Gpresult or group policy result set, you can know which policies are obtained by the client. The former is the command line mode, and the latter is the graphical interface, with the same functions. The following describes how to use the result set of a group policy.

(1) Open gpmc. msc, click the Group Policy result collection wizard, select the local computer or remote computer, and select the user to display the final result, we can view the result (2 ).

Figure 2 view results

In "Group Policy Object> application policy", we can see which GPO is applied on the problematic client, and which GPO is not applied. If a group policy is not applied, the setting will definitely not take effect, because the computer does not get this policy at all.

As mentioned in the case (we hope that all computers in the domain do not display the username of the last logon to ensure security, but it is a pity that it does not take effect on all clients ), later, gpresult was run on a random client. It was found that the user name policy set for the computer not to Display the last logon (name Do not Display last logon name at the time) was not applied to the client at all, the policy does not take effect.

2. If there are multiple domain controllers in the network, make sure that the policies of the multiple domain controllers are consistent. Check that gpotool is running (you need to install the Windows Resource Kit Toolkit ).

Validating DCs... Available DCs: mic-technet.dc.mic Searching for policies... Found 4 policies Policy {31B2F340-016D-11D2-945F-00C04FB984F9} Friendly name: Default Domain Policy Policy OK ========================================================== Policy {6AC1786C-016F-11D2-945F-00C04FB984F9} Friendly name: Default Domain Controllers Policy Policy OK ========================================================== Policy {90BD780C-D2E8-44CB-97B8-80B343852457} Friendly name: Do not display logon name Policy OK ========================================================== Policy {CC2C8E4F-FA55-4824-AC75-0122494DCC31} Friendly name: user Policy OK ========================================================== Policies OK

This is the result of running gpotool. Of course, I am only using a virtual environment and only one domain controller. You can compare the problematic logs with the normal logs to find the problem. Imagine that if there are two domain controllers, and there is another problem with the replication between them, it means that the group policies of each domain controller are not uniform, and the natural client will encounter problems during the application.

3. Check whether the policy object is in AD and Sysvol, and whether the GUID is associated with the correct GPO.

(1) view the GUID of the Group Policy.

(2) Use Search. vbs to check whether the LDAP protocol is correct and whether GPO and GUID correspond to the actual meaning.

Search. vbs is a script tool under the Windows 2003 installation CD Support \ Tools \ Support. cab. You can resolve the GPO name to GUID.

Usage:

Cscript search. vbs "LDAP: // dc = mydomain, dc = com"

/C: "& (objectClass = groupPolicyContainer) (displayName = Default Domain

Policy) "/P: name/S: SubTree

Replace mydomain and com with your own domain name.

3. If the problem persists after the preceding two steps, activate userenv. log:

Open the Registry Editor and Navigate to HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon.

Create a dword Value: UserEnv DebugLevel. The data is 10002 (Windows 2000/XP), and 2003 for Windows 30002. After restarting, you can find the Userenv. log File under % SystemRoot % \ Debug \ UserMode. This file is very helpful for us to solve the problems of user configuration files and Group Policy Processing.

For example, you may find in this file:

USERENV (178.63c) 22: 27: 23: 188 EvalList: Object cannot be accessed

This indicates that the logged-on user has no permissions for the GPO to be applied to him. Pay attention to the permissions of the Group Policy.

4. If the policy related to security settings does not take effect, you can enable Winlogon:

Open the Registry Editor and Navigate to HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon \ GPExtensions \ {extensions}. Create a New DWORD Value named Extension DebugLevel and set the value to 2, refresh the policy to generate winlogon in Windows \ Security \ Logs. log. All security settings are recorded in detail.

For example, when a Windows 2000-based computer is started, the event viewer records event IDs 1202 and 1000 every five minutes.

The following error message is displayed when you view the Winlogon. log file:

Error 1332: No mapping between account names and security IDs was done. Cannot find Power Users.

Obviously, someone assigned security rights to the Power Users group, but when the computer is promoted to a domain controller, the Power Users Group will be deleted, however, the Group Policy does not delete the corresponding permissions, and the computer will not stop looking for (accurately speaking, the corresponding) Power Users group, so an error will be reported.

When viewing Userenv. log and Winlogon. log, you can follow the following information: fail, error, and cannot.