GP Preferences has a ton of compelling reasons to use it; the functionality allows admins to configure settings that are difficult to impossible to achieve through policy (deploying shortcuts, setting up drive maps, managing devices…) and the configuration UI is eerily familiar to what the user’s UI looks like to configure the same settings. Pretty easy to figure out where everything is when you already know the layout, right? The subtlety, however, is in knowing when you have actually set the configurations to be captured in the preference item and set to be applied with F5-F8 keys, indicated by the red or green icons.

This is my favorite example of the sweet UI and the subtle differences. These are the Internet settings options I see as a user for IE7:

And these are the same two tabs in Preferences. Notice the only difference in the Preference dialogs vs. the user is the right-most Common tab (where all of the interesting targeting and special behavior rules can be set up).  

The other difference is the red dashed line or green circles that hover around the configuration options. What does this mean? Why is it there? And more importantly…how am I supposed to use it?

Look at all those options  you can adjust in the Advanced Tab; that’s a lot of granularity and a lot of work to get exactly right. Instead of forcing admins to modify every single setting when they configure an IE option, Preferences offers the ability to pick and choose which setting choices the admin wants to be pushed out. Those that are red underlined (or have a red circle next to them) are going to be ignored. Those that are underlined with a green solid line (or next to a green circle) are going to be noted, captured in the GPO, and enforced on the target user or computer. So I can make a Preference item that only captures three or four settings out of a whole menu of settings. Cool, right?

To ensure you aren’t pushing out unwanted settings, settings are ignored by default; this is indicated with red-dashed-underlined or a red circle icon. This is true of the home page, for example (you can see the red dashed line in the image above). If you do not consciously make the choice to have these settings captured, they will be ignored. No green line/circle, no configuration.  This is what causes most people to have issues with Preferences; they go through all the work of configuring the settings they want, set up targeting, link the GPO, gpupdate…nothing changes. The GPO applied in the report, but what happened? The settings were still set to be ignored, so nothing was pushed out.

The mechanism to specify or ignore settings is controlled by the F5 – F6 – F7 – F8 keys. They are grouped in pairs by outside keys (F5, F8)  and inner; (F6, F7). The outer keys manage all the settings at once; F5 makes everything count, all the settings get green-underlined. F8 sets them all to be ignored, red-dashed-underline. F6 and F7 work on individual settings; F6 will light up one setting at a time, F7 will set one setting to be ignored. Here’s a diagram, hopefully it doesn’t make it more confusing. I’ll write up some examples for the next blog post, hope this helps so far!

In this scenario, Group Policy settings are not applied on the member computer. Additionally, the following event is logged in the System log on the member computer:

Date: Date
Event ID: 1058
Level: Error
Keywords:
User: UserSID
Computer: CompuerName
Description:
The processing of Group Policy failed. Windows attempted to read the file \\ path \gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

Note This problem occurs only on member computers that are running Windows Server 2008 or Windows Vista Service Pack 1 (SP1). It does not occur on member computers that are running Windows Server 2003, Windows XP, or the release version of Windows Vista.

 For more information, check the following article:

https://support.microsoft.com/kb/950876

Where can you use passwords?

• Local User preference items: When you create or modify a local user account, you can specify both a user name and a password for the account.
• Data Source preference items: If a user name and password are required to access the data source, you can provide them in the preference item. If you do so, end users to whom the preference item applies can access the data source regardless of their own permissions, but only if the specified account has the necessary permissions.
• Mapped Drive preference items: You can specify the user name and password to be used to connect to a mapped drive. If you do so, end users to whom the preference item applies can access the mapped drive regardless of their own permissions, but only if the specified account has the necessary permissions.
• Scheduled Task or Immediate Task preference items: You can configure a scheduled task to run under the security context of a specified user (allowing the task to run regardless of whether that user is logged on), by selecting the Run as check box and providing a user name and password.
• Service preference items: You can modify which account the service runs under by selecting Local System account or by selecting This account and specifying a user name and password.

For the user name in a Data Source, Mapped Drive, Scheduled Task, Immediate Task, or Service preference item, you can specify a local user account on multiple computers using the format .\UserName, or a domain account using the DomainName\UserName format.

Are passwords in preference items secure?
Passwords in Group Policy preference items are protected using 256-bit AES encryption. In the XML source code of a preference item, the password does not appear as clear text; it is encrypted. The client reads the XML, decrypts the password, and implements the configuration.

Although passwords in Group Policy preference items are encrypted, they are not completely secure and therefore are not appropriate for situations requiring high security. Consider the security requirements of your situation, and use discretion when deciding whether to include passwords in preference items.

1.            Server Manager

2.            Changes to Domain Controller Promotion

3.            Re start able Domain Controller

4.            Distributed File System Namespace - DFSN

5.            Distributed File System Replication – DFSR

6.            Fine Grained Password Policy

7.            RSAT Tools

8.            IFM Support

9.            Auditing

10.          ADMT 3.01

11.          Windows Server Backup (System State)

12.          Read Only Domain Controller (RODC)

13.          Terminal Service Licensing

14.          Group Policy Changes

15.          Active Directory Light Weight Directory Services

16.          Certificates

17.          Webcasts

Changes to Windows 2008 Active Directory in a Nutshell.pdf

If we create a group and assign the users to the group.

Create a loopback policy for users in merge mode and assign the group to security filtering for the loopback policy and give the following permission:

Read and Apply Group Policy.

User side of the policy will not apply.

From the GPSVC logs, we see the following:

Machine Side:

GPSVC(434.4b8) 15:00:19:206 EvalList: Object <cn={630069B4-401B-4DB0-9559-EF4D821D04FE},cn=policies,cn=system,DC=childA,DC=dom147330,DC=local> cannot be accessed

User Side:

GPSVC(434.1c8) 15:05:54:924 EvalList: Object <cn={630069B4-401B-4DB0-9559-EF4D821D04FE},cn=policies,cn=system,DC=childA,DC=dom147330,DC=local> cannot be accessed

For more details look into the below article:

https://support.microsoft.com/kb/953768

Log Name: Application
Source: Microsoft-Windows-User Profiles Service
Date: Date
Event ID: 1511
Task Category: None
Level: Warning
Keywords: Classic
User: User
Computer: Computer
Description:
Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.

Title: A temporary profile is loaded after you log on to a Windows Vista-based system 

Check the following article, which describes about the cause.

https://support.microsoft.com/kb/947242 

Check the following article, which describes about the cause.

https://support.microsoft.com/kb/947242 

Windows Vista provides a new centralized event logging system and Event Viewer. Features such as cross-log querying, scheduled task integration, and page support in filtered views make the Event Viewer the ideal tool to view the health of the computer and the health of Group Policy.

Earlier instances of Group Policy used the event source name "Userenv". Earlier versions of Windows shared this source name with other components. This made it difficult to identify events specific to Group Policy. Also, when troubleshooting, the information provided by Group Policy events added little value.

In Windows Vista, Group Policy writes all event and logging information to the Event Viewer and uses a source name of "Group Policy." This makes it easier to locate events relevant to Group Policy. Additional improvements were made by updating the details of each event. These improvements include better explanations of the event in the event description, possible causes, and suggested followup actions. You can locate Group Policy events in the System event log and the Group Policy operational event log.

How to Start the Event Viewer

System event log

You use the System event log to view events logged by Windows and Windows Services. Windows categorizes these events as error, warnings, and informational events. The Group Policy service logs administrative events in the System log. Administrative events help you determine the initial state of Group Policy processing. These events appeared in the Application log on earlier versions of Windows.

To start Event Viewer

Group Policy operational log

The Group Policy operational log provides you a view of the work the Group Policy service performs before and during Group Policy processing. Earlier versions of Windows provided this same functionality by using userenv logging. However, other Windows components shared this log file, which created information unrelated to Group Policy. Additionally, entries found in userenv log files were ambiguous, confusing, and usually required an advanced technical understanding of Group Policy. The Group Policy operational log replaces the userenv log file and provides comprehensive and detailed event descriptions than its predecessor.

To view the Group Policy operational log

Troubleshooting Group Policy Using Event Logs

Using the Event Viewer

You can use the Event Viewer to isolate the cause of most Group Policy failures. Windows Vista provides a new user interface for the Event Viewer. You should familiarize yourself with the new Event Viewer and where you locate information related to Group Policy processing. The following section shows you the location of information you will use when troubleshooting Group Policy.

General tab

Figure 1 The General tab of a Group Policy event as seen using the Event Viewer

Description: Contains text that describes the logged event. Group Policy events usually contain information describing the events, possible reasons why the event occurred, and suggested followup actions.

Source: The name of the software that logs the event. Group Policy events always use the source of "GroupPolicy."

Event ID: A numerical ID representing the type of event logged. Administrative events in the System event log and the Group Policy operation event log use event ids. You can find more information about specific Group Policy events and event IDs in the appendices of this document.

Level: Classifies the severity of an event. Group Policy events use Error, Informational, and Warning event levels.

User: The name of the user account that triggered the logged event. The Group Policy service uses the name SYSTEM for recording events related to computer policy processing. User policy processing events use the name of the user who is processing policy.

Logged: The date and local time when the event logging system logged the event. Group Policy in Windows Vista has the opportunity to refresh more often. When troubleshooting Group Policy, make sure the events you are viewing match the time of the reported problem.

Computer: The name of the computer on which the event occurred.

More Information: A hyperlink to the Microsoft TechNet Web site. Clicking this link provides you with information about the event, possible causes for the event, and suggestions that may resolve the issue, if the event is a warning or error.

Details tab

The Event Logging system in Windows Vista records each event using XML. This allows the Group Policy service to record additional information about each event. This information is useful for troubleshooting Group Policy; however, you cannot see the information from the General tab. Therefore, you use the Details tab to view the additional information. The Details tab provides two views to this data: XML view and Friendly view. The XML view displays the additional event data in raw XML and is difficult to read. The Friendly view displays this same data in an expandable, easy to read, hierarchical view. You will use the Friendly view when you need to view this additional data.

System and EventData nodes

The Friendly view of an event message has two nodes: System and EventData. The Group Policy service writes information in both nodes. The following section describes important fields included in the Friendly view that you use when troubleshooting Group Policy.

Figure 2 The Details tab of a Group Policy event as seen using the Event Viewer

System\Correlation:ActivityID

The ActivityID represents one instance of Group Policy processing. The Group Policy service creates a unique ActivityID each time Group Policy refreshes. For example, a computer processes Group Policy during startup. At that time, the Group Policy service assigns that instance of processing an ActivityID. Further events logged during that instance use the same ActivityID until that instance of Group Policy processing completes (Group Policy processing completes when the process ends either successfully or with errors). Users process Group Policy during the logon process. Again, the Group Policy service assigns a unique ActivityID to that instance of Group Policy processing and uses it until processing completes. This behavior repeats for each new instance of Group Policy processing, which includes automatic and forced Group Policy refreshes. You can view this value on all Group Policy events.

EventData\PolicyActivityID

This is the same value as the System\Correlation:ActivityID. The Group Policy service uses this value to identify an instance of Group Policy processing. You can view this value in policy start events (4000–4007).

EventData\PrincipalSamName

This value contains the name of the security principal to which the Group Policy service applies, the name of the computer during computer policy processing, and the name of the user during user policy processing. The event displays the format as domainname\computer or domainname\user. This information appears in policy start events (4000–4007), next policy application events (5315), policy end events (8000–8007), and scripts processing start and end events (4018, 5018).

EventData\IsDomainJoined

This value is True when the computer is a member of a domain and False when not. You can view this value on policy start events (4000–4007).

EventData\IsBackgoundProcessing

This value is True when the Group Policy service applies policy settings in the background. Otherwise, this value is False. When this value and the IsAsyncProcessing are False, then the Group Policy service applies policy settings synchronously in the foreground. You can view this value on policy start events (4000–4007).

EventData\IsAsyncProcessing

This value is True when the Group Policy service applies policy setting asynchronously in the foreground. Otherwise, this value is False. When this value and the IsBackgroundProcessing are False, then the Group Policy service applies policy settings synchronously in the foreground. You can view this value on policy start events (4000–4007).

EventData\PolicyApplicationMode

The Group Policy service records the type of Group Policy processing in the PolicyApplicationMode field. The PolicyApplicationMode field is one of three values. Those values are:

EventData\PolicyProcessingMode

You use the PolicyProcessingMode field to determine the presence of loopback processing and whether loopback processing is in Merge or Replace mode.

EventData\ProcessingTimeInMilliseconds

You use the ProcessingTimeInMilliseconds field to determine the amount of time, in milliseconds, the described event used to complete the operation.

Note

1 millisecond is .1000 of a second. To determine the number of elapsed seconds, divide the value in ProcessingTimeInMilliseconds by 1000. For example, a ProcessingTimeInMilliseconds value of 12,747 equates to 12.74 seconds.

EventData\DCName

The Group Policy service records the name of a domain controller in the DCName field. The name found in this field is the domain controller the Group Policy service uses when communicating with Active Directory.

EventData\ErrorCode and EventData\ErrorDescription

These two fields appear only on error events. The ErrorCode field provides a value, represented as a decimal, that the described event encountered. The ErrorDescription field provides a short description of the ErrorCode value.

Where to start

The improvements made in the Group Policy service make troubleshooting more methodical than in earlier versions. If you are experiencing problems with Group Policy on Windows Vista, start troubleshooting by using these steps.

Using the System event log to troubleshoot Group Policy

·      Start troubleshooting Group Policy by using the System event log. The Group Policy service writes administrative events to the System event logs. The status of the Group Policy service is indicated by:

·      An informational event: The Group Policy service is functioning properly.

·      A warning event: The Group Policy service is functioning properly, but other dependencies may have failed.

·      An error event: The Group Policy service has failed.

Read the event description when you encounter these events. In most cases, the event description provides you with information about the event, what may cause the event, and followup suggestions.

·      Click the More Information link. If you need more help with troubleshooting the problem, then click the More Information link. This link connects you to the Microsoft TechNet Troubleshooting Web site and provides information specific to the event. The link also provides basic information you can use to help diagnose and resolve the event.

·      Read the Group Policy operational event log. The Group Policy service depends on other components for it to operate properly. Many times, problems with dependent components appear as Group Policy events in the System event log. These situations require you to review the sequence of policy application for the user or computer using the Group Policy operational event log. Use the set of procedures in the next section, "Troubleshooting using the Group Policy operational log."

Troubleshooting using the Group Policy operational log

Determine the instance of Group Policy processing

Before you view the Group Policy operational log, you must first determine the instance of Group Policy processing that failed.

How to determine an instance of Group Policy processing

To determine an instance of Group Policy processing

Create a custom view of a Group Policy instance

A computer often has more than one instance of Group Policy processing. Computers dedicated to running Terminal Services usually have more than one instance of Group Policy processing and operate simultaneously. Therefore, it is important to filter the Group Policy operational event log to show only events for the instance you are troubleshooting.

Use the following procedure to create a custom view of a Group Policy instance. You do this by using an Event Viewer query. This query creates a filtered view of the Group Policy operational log for a specific instance of Group Policy processing.

To create a custom view of a Group Policy instance

Important

Remember, the Group Policy service assigns a unique ActivityID for each instance of policy processing. For example, the Group Policy service assigns a unique ActivityID when user policy processing occurs during user logon. When Group Policy refreshes, the Group Policy service assigns another unique ActivityID to the instance of Group Policy responsible for refreshing user policy.

Reading the events

The Group Policy operational log has a range of event numbers dedicated to related events. The following table summarizes the range of events and their meanings.

Most of the events in the Group Policy operational log appear in pairs. For each start event, there is an end event. End events can be successful, warning, or error events. Usually these events share the last two digits in their event ids. For example, a 4017 event appears in the event log, which represents a Group Policy component beginning a specific action. If the action completes successfully, then the Group Policy service records a 5017 event. If the action completes with errors or fails then the Group Policy service records a 6017 or 7017 event, respectively. Policy processing events use the same numbering scheme for warning and error events messages in the 8000–8007 range for Group Policy success events. You can use these numbering patterns to quickly identify warning and failure events in the Group Policy operational log.

Analyzing events in the Event Viewer

The best way to troubleshoot Group Policy processing is to break the process down into three phases. Within each phase of the process is a subset of processing scenarios. When processing Group Policy, the Group Policy service iterates through each scenario as it transitions to each phase. The phases of Group Policy processing are:

·      Preprocessing phase: Indicates the beginning instance of Group Policy processing and gathers information required to process Group Policy.

·      Processing phase: Uses the information gathered in the preprocessing phase to cycle through each Group Policy extension, which applies policy settings to the user or computer.

·      Post-processing phase: Reports the end of the policy processing instance and records if the instance ended successfully, was processed with warnings, or failed.

This section provides information about each phase of Group Policy processing and the processing scenarios included in each phase.

Preprocessing phase

An instance of Group Policy processing starts with the pre-processing phase. This introductory phase is where the Group Policy service collects the required information to process Group Policy. The service collects this data using processing scenarios, which are small subsets of policy processing within a given phase of policy processing. The processing scenarios included in the preprocessing phase are:

·      Start policy processing

·      Retrieve account information

·      Domain controller discovery

·      Computer Role discovery

·      Security principal discovery

·      Loopback processing mode discovery

·      GPO discovery

·      Slow link detection

·      Nonsystem GP Extension discovery

Scenario: Start policy processing

Windows Vista creates an instance of Group Policy processing during startup, user logon, periodic and manual refreshes, and changes to network interfaces. Each instance of Group Policy begins with a Group Policy processing start event. This is an informational event with an event id ranging from 4000–4007. The following table lists the different types of Group Policy processing start events.

The Group Policy service records an event between 4000–4007 in the Group Policy operational log when an instance of Group Policy begins. Also included in the event is the ActivityID that identifies the instance of Group Policy processing. The following are examples of the start policy processing scenario.

12:41:16.472 4000 Starting computer boot policy processing for CONTOSO\MSTEPVISTA$.

       ActivityID: {89824640-B13A-4C67-B2EE-9DEB948182F9}

14:15:55.708 4001 Starting user logon Policy processing for CONTOSO\user.

       ActivityID: {6A64962C-6C32-4C8A-8E89-C53FB71A7A67}

Scenario: Retrieve account information

The Group Policy service must retrieve the location of the user or computer object in Active Directory before it can apply Group Policy. The GPO discovery scenario uses this information to determine which Group Policy objects are within scope for the given user or computer. The retrieve account information scenario includes the following events:

Event ID 5320: Informational/successful interaction event

The Group Policy service writes this event to record information about an imminent interaction with a dependent component or a successful interaction with a dependent component. It is normal for this event to appear multiple times in the operational log. One of three different events may follow when the Group Policy service uses this event to describe an imminent interaction:

The following example shows the event 5320 used as an informational event in the retrieve account information scenario.

12:41:16.632 5320 Attempting to retrieve the account information.

Event ID 4017: Start-trace component event

The Group Policy service records this event before making a system call. Often, the Group Policy service must use another function of Windows to gather information required to process Group Policy. When a component of Windows asks another component of Windows to perform some specific work and return the information, it is referred to as a system call. The Group Policy service performs system calls throughout an instance of Group Policy processing. Therefore, it is normal for these events to appear multiple times in the operational log.

Event ID 4017, sometimes called the "trace" event, represents the beginning of a system call. Each 4017 event must have a corresponding end event. The Group Policy service records one of the following end-trace events.

All end-trace events contain the elapsed time used by the system call. Warning and failed end-trace events contain error information in the Details tab. The following is an example of a start-trace event and successful end-trace event, both of which occur during the retrieve account information scenario.

2006-09-14 12:41:16.632 4017 Making system call to get account information.

2006-09-14 12:41:17.022 5017 The system call to get account information completed.

                          CN=MSTEPVISTA,CN=Computers,DC=contoso,DC=com                           The call completed in 390 milliseconds.

Note

Most ending events regardless of success, warning, or error display the amount of elapsed time, in milliseconds, from the start event. For example, end events for policy processing (event IDs 8000–8007) display how long it took the Group Policy service to process Group Policy. Trace events (events ending in 017) display elapsed time used to perform the system call. You can use these values to determine if Group Policy processing is delaying computer startup or user logon.

Scenario: Domain controller discovery

The Group Policy service reads Group Policy objects from Active Directory. Therefore, the service must discover a domain controller.

Event ID 4326: Domain controller discovery start event

This event marks the beginning of the domain controller (DC) discovery scenario and follows with event ID 5320, which is used to record information about the Group Policy service interacting with other portions of the operating system.

12:41:17.022 4326 Group Policy is trying to discover the Domain Controller information.

12:41:17.022 5320 Retrieving Domain Controller details.

The DC discovery process continues by recording a start-trace event, which includes the name of the discovered domain controller the Group Policy service uses to retrieve domain controller information, and corresponding end-trace event.

12:41:19.376 5017 The LDAP call to connect and bind to Active Directory completed.                  hq-con-srv-01.contoso.com                  The call completed after 171 milliseconds.

Next, the Group Policy service records the DC discovery end event.

Event ID 5308: DC discovery interaction event

The Group Policy service records the DC discovery interaction event to report the result of a specific interaction that occurred during the DC discovery scenario. Interaction events report the results of the interaction with a success, warning, or failure event. Also, each event includes additional information related to the reported result.

A successful DC interaction event contains information returned from the domain controller. This information includes the universal naming convention (UNC) path and IP address of the contacted domain controller. Warning and failure interaction events contain the return error code in the description. You can view a description of the error on the Details tab.

Note

It is common to see a start-trace event and end trace event before a DC discovery interaction event. Also, the end-trace event and the DC discovery interaction event usually start with the same number. For example, the first digit in a successful end-trace event is the number five; therefore, the first digit of the DC discovery interaction event is also a five. The following is an example of a successful DC discovery interaction event, which occurs during the Domain controller discovery scenario.

12:41:19.376 5308 Domain Controller details:                   Domain Controller Name: \\hq-con-srv-01.contoso.com                  Domain Controller IP Address : \\192.168.0.1

Event ID 5326: Domain controller discovery end event

Domain controller discovery completes when the Group Policy service records the DC discovery end event. This event reports the result of the Group Policy service's attempt to discover a domain controller. And, just like most of the other events, the DC discovery event has three statuses: success, warning, and error.

All of these event IDs report the lapsed time used to discover a domain controller. The following is a example of a complete DC discovery scenario.

12:41:17.022 4326 Group Policy is trying to discover the Domain Controller information.

12:41:17.022 5320 Retrieving Domain Controller details.

12:41:19.206 4017 Making LDAP calls to connect and bind to Active Directory.                  hq-con-srv-01.contoso.com

12:41:19.376 5017 The LDAP call to connect and bind to Active Directory completed.                  hq-con-srv-01.contoso.com                  The call completed after 171 milliseconds.

12:41:19.376 5308 Domain Controller details:                   Domain Controller Name : \\hq-con-srv-01.contoso.com                  Domain Controller IP Address : \\192.168.0.1

12:41:19.376 5326 Group Policy successfully discovered the Domain Controller in 2354 milliseconds.

Scenario: Computer role discovery

In this scenario, the Group Policy service detects the role of the computer. The computer role determines if the current computer is a standalone workstation or server; domain member computer, which supports directory services; domain controller; or domain member computer, which does not support directory services. The Group Policy service requires this information to apply Group Policy based on the computer's role.

Event ID 5309: Computer information event

The Group Policy service records this interaction event after an attempt to determine the role of the current computer.

Completed computer information events provide the role of the computer and the name of the network. The event displays the computer role as a numerical value. You can use the following table to determine the role of the computer.

The following is example output of the computer role discovery scenario.

12:41:19.416 5309 Computer details:                   Computer role : 2                  Network name :

Scenario: Security principal discovery

The Group Policy service applies Group Policy to computers and users. These are two examples of security principals (computers and users)—an entity recognized by the Windows security system. The Group Policy service must discover if the current security principal is a user or computer in order to apply the correct policy settings.

Event ID 5310: Security principal information event

The Group Policy service records this interaction event after its attempt to retrieve information about the current security principal, which is a computer or user.

The success and warning versions of the security principal information event contain information about the security principal, such as:

·      Distinguished name of the account.

·      Name of the domain where the account is located.

·      Name of the domain controller used to determine the account information.

·      Name of the domain where the domain controller resides.

The following is example output of the security principal discovery scenario

12:41:19.416 5310 Account details:             Account Name:CN=MSTEPVISTA,CN=Computers,DC=contoso,DC=com            Account Domain Name : contoso.com            DC Name : \\hq-con-srv-01.contoso.com            DC Domain Name : contoso.com

Scenario: Loopback processing mode discovery

Group Policy loopback processing changes how the Group Policy service applies user policies. Typically, the Group Policy service reads Group Policy objects within the scope of the user object to determine user policy setting. Depending on the mode, loopback processing merges or replaces the user policy settings with user policy settings included in Group Policy objects within the scope of the computer object.

Event ID 5311: Loopback processing mode event

The Group Policy service records this interaction event after it has determined the loopback processing mode.

The event description includes quoted text that identifies the loopback processing mode.

·      No loopback mode: Loopback processing is not enabled.

·      Merge: Loopback processing is enabled. The Group Policy service merges user settings within the scope of the computer with user setting within the scope of the user.

·      Replace: Loopback processing is enabled. The Group Policy service replaces user settings within the scope of the user with user settings from the scope of the computer.

The following is example output of the loopback processing mode discovery scenario.

12:41:19.486 5311 The loopback policy processing mode is "No loopback mode".

Scenario: GPO discovery

The Group Policy service discovers a list of Group Policy objects applicable to the computer or user. When the service has the list, it checks the accessibility of each Group Policy object by reading the gpt.ini file located on the system volume of the previously discovered domain controller. The Group Policy service records this activity with a series of start and end-trace events (event ID 4017). You can use the corresponding end-trace event to determine the success or failure of each attempt to read the gpt.ini file.

The following is example output of the start-trace events and end-trace events included in the GPO discovery scenario.

12:41:19.636 4017 Making system calls to access specified file. \\contoso.com\SysVol\contoso.com\Policies\{9F1DE622-0635-4F10-8A0B-4AEAEB5C3B79}\gpt.ini

12:41:20.307 5017 The system calls to access specified file completed. \\contoso.com\SysVol\contoso.com\Policies\{9F1DE622-0635-4F10-8A0B-4AEAEB5C3B79}\gpt.ini                  The call completed in 671 milliseconds.

The Group Policy service continues the GPO discovery process by recording the applied GPO discovery list event.

Event ID 5312: Applied GPO list event

The Group Policy service records this event after it checks each Group Policy object's gpt.ini file. The details of the event include the names of Group Policy objects applicable to the computer or user.

