Client-Side Troubleshooting | Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

One of the most important skills to master is the ability to determine what's going on at the client. By and large, the Group Policy Results tool, which you run from the GPMC, should give you what you need. However, occasionally, only trotting out to the client can truly determine what is happening on your client systems.

You could be roaming the halls, just trying to get the last Krispy Kreme glazed doughnut from the break room, when someone snags you and plops you in their seat for a little impromptu troubleshooting session. They want you to figure out why Group Policy isn't the same today as it was yesterday or why they're suddenly getting new or different settings.

This section will describe the various means for determining the RSoP (Resultant Set of Policy) while sitting at a client or using some remote-control mechanism such as Microsoft SMS (Systems Management Server), VNC (Virtual Networking Client), or even, in the case of Windows XP, Remote Desktop. As you saw in the last chapter, the GPMC has two tools to help you tap into this data: Group Policy Results and Group Policy Modeling. However, there are other client-side tools at your disposal. Additionally, I'll describe how to leverage a new function in Windows XP and Windows 2003 to determine a target user 's and computer's RSoP remotely!

RSoP for Windows 2000

If you're sitting at a Windows 2000 machine, there aren't a lot of options to help you determine the RSoP. However, one particular tool can really bring home the bacon GPResult.exe . This is one of the most important tools for Group Policy troubleshooting. When the going gets tough and I can't figure out what's going on, I look to GPResult to help tell me the score. You'll find GPResult in the Windows 2000 Server Resource Kit, but it is also built into the Windows 2000 Service Pack 4 and is in c:\Windows\system32.

The main goal of GPResult is to expose which GPOs are applied from where and the settings. The Achilles heel of GPResult on Windows 2000 is that it must be run on the client experiencing the problem.

Warning

GPResult appears only on Windows 2000 installations on which Service Pack 4 was installed after the machine was installed. GPResult will not appear if a slip-streamed Windows 2000 with SP4 was used to create a machine fresh. This is a bug in the definition of the service pack and is subject to change in future service packs . You can just expand GPResu1t.exe from the service pack files and plunk it in the c:\windows\system32 folder without any penalty.

Tip	If you can set up Telnet server on a client system, you can telnet to the client and then run GPResult as if you were at the client. This could save you a hike or two. However, you'll need to log on with the credentials of the user (not of the local administrator) to get the same results.

GPResult has three modesnormal, verbose, and super-verboseand can expose the user settings, the computer settings, or, by default, both. If you don't have Windows 2000 SP4 loaded, you can copy GPResult onto a floppy (from an SP4 installation or from the resource kit) or run it over the network.

Although GPResult is powerful, it has a limited set of options:

/v displays verbose output. In the next section, you'll see an example of verbose output.
/s displays super-verbose output. This equates to the new /z option in GPResult for Windows XP. Again, I'll discuss how you might use this in the next section.
/c limits the output to the computer-side policy settings.
/u limits the output to the user-side policy settings.

You can mix and match the options. For instance, to display verbose output for the computer section, you can run GPResult /v /c .

We'll explore GPResult in depth in the next section, but, due to space concerns, I'll describe it from a Windows XP perspective.

Note	The Windows 2000 GPResult isn't nearly as feature rich as its Windows XP or Windows 2003 counterpart , but, as you'll soon see, there is still life in the Windows 2000 version.

RSoP for Windows 2003 and Windows XP

Windows XP and Windows 2003 greatly expand our capacity to determine the RSoP of client machines and users on those machines. In this section, we'll explore several options. The first stop is a grown-up GPResult to help us get to the bottom of what's happening on our client machines.

GPResult for Windows 2003 and Windows XP

GPResult for Windows 2003 and Windows XP is more advanced than its Windows 2000 counterpart. Indeed, you can run GPResult when you're sitting at a user's desktop or at your own desktop, or you can run it remotely and pretend to be that user. If you're running it while sitting at someone's desktop, you'll likely use the following options:

/v is for verbose mode. It presents the most meaningful information.
/z is for zuper, er, super-verbose mode. Based on the types of policy settings that affect the user or computer, it displays way more information than you'll likely ever want to see, based on the types of policy settings that affect the user or computer.
/scope:user limits the output to the user-side policy settings, and /scope:computer limits the output to the computer-side policy settings.

You can mix and match the options. For instance, to display verbose output for the user section, you can run GPResult /v /scope:user .

Here's the result of running GPResult with no arguments while logged on to the XPProl workstation (which is in the Human Resources Computers OU) as Frank Rizzo (who is in the Human Resources Users OU). I have slightly modified the output for formatting purposes. Note that some of the display might be somewhat different from yours.

Warning

You must have at least Windows XP SP1 to properly use GPResult . Without at least SP1, trying to run GPResult twice will fail to function. For more information, see the Microsoft Knowledge Base article 322852. Microsoft decided not to honor me by putting my name in this bug I found to enhance their Knowledge Base database. Oh well. <grin>

 Microsoft(R)WindowsR) XP Operating System Group Policy Result tool v2.0 Copyright(C) Microsoft Corp. 1981-2001 Created On 7/26/2003 at 10:48:23 AM RSoP results for CORP\frizzo on XPPR01 :  Logging Mode ----------------------------------------------------- OS Type:          Microsoft Windows XP Professional OS Configuration: Member Workstation OS Version:       5.1.2600 Domain Name:      CORP Domain Type:      Windows 2000 Site Name:        Default-First-Site-Name Roaming Profile: Local Profile:    C:\Documents and Settings\frizzo Connected over a slow link?: No COMPUTER SETTINGS -----------------     CN=XPPR01,OU=Human Resources Computers,DC=corp,DC=com     Last time Group Policy was applied: 7/26/2003 at 10:45:00 AM     Group Policy was applied from:      WINDC01.corp.com     Group Policy slow link threshold:   500 kbps     Applied Group Policy Objects     ----------------------------         Prohibit new Tasks in Task Scheduler             Filtering: Denied (Security) The following GPOs were not applied because they were filtered out     --------------------------------------------------         Hide Desktop Tab             Filtering: Not Applied (Empty)         Hide Screen Saver Tab             Filtering: Not Applied (Empty)         Local Group Policy             Filtering: Not Applied (Empty)         Default Domain Policy             Filtering: Not Applied (Unknown Reason)     The computer is a part of the following security groups:     --------------------------------------------------         BUILTIN\Administrators         Everyone         BUILTIN\Users         XPPR01S         HR-Admin-Computers         Domain Computers         NT AUTHORITY\NETWORK         NT AUTHORITY\Authenticated Users USER SETTINGS -------------     CN=Frank Rizzo,OU=Human Resources Users,DC=corp,DC=com     Last time Group Policy was applied: 7/26/2003 at 10:47:55 AM     Group Policy was applied from:      WINDC01.corp.com     Group Policy slow link threshold:   500 kbps     Applied Group Policy Objects     ----------------------------         Hide Desktop Tab         Local Group Policy     The following GPOs were not applied because they were filtered out     --------------------------------------------------         Hide Settings Tab / Restore Screen Saver Tab             Filtering:  Denied (Security)         Hide Screen Saver Tab             Filtering:  Not Applied (Unknown Reason)         Default Domain Policy             Filtering:  Not Applied (Unknown Reason)     The user is a part of the following security groups:     ---------------------------------------------------         omain Users         Everyone         Remote Desktop Users         BUILTIN\Users         Group Policy Creator Owners         HR-OU-Admins         LOCAL         REMOTE INTERACTIVE LOGON         NT AUTHORITY\INTERACTIVE         NT AUTHORITY\Authenticated Users

Tip	You can redirect the output to a text file with GPResult > filename.txt.

You can glean all sorts of juicy tidbits from GPResult. Here are the key areas to inspect when troubleshooting client RSoP:

Find the "Applied Group Policy Objects" entries for both the user and computer. Remember that Group Policy is applied from the local computer first, then the site level, then the domain level, and then each nested OU. If a setting is unexpected on the client, simply use the provided information along with the Group Policy Object Editor to start tracking the errant GPO.
Use the "Last time Group Policy was applied:" entry to check to see the last time the GPO was appliedvia either initial or background refresh processing. Use GPUpdate to refresh this, and then ensure that the value is updated when you re-run GPResult .
Use the spelled-out distinguished name of the computer and user objects (for example, CN=Frank Rizzo, OU=Human Resources Users, DC=corp, and DC=com) to verify that the user and computer objects are located where you think they should be in Active Directory. If they are not, verify the location of the user and computer accounts using Active Directory Users And Computers. You might need to reboot this client machine if the location in Active Directory doesn't check out.
Use "The user is a part of the following security groups" and "The computer is a part of the following security groups" sections to verify that the user or computer is in the groups you expect. Perhaps your user or computer object is inside a group that is denied access to either the "Read" or "Apply Group Policy" permissions on the GPO you were expecting.
Find the "Connected over a slow link?" entry for the log and the "Group Policy slow link threshold" entries for both the user and computer. Remember that the various areas of Group Policy are processed differently when coming over slow links. (See Chapters 3 and 10.)
Find the "The following GPOs were not applied because they were filtered out" section for both the user and the computer section. If you have GPOs listed here, the user or computer was, in fact, in the site, domain, or OU that the GPO was supposed to apply to. However, the GPOs listed here have not applied this user or computer for a variety of reasons. GPResult can tell you why this has happened . Here are some of the common reasons:
- Denied (Security) The user or computer doesn't have "Read" and "Apply Group Policy" rights to process the GPO. For instance, in the previous example, the "Prohibit new Tasks in Task Scheduler" doesn't apply to XPProl because we explicitly denied the XPProl computer object the ability to process the "Apply Group Policy" attribute.
- Not Applied (Empty) This GPO doesn't have any policy settings set in the user or computer half. For instance, in the previous example, the "Hide Desktop Tab" GPO doesn't have any computer-side policy settings. Hence, this GPO doesn't apply to Frank's computer object.
- Not Applied (Unknown Reason) Usually Block Inheritance has been used (though other, truly "unknown reasons" could also be valid). In the previous example, the "Hide Screen Saver Tab," which is set at the site level, won't apply to Frank because we've blocked inheritance at the Human Resources OU.

Note	The account policies of the Default Domain GPO cannot be blocked, regardless of the GPResult output.

Three Different GPResults Three Different Outputs!

If you want to take GPResult to the next level, use it with the /v switch. You can then see which Registry settings are specifically being altered by the GPOs. This could be useful if you want to manually dive into the Registry and perform the same punch the policy setting is doing on a machine that isn't connected to Active Directory and see if you get the same results.

However, running GPResult /v on Windows 2000, Windows XP, and Windows 2003 returns totally different results. For the sake of brevity, here are three comparison snippets to illustrate some additional information possible with GPResult /v . This output has been taken out to show you some specific details and also formatted slightly for readability.

GPResult /v for Windows XP SP1 is the least useful. When you run it, you'll get output similar to the following.

 Administrative Templates GPO: Hide Desktop Tab Setting: Software\Microsoft\Windows\CurrentVersion\Policies\System State:   Enabled

This output merely tells you that the GPO "Hide Desktop Tab" manipulates a Registry key somewhere in the path specified in the Setting field.

When you run the command on a Windows 2003 computer, you get the following:

 Administrative Templates ------------------------ GPO: Hide Desktop Tab KeyName: Software\Microsoft\Windows\CurrentVersion\Policies\ System\NoDispBackgroundPage Value: 1, 0, 0, 0 State: Enabled

This output is even more useful, because it shows you that it's the " NoDispBackroundPage " Registry entry with the value of 1 in the Registry that is performing the function. I'm guessing the difference in output between Windows XP and Windows 2003 is just a GPRESULT bug, but as of Windows XP+SP1 (and the beta of SP2), the output displayed is, in fact, different.

However, the most useful GPResult /v output comes from the GPResult in the Windows 2000 Resource Kit! (Yes! Windows 2000!)

 The user received "Registry" settings from these GPOs:     Hide Desktop Tab         Revision Number:   3         Unique Name:   {7AF6DlA4-4CAB-44FF-8003-67ED8241FFAB}         Domain Name:   corp.com         Linked to:    Domain (DC=corp,DC=com)     The following settings were applied from: Hide Desktop Tab         KeyName:   Software\Microsoft\Windows\CurrentVersion\Policies\System         ValueName:   NoDispBackgroundPage         ValueType:   REG_WORD         Value:   0x00000001

The Windows 2000 GPResult /v shows you the ValueName (like the Windows 2003 version), but also shows you the ValueType (REG_DWORD). Additionally, it can also easily show you the association between the GPO friendly namesay, "Hide Appearance Tab"and the GUID-in my case, " 7AF6D1A4-4CAB-44FF-8003-67ED8241FFAB ." You might need this information later with other tools such as the Event Viewer, which may or may not use the friendly name.

So my advice? The GPResult built into Windows XP and Windows 2003 is much better for basic troubleshooting. Its output describing why specific GPOs are not being processed is excellent . However, keep a copy of the Windows 2000 version of GPResult handy. It runs just fine on Windows XP and Windows 2003 machines, and, because of its additional functions in displaying both the Registry and the GPO GUID, you can get a lot closer to knowing what has been changed.

Remotely Calculating a Client's RSoP Using Windows XP or Windows 2003 GPResult

The Windows 2000 version of GPResult doesn't work the way the Windows XP and Windows 2003 version does. The Windows XP and Windows 2003 version of GPResult has a secret weapon tucked up its sleeve. You can almost hear it say, "Are you talkin' to me?"

Its weapon is that it can tap into the WMI provider built in to both Windows XP and Windows 2003. GPResult is like the GPMC's Group Policy Results Wizard. That is, it can be run from any Windows XP or Windows 2003 machine, and, provided the target machine is turned on, the system can "pretend" to be any particular user who has ever logged on locally. It's then a simple matter of displaying the results. You simply run GPresult , point it to a system, and provide the name of the user to pretend to log on with.

This magic only works on Windows XP and Windows 2003 as both source computers and target computers. Windows 2000 computers don't have a tap into this WMI magic; so they can't play.

There are two more important cautions here (which I talked about in the Group Policy Results section, but they bear repeating). That is, this magic only works if the target user has ever logged on to the target machine. They only need to have logged on just once, and they don't even need to be logged on while you run the test. But if the target user has never logged on to the target machine, remotely calculating GPResult will fail. Additionally, remotely trying to get a Windows XP / Service Pack 2 computer's RSoP via GPResult will fail if the Windows Firewall is enabled. As described in Chapter 2, either turn off the Windows Firewall or enable the new Windows XP / Service Pack 2 policy setting titled Windows Firewall:Allow Remote Administration Exception, which can be located in Computer Configuration ˜ Administrative Templates ˜ Network ˜ Network Connections ˜ Windows Firewall ˜ Domain Profile.

With that in mind, here are your additional Windows XP and Windows 2003 GPResult options:

/s <target system name or IP address> points to the target system.
/user <optional domain\username> pretends to log on as the target user.

You can combine any of the aforementioned GPResult switches as well. If you log on to WINDC01 and want to see only the user-side policy settings when Frank Rizzo logs on to XPProl, type the following:

 gpresult /user frizzo /s xpprol /scope:user

Again, this command only succeeds if Frank has ever logged on to XPPro1 (which he has).

GPResult is much better at telling you why a GPO is applying rather than what specific policy settings are contained with a GPO. For instance, notice that at no time did GPResult tell us what policy settings were contained in the local GPO. And, even when we performed a GPResult /v , we only found out the Registry keys that were modifiednot the proper name of the specific policy setting that is doing the work. For these tasks, we'll need to use the GPMC (as seen in Chapter 3) or the Windows XP GUI RSoP (described next).

Windows XP's Group Policy "Help and Support System" RSoP Tool

If wading through a mountain of text-based GPResult output isn't your cup of tea, I've got some good news for you: you can view RSoP information graphically in both Windows XP and Windows 2003. If a user has problems, you cannot find a Windows 2003 or Windows XP machine to log on to (to remotely perform the tests), and you still want the user to tell you what their RSoP tool is, this tool is handy. You can get what you need over the phone and have the user just click-click-click to get you the results you want to hear (instead of asking them to dive into the scary world of command-line tools).

To launch the Windows XP Group Policy "Help and Support System" RSoP tool, otherwise just known as the "GUI RSoP tool," choose Start ˜ Help and Support to open Help and Support Center. Then click "Get support, or find information in Windows XP newsgroups." Next, click "Advanced System Information." Finally, select "View Group Policy settings applied." Figure 4.19 shows the results.

Figure 4.19: The RSoPtool in the Help and Support Center is useful when you're asking users to help you help them.

You'll see the many sections of user and computer Group Policy in the GUI RSoP tool. On Windows XP, this tool is, in some ways, superior to GPResult because you can see which Registry keys are being modified by Active Directory GPOs and also what's going on inside the Local GPO. Although this tool does provide the names of the GPOs that apply, it doesn't address "why" GPOs are or are not applying, as GPResult does. So, a yin and yang approach with both the GPResult and the GUI RSoP tools may be needed to get the whole story.

Warning

At the bottom of the GUI RSoP, you'll see an option to save the report to an HTML file. The default location is c:\, but nonadministrators cannot save files here. If users save to an HTML file, be sure they have permission for the folder.

The RSoP MMC Snap-In

Yet another tool can help you determine the RSoP of the client. Technically, this tool is named the RSoP MMC Snap-in. This tool has, more or less, been rendered obsolete by the reports you get from the GPMC. I'm how to use the tool here only for reference and completeness.

RSoP Generation from Help and Support Center

In Figure 4.19, you can see the "Save this report to an .htm file" option. Just below that (not shown) is the "Run the Resultant Set of Policy tool" option. This option launches this tool (again, technically, the RSoP MMC Snap-in), which will show you only the policy settings that are set and which GPOs they are coming from: local, site, domain, or OU, as shown in Figure 4.20.

Figure 4.20: The RSoP MMC Snap-in tool shows you only the policy settings that are configured.

The bad news is that you still need to drill down a bit into each folder to get to the end. The good news is that the list is prefiltered and will only show you the policy setting name, the state, and the GPO from whence it came.

RSoP Generation from the True RSoP MMC Snap-In

Instead of launching the RSoP MMC Snap-in tool from within the Help and Support Center, you can do just what its name implies. That is, run it directly as its own MMC snap in. To do so, follow these steps:

Choose Start ˜ Run to open the Run dialog box. In the Open box, enter MMC and press Enter to open the MMC.
Choose File ˜ Add/Remove Snap-in.
Click Add to see the list of snap-ins and select "Resultant Set of Policy" to start the Resultant Set of Policy Wizard.
Click Next to open the Mode Selection screen. If you're running Windows XP, only Logging is available. If you're running Windows 2003, Planning mode is also listed.
You'll then specify to perform the calculation on this computer or another Windows XP or Windows 2003 computer.
Next, you'll select the user; you can pretend to log on as any user who has logged on to the machine at least one time before. Note that you won't be able to "pretend" to log on as just anyone unless you're really logged in as someone with Administrator rights on the target machine.
Once the parameters are plugged in, you can press Next as seen in Figure 4.21 below.

Figure 4.21: The RSoP MMC Snap-in tool calculates the reaction between the specified user and computer.

The RSoP MMC Snap-in tool does have one goodie that its bigger brother, the GPMC, does not have. That is, besides showing the "winning" GPO, it also lets you know the "losing" GPOs. After you complete the wizard and close the open screens, the RSoP you just calculated will appear in its own window, similar to what is seen in Figure 4.20.