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.
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.
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.
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 : http://www.w3.org/2001/XMLSchema
xsi : http://www.w3.org/2001/XMLSchema-instance
xmlns : http://www.microsoft.com/GroupPolicy/Settings
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.
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
—– — —-
http://www.microsoft.com/… SID Name
13:01 C:\> $xml.DocumentElement.SecurityDescriptor.Owner.Name
xmlns #text
—– —–
http://www.microsoft.com/GroupPolicy/Types 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 iammred.net/Charl… 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 scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
0 comments