While much is changing in Windows 8, the changes related to Group Policy are more modest. One of these modest changes is in the Resultant Set of Policy (RSoP) functionality, exposed through the Group Policy Results Wizard in GPMC. This wizard was always my first “go-to” tool when trying to troubleshoot GP Processing problems, and they’ve made it more useful in Windows 8.
The first thing you’ll notice is that the Summary tab on RSoP is completely different, as shown here:
RSOP Summary Tab in Windows 8 GPMC
The Summary tab is a troubleshoot assistant that gives you clue as to where problems may lie during the last GP processing cycle on the targeted machine. In the case of the screenshot above, it shows any errors during computer or users processing. And, if you click on the errors link (I have 9 errors for Computer processing) it displays a window that contains all of the GP operational event log errors from that remote system related to this failure!
GP Related Error Events
For more benign errors, such as what link speed was detected and that the OU where my computer and user reside have the block inheritance flag set, they mark them in yellow and link out to MS KB articles related to that topic. This is far more useful for quick troubleshooting than the sometimes obscure “Component Status” information given in previous versions of RSoP.
If you click on the Details tab within Group Policy Results, you’ll notice that they’ve combined what used to be in the Summary tab in previous versions with the Settings tab–providing component status along with the actual settings that should have been delivered to user and computer. However, you will note some interesting additions, as shown below:
The New RSOP Component Status
Notably, they now include the time taken for each Client Side Extension to run. As you’ll notice in the figure above, they also provide more detailed information when either Core processing (the part of the GP Processing cycle that reads AD to determine which GPOs apply) or Client Side Extension (CSE) processing fails. If you click one of the “Last Process Time” entries, a useful dialog pops up with additional information about the processing cycle, including whether it was background or foreground, whether loopback was enabled on the computer, and which DC was used to process policy (see Figure below)!
Additional GP Processing Details
Great stuff and very similar to what we return in our own PowerShell-based Group Policy Health Cmdlet. Finally, if you click a “View Log” Link within one of the component status items, the filtered view of the GP Operational Log on that system related to that CSE or Core processing event will appear, showing you all events related to the success or failure of the component. Double-cool!
You might wonder if all this new goodness is available against downlevel versions of Windows. The answer is, “kinda” :). For example, the Summary data that shows existing and possible problems works as expected on Win7 targets, for example. However, the individual CSE timings are not exposed in those downlevel OS versions because they simply aren’t logged before Windows 8. Not terrible but something to keep in mind.
You might also ask if GPResult.exe–the command line version of RSOP–includes these new features. Alas, it does not appear to. In testing I did with the version on Windows 8 Consumer Preview, GPResult seems to return the same data is always did. That’s too surprising since some of the data in the GPMC version is context-specific to a GUI. But still it would have been nice if some of the timings data would get returned through gpresult.exe. Since this is a beta, who knows how it may change before RTM.
Finally, you may also wonder if the PowerShell version of RSOP–Get-GPResultantSetOfPolicy— also supports these new data. Interestingly enough–it does seem to support most of the new data presented in the GUI, including timings for each CSE or Core Processing, as well as the event details associated with the GP Processing event. The Summary screen information does not appear to be captured anywhere in the output of the cmdlet, which I expected, as it’s probably analyzed within the GUI rather than collected as part of RSoP data. Nevertheless the cmdlet does seem to have the important pieces wired in, which is good for those of us who are command-line junkies.
Overall, I think Microsoft made some good improvements to RSoP in Windows 8, and I hope you find them useful once you start deploying this version of the OS!
Darren