The following is example output of a Applied GPO list event.

12:41:20.958 5312 List of applicable Group Policy objects:                   Removable Devices Policy

                  Power Management Policy

                  Folder Redirection Policy

                  Default Domain Policy

The Group Policy service concludes the GPO discovery scenario by recording the filtered GPO list event.

Event ID 5313: Filtered GPO list event

The Group Policy service records this event at the conclusion of the GPO discovery scenario. The details of the event include the names of filtered Group Policy objects. The Group Policy service does not apply these GPOs to the computer or user.

The following is example output of the entire GPO discovery scenario.

12:41:19.636 4017 Making system calls to access specified file. \\contoso.com\SysVol\contoso.com\Policies\{9F1DE622-0635-4F10-8A0B-4AEAEB5C3B79}\gpt.ini

12:41:20.307 5017 The system calls to access specified file completed. \\contoso.com\SysVol\contoso.com\Policies\{9F1DE622-0635-4F10-8A0B-4AEAEB5C3B79}\gpt.ini                  The call completed in 671 milliseconds.

12:41:20.307 4017 Making system calls to access specified file. \\contoso.com\SysVol\contoso.com\Policies\{1AAEB8CD-E71C-4D7F-A658-A5331ED8FEF0}\gpt.ini

12:41:20.598 5017 The system calls to access specified file completed. \\contoso.com\SysVol\contoso.com\Policies\{1AAEB8CD-E71C-4D7F-A658-A5331ED8FEF0}\gpt.ini                  The call completed in 290 milliseconds.

12:41:20.598 4017 Making system calls to access specified file. \\contoso.com\SysVol\contoso.com\Policies\{898264CC-84A5-4A77-95F6-402B30778048}\gpt.ini

12:41:20.648 5017 The system calls to access specified file completed. \\contoso.com\SysVol\contoso.com\Policies\{898264CC-84A5-4A77-95F6-402B30778048}\gpt.ini                  The call completed in 51 milliseconds.

12:41:20.648 4017 Making system calls to access specified file. \\contoso.com\SysVol\contoso.com\Policies\{CBBCB787-7FE6-45B3-89D3-38D74D658BA3}\gpt.ini

12:41:20.668 5017 The system calls to access specified file completed. \\contoso.com\SysVol\contoso.com\Policies\{CBBCB787-7FE6-45B3-89D3-38D74D658BA3}\gpt.ini                  The call completed in 20 milliseconds.

12:41:20.668 4017 Making system calls to access specified file. \\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

12:41:20.848 5017 The system calls to access specified file completed. \\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini                  The call completed in 180 milliseconds.

12:41:20.958 5312 List of applicable Group Policy objects:                              Removable Devices Policy

                             Power Management Policy

                             Folder Redirection Policy

                             Default Domain Policy

12:41:20.958 5313 The following Group Policy objects were not applicable because they were filtered out :                              Local Group Policy

                                Not Applied (Empty)

                             Shell Restriction Policy

                                Not Applied (Empty)

Scenario: Slow link detection

Several components of Group Policy rely on a fast network connection. However, sometimes a fast network connection is not available. The Group Policy service is responsible for detecting and estimating bandwidth between the computer and the domain controller. The Group Policy service compares the result of the estimated bandwidth to the slow link threshold (configured by Group Policy). A value below the threshold results in the Group Policy service flagging the network connection as a slow link.

The Group Policy service shares this information with each Group Policy client-side extension. Client-side extensions have a default behavior when they encounter a slow link. For example, the security client-side extension processes Group Policy settings, even when the network connection is slow. However, the folder redirection client-side extension does not process its Group Policy settings over a slow network connection.

Event ID 5327: Estimated bandwidth event

The Group Policy service records this event when it successfully estimates the network bandwidth of a network interface.

The Group Policy service includes the estimated bandwidth, measured in kilobits per second (Kbps), in success and warning events.

Important

The Group Policy service uses all enabled network interfaces to determine the estimated bandwidth. It is important to remember this when troubleshooting computers with multiple network interfaces. The following is example output of a successful estimated bandwidth event

12:41:22.991 5327 Estimated network bandwidth on one of the connections: 1408 kbps.

After estimating the network bandwidth, the Group Policy service records a Network information event.

Event ID 5314: Network information event

The Group Policy service records this event after it estimates the network bandwidth for the computer. Success and warning network information events include:

·      The connection is a fast or slow link.

·      The estimated bandwidth value, measured in Kbps.

·      The slow link bandwidth threshold, also measured in Kbps.

The following is example output of the slow link detection scenario

12:41:22.991 5327 Estimated network bandwidth on one of the connections: 1408 kbps.

12:41:22.991 5314 A fast link was detected. The Estimated bandwidth is 1408 kbps. The slow link threshold is 500 kbps.

Scenario: Nonsystem GP extension discovery

The Group Policy service runs in a shared service host process with other components included with Windows Vista. The service operating in this shared service host increases its performance. However, third party developers can extend Group Policy by providing additional extensions, which are processed during Group Policy processing. The Group Policy service detects for non-system extensions during the pre-processing phase of Group Policy processing. The service reconfigures itself to run in a separate service host process when it detects non-system extensions, also known as standalone mode.

The Group Policy service reports this information in the operational log using the operational information event.

Event ID 5320: Operational information event

The Group Policy service uses this event to display success information in the operational log. This event is not specific to any given phase or scenario within Group Policy processing. It is common for the event description to change for this event.

The following is example output of the non–system extension discovery process.

12:41:28.058 5320 Checking for Group Policy client extensions that are not part of the system.

12:41:28.058 5320 Service configuration update to standalone is not required and will be skipped.

12:41:28.058 5320 Finished checking for non-system extensions.

Processing phase

The pre-processing phase of Group Policy processing collects information needed to process Group Policy settings. The next phase is the processing phase. In this phase, the Group Policy service uses the information it collected in the pre-processing phase to apply each policy setting. The service accomplishes this by passing the previously collected information to each of the system and nonsystem client-side extensions. This phase begins by recording a client-side extension (CSE) processing start event.

Event ID 4016: CSE processing start event

The Group Policy service records this event at the beginning of the processing phase. The Group Policy service records the name of the processing extension and a list of the applicable GPOs for the processing extension. This event, as do many other Group Policy events, has a corresponding end event. Each client-side extension reports to the Group Policy service when it finishes processing. At that time, the Group Policy service records the CSE processing end event.

Event ID 5016: CSE processing end event

The Group Policy service records this event when a client-side extension successfully completes its processing. The event description includes the name of the client-side extension and the amount of elapsed time (measures in milliseconds) the extension used for processing.

The following is example output of a CSE processing start and end events.

17:53:28.725 4016 Starting Registry Extension Processing.

      List of applicable Group Policy objects: (Changes were detected.)

                             Removable Devices Policy

                             Power Management Policy

                             Default Domain Policy

17:53:37.912 5016 Completed Registry Extension Processing in 9188 milliseconds.

17:53:38.022 4016 Starting Scripts Extension Processing.

      List of applicable Group Policy objects: (Changes were detected.)

                            User Logon Script Policy

17:53:38.537 5016 Completed Scripts Extension Processing in 516 milliseconds.

17:53:38.553 4016 Starting Security Extension Processing.

      List of applicable Group Policy objects: (Changes were detected.)

                            Default Domain Policy

17:53:56.912 5016 Completed Security Extension Processing in 18359 milliseconds.

17:53:56.928 4016 Starting EFS recovery Extension Processing.

      List of applicable Group Policy objects: (Changes were detected.)

                            EFS Recovery Agent Policy

17:53:57.365 5016 Completed EFS recovery Extension Processing in 437 milliseconds.

Post-processing phase

The post-processing phase completes an instance of Group Policy processing. The Group Policy service records a single event: the end policy processing event.

Event ID 8000: End policy processing event

This event identifies a successful completion of Group Policy processing for a computer. The Group Policy service reserves event IDs between 8000 and 8007 to indicate a particular type of Group Policy processing completed successfully.

Each end policy processing event has a corresponding warning and error event. These events follow the same pattern as described through the document. The corresponding warning event ID begins with a 6 with the last three digits identical to the start policy-processing event. The corresponding error event ID begins with a 7. Likewise, the remaining numbers in the event ID match those of the start policy processing event. For example, the Group Policy service records a start policy processing event with the event ID 4003. The service records an end policy processing event with the event ID 8003, when the instance completes successfully. If the instance completes with errors or fails altogether, the service records an end policy processing event with event ID 6003 or event ID 7003, respectively. The following is example output of a successful end policy processing event.

12:41:30.922 8000 Completed computer boot policy processing for CONTOSO\WKST007$ in 14 seconds.

Summary of policy processing

You can break an instance of Group Policy processing into three distinct parts: pre-processing, processing, and post-processing. During pre-processing, the Group Policy service collects information it needs for processing Group Policy settings. Next, the Group Policy service uses the information gathered during pre-processing and processes Group Policy settings. The service accomplishes this by sharing the previously collected data with each system and non-system client-side extension. Client-side extensions use this information to apply their individual policy settings and then return control to the Group Policy service. The service repeats this process until each client-side extension processes its portion of Group Policy. Post-processing is the final phase. During this phase, the Group Policy service reports the success or failure of the entire instance of Group Policy processing, along with elapsed time the instance used.

Group Policy troubleshooting quick reference

1.   Start by reading Group Policy events recorded in the System event log.

·      Warning events provide further information for you to follow to ensure the Group Policy service remains healthy.

·      Error events provide you with information that describes the failure and probable causes.

·      Use the More Information link included in the event message. This link connects you to the Microsoft TechNet Troubleshooting Web site. This Web site provides you with known causes and resolution steps for the current event. Microsoft updates this information as it receives new information.

·      Use the Details tab to view error codes and descriptions.

·      Use the Group Policy operational log.

2.   Use the Group Policy operational log.

·      Identify the activity ID of the instance of Group Policy processing you are troubleshooting.

·      Create a custom view of the operational log.

·      Divide the log into phases: pre-processing, processing, and post-processing.

·      In order, consolidate each starting event with its corresponding ending event. Investigate all warning and error events.

·      Isolate and troubleshoot the dependent component.

·      Use the Group Policy update command (GPUPDATE) to refresh Group Policy. Repeat these steps to determine if the warning or error still exists.

Important

Refreshing Group Policy changes the Activity ID in your custom view. When troubleshooting, be sure to update your custom view with the most current activity ID.

More troubleshooting information

Connectivity with domain controllers

The Group Policy service requires communication with a domain controller. The service discovers domain controllers using name resolution, namely DNS. The Group Policy service contains many warning and error event messages to help you identify connectivity issue with domain controllers. Use the Details tab of the event id, and review the error code and error description the event encountered. For example, the Group Policy service reports an error event with an event ID 1030 in the System log. This event occurs when the query for Group Policy object information fails, usually because it cannot contact the domain controller. However, the error code returned in the event detail is event ID 1355, which often times indicates a problem with name resolution and not the domain controller.

Also, the majority of Group Policy events contains the name of the domain controller the service is attempting to use. Read the event description for the name of the domain controller or check the Details tab. Look for the node named DCname. This helps you determine if the problem is related to this single domain controller.

Suspected delays associated with Group Policy

Group Policy applies to the computer shortly after it is turned on and to users shortly after they log on. It is common to suspect Group Policy as the cause of delayed user logons. Group Policy operational logging improves your ability to diagnose if Group Policy processing is causing your logon delays. Consider the following information if you suspect Group Policy processing is delaying your logons.

·      The Group Policy service, operating in synchronous processing mode, can cause delays with the logon process. This behavior is by design because synchronous processing does not allow the logon processes to complete until Group Policy processing is complete. Read the Details tab of start policy processing events (event IDs 4000–4007). The nodes IsBackgroundProcessing and IsAsyncProcessing can help you determine the processing mode. Also, success and warning network information events contain the application processing mode. On the Details tab for events with event IDs 5314 or 6314, read the PolicyApplicationMode node. You can use the value displayed to determine the mode of Group Policy application.

·      Each end event displays the elapsed time, in milliseconds, used by the described event. Additionally, you can see this same information in the Details tab of the event message. You can use the ProcessingTimeInMilliseconds node to determine how much time expired when processing each scenario and phase of Group Policy.

·      Certain policy settings take longer to apply than others. Typically, the Group Policy service applies these policy settings synchronously. For example, expect longer Group Policy processing times when deploying a software package to a computer or user. The Group Policy service waits for the software to finish installing before it transitions to the next scenario or phase of processing.

GPLogView

Often times, it is easier to read text files for troubleshooting instead of using the Event Viewer. In fact, exporting event logs into text files may be the only solution when troubleshooting computers in remote locations. GPLogView is a utility you can download and use to export Group Policy event data from the system and operational log into a text, html, or xml file. You can download GPLogView from the Microsoft Download Center (https://go.microsoft.com/fwlink/?LinkId=75004). The following examples show the syntax of commonly used options for GPLogView.

Example 1: Export all Group Policy events

You can use GPLogView to export all Group Policy–related events from the system log and the operational log.

gplogview -o gpevents.txt

Example 2: Export Group Policy events with a specific Activity ID

GPLogView filters Group Policy–related events by Activity ID, which is useful when troubleshooting a specific instance of Group Policy processing.

gplogview -a 8A7C7CE5-F7D0-4d32-8700-57C650A53839 -o gpevents.txt

Example 3: Monitor Mode

You can use GPLogView to capture Group Policy events in real time. GPLogView writes all Group Policy related events to the command window, as they occur. Press CTRL+C to exit monitor mode, or press Q and ENTER.

gplogview -m

Figure 3 GPLogView operating in monitor mode

Example 4: Using an external event log for input

By default, GPLogView reads the events logs on the current Windows Vista computer. However, you can change the GPLogView input source to an exported event log from another Windows Vista computer. This change gives you the ability to export multiple views of Group Policy processing that happened on another computer.

Note

The saved event log must come from a computer running Windows Vista. GPLogView does not work with saved event logs from earlier releases of Microsoft Windows.

gplogview-i savedevents.evtx -o gpevents.txt

You can view these and other commands supported by GPLogView by invoking command line Help.

gplogview -?

Appendix A: Group Policy system event messages

The following table lists Group Policy event messages that appear in the System log of the Event Viewer.

Appendix B: Group Policy operational event messages

The following tables identify the collections of Group Policy event messages (ordered by start event) that appear in the Group Policy operational event log.

Policy processing

Client-side extension processing

Trace events

Scripts processing

Individual script processing

Domain controller discovery

Domain controller information

Computer information

Security principal information

Loopback processing mode

Applied GPO list

Filtered GPO list

Network information

Next policy processing information

Successful or informational interaction

Computer startup wait information

Winlogon notification information

Service Control Manager notification information

Network bandwidth information

Service configuration information

NLA service warning

Client-side failure information

Policy processing

Computer start and end events

User logon start and end events

Computer network change start and end events

User network change start and end events

Computer manual refresh start and end events

User manual refresh start and end events

Computer periodic refresh start and end events

User periodic refresh start and end events

Client-side extension processing

Trace events

Scripts processing

Individual script processing

Domain controller discovery

Domain controller information

Computer information

Security principal information

Loopback processing mode

Applied GPO list

Filtered GPO list

Network information

Next policy processing information

Successful or informational interaction

Note

Event messages with event IDs 5320 and 5321 provide the same basic functionality. Event messages with event ID 5321 usually display more information in the event details.

Computer startup wait information

Winlogon notification information

Service Control Manager notification information

Network bandwidth information

Service configuration information

Network Location Awareness service warning

Client-side failure information

·      How to locate new troubleshooting information.

·      How to use the Event Viewer to filter specific Group Policy information.

·      How to read and interpret event data.

·      Correct methods for locating point of failure.

•What is Group Policy Preferences
•Benefits
•Preferences Vs Policy Settings
•System Requirements
•Client Side Extensions
•Features
•Common Options
•Targeting
•GPMC Support
•Enabling Logging
•Links

(Note: Attached is complete presentation in PDF format)

Group Policy Preferences.pdf