Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to generate a Group Policy Resultant Set of Policy (RSoP) report.

Microsoft Scripting Guy, Ed Wilson, is here. I can tell you that spring is definitely heating up. Not necessarily temperature-wise, but in the world of Windows PowerShell. We have the MVP summit coming up in Redmond in which Microsoft MVPs from all over the world will converge on Redmond to make and to reinforce contacts with both the product groups and with themselves. This year, there is an awesome group of presentations about Windows PowerShell for the PowerShell MVPs.

Following that, there is the Windows PowerShell Summit in Redmond. The Scripting Wife and I will be there (I am making three presentations). This is a sold out international event, with Windows PowerShell people coming from all over the world to partake of three days of Windows PowerShell goodness. It will be awesome.

Then, there are the 2013 Scripting Games, and TechEd 2013 in New Orleans, not to mention countless community events cropping up all over the place (such as PowerShell Saturday). In the midst of that, I know I am doing several web casts as well. In fact, I just signed up to do one for O’Reilly in celebration of my new Microsoft Press Windows PowerShell 3.0 Step by Step book, and I know there are at least three remote Windows PowerShell user group meetings in the works. In fact, as I am writing this, I just got the meeting invite to appear on the PowerScripting Podcast on February 21, 2013, at 9:30 P.M. Eastern Standard Time. The PowerScripting Podcast is always fun. I especially enjoy the interaction in the chat room during the recording of the show. Dude, Dude, Dude: I think that sometimes people deliberately say stuff to make me start laughing.

Generate an XML RSoP report

As I mentioned yesterday, it is possible to generate an RSoP report for all of the Group Policy Objects by using the GPResult command. My biggest problem with the GPResult command is actually the syntax. The syntax is not consistent, and the online Help examples do not easily clarify the usage. But, that is not the case with Windows PowerShell. The great thing about Windows PowerShell is that the usage is consistent across cmdlets, and if I miss a required parameter, Windows PowerShell prompts for the missing parameter instead of erroring out, timing out, or going into la-la land.

Admin rights required

Keep in mind, that to run the Get-GPResultantSetOfPolicy cmdlet, you must start Windows PowerShell with elevated rights. Unfortunately, the generated error does not appear to have anything to do with admin rights. The error, appearing in a non-elevated Windows PowerShell console, is shown in the following image.

So, how did I figure out I needed to run Windows PowerShell with elevated rights? Well, I actually wrote a book on WMI, and I recognize HRESULT: 0x80041003 as an old-fashioned WMI access denied error. WMI did I say? Yes, indeed. RSoP data is actually stored in the WMI repository in the Root/RSoP namespace. Therefore, receiving a WMI error message is not completely unexpected.

When I open the Windows PowerShell console with admin rights, I import the module and call the command to produce an XML report. In yesterday’s article, I used the Get-GPOReport cmdlet to analyze a specific GPO.

The Get-GPOReport cmdlet returns the XML directly to the Windows PowerShell console if I do not supply a path. I used that technique to capture the XML in a variable and to process the XML as an XMLDocument. Unfortunately, this is not an option with the Get-GPResultantSetOfPolicy cmdlet, and therefore, it is required to specify the path as well. The following command prompts for the path.

Get-GPResultantSetOfPolicy -ReportType xml

The command and the prompt for the path as well as the results of the command once the path is supplied are shown here.

Parse the XML report

The cool thing is that after the XML report generates, there is no longer a need for the elevated Windows PowerShell console. I can open the XML report in a non-elevated Windows PowerShell console, convert the content to an XML document, and parse it as required. This technique is shown here.

One of the things I need to know is the link order of the GPOs. This is because, in general, GPOs applied last take precedence. So, for example, I could enable something in one GPO, disable it in the second GPO, and then enable it back again in another GPO. Depending on the order in which these GPOs are applied will determine, when we look at RSOP, if the policy is enabled or disabled. The following command parses the RSOP report and chooses the name of the GPO and the link order.

14:27 C:\> $xml.DocumentElement.ComputerResults.GPO | select name, @{LABEL=”LinkOrder

“;EXPRESSION={$_.link.linkorder}} | sort linkorder

 Name                                       LinkOrder

—-                                       ———

Local Group Policy                         1

EnablePSRemoting                           2

Enable WMI Relibility                      3

Default Domain Policy                      4

BackupOnLogOff                             5

Join me tomorrow when I will talk about exploring the Windows PowerShell RunSpace and the associated apartment mode.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy