Use PowerShell to Generate and Parse a Group Policy Object Report

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to generate and parse a Group Policy Object report.

Microsoft Scripting Guy, Ed Wilson, is here. So, I am working on my MCSE: Server Infrastructure certification and having passed the Installing and Configuring Windows Server 2012 exam (70-410), I am now studying for the Administering Windows Server 2012 exam (70-411). According to the 70-411 exam guidelines, 15 to 20 percent of the exam is related to Configuring and Managing Group Policy.

Note   I have been taking Microsoft Certification exams since my first MCSE (on Windows NT 3.51). The one big tip I can give you is to adhere to the Skills Being Measured (study guide). If you see something on the list that you do not understand, look it up on TechNet, search the online Help, and actually perform the task. Luckily, now with Hyper-V, this is much easier. You can learn a lot by clicking through a wizard—much more than just looking at screenshots.

Anyway, I am spending a lot of time here lately playing around with Group Policy.

Generating a RSOP report

Nearly everyone who has spent any time as a network administrator, or even a Help desk person, has run into situations that demand analyzing Resultant Set of Policy (RSoP). The dreaded situation arises where it seems settings are not being applied that should be applied or settings are applied that should not be applied. The standard tool for troubleshooting this is the GPRESULT command. The syntax of this command always seems a bit confusing, but eventually, I come up with a command that works. This command is shown here.

gpresult /r

Outputting the RSoP report to the Windows PowerShell console does not make for a great troubleshooting experience—everything goes to the console, and this results in a lot of scrolling up and down. This is shown here.

Image of command output

One thing that can be done to improve this experience is to output the report to Out-GridView. This is shown here.

gpresult /r | Out-GridView

Even though the output is just plain text, it does not preclude using the Out-GridView cmdlet to parse the results.

By typing in the filter box on top of the GridView pane, I can filter the text that appears in the bottom. This is a good way to bring some measure of control to the output.

Image of filter box UI

XML is a better way to filter the output

By using the Windows PowerShell cmdlet Get-GPOReport (from the GroupPolicy module from the RSAT tools), I can gain a bit of flexibility as I dive into a specific Group Policy Object. The Get-GPOReport cmdlet will produce two different types of reports—HTML or XML. The cmdlet also has a –path parameter that I use to specify the path for storing the report. Therefore, to produce a report about the BackupOnLogOff GPO that exists in my domain, I use the following syntax:

Get-GPOReport -Name backuponlogoff -ReportType html -Path c:\fso\backup.html

I can open the produced report in Internet Explorer. The report is shown here.

Image of report

Of course, generating a report to an HTML file does not help me too much—in fact, it is not much different than writing the output to the Out-GridView cmdlet.

However, if I do not specify a path, the output returns to the console. Now, obviously, I do not want to write HTML to the Windows PowerShell console; in fact, I do not even want to write XML to the Windows PowerShell console, but what if I store the results in a variable and cast the variable to an XML document? Hmm … might that work?

Well, as a matter of a fact, it does. Here is the command I use to get a GPO report in XML and store it in a variable as an XMLDocument object.

[xml]$xml = Get-GPOReport -Name backuponlogoff -ReportType xml

Note   Keep in mind when exploring the XML document that tab expansion works, and so there is actually very little typing required.

The main property I like to begin with is the DocumentElement. From this property, I see several objects I can explore. This is shown here.

13:01 C:\> $xml.DocumentElement

xsd                 :

xsi                 :

xmlns               :

Identifier          : Identifier

Name                : BackupOnLogOff

IncludeComments     : true

CreatedTime         : 2012-02-22T19:19:53

ModifiedTime        : 2012-02-22T19:19:53

ReadTime            : 2013-02-05T18:01:33.4004324Z

SecurityDescriptor  : SecurityDescriptor

FilterDataAvailable : true

Computer            : Computer

User                : User

LinksTo             : LinksTo

To see if the GPO is enabled on the Computer or on the User portion, I examine the enabled property from those objects, as shown here.

13:01 C:\> $xml.DocumentElement.Computer

VersionDirectory             VersionSysvol               Enabled

—————-             ————-               ——-

0                            0                           true

The following image shows the commands and the associated output used to obtain the XML report and to parse it.

Image of command output

If I want to see the owner, I navigate through the SecurityDescriptor object, as shown here.

13:01 C:\> $xml.DocumentElement.SecurityDescriptor.Owner

xmlns                        SID                         Name

—–                        —                         —-… SID                         Name


13:01 C:\> $xml.DocumentElement.SecurityDescriptor.Owner.Name

xmlns                                      #text

—–                                      —– IAMMRED\Domain Admins

I can also easily see where the GPO links by examining the LinksTo object, as shown here.

13:02 C:\> $xml.DocumentElement.LinksTo

SOMName               SOMPath              Enabled              NoOverride

——-               ——-              ——-              ———-

Charlotte   … true                 false

Well, that is about it for looking at a GPO report in XML. Join me tomorrow when I will talk about more cool Group Policy stuff.

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

Ed Wilson, Microsoft Scripting Guy 


Discussion is closed.

Feedback usabilla icon