Not surprisingly, there are a huge number of PowerShell cmdlets that can be used to manage Group Policy. There are cmdlets for creating Group Policy objects, modifying Group Policy settings, checking existing settings, and the list goes on and on. If I am to be perfectly frank, however, it is usually more efficient to use the GUI based Group Policy Object Editor when you need to create and modify Group Policy settings. Even though PowerShell can be used, the required commands tend to be long and convoluted. However, this does not mean that PowerShell does not have its place when it comes to keeping your organization secure. Even though it probably doesn’t make a lot of sense to use PowerShell as a tool for creating and editing Group Policy settings, PowerShell can be used as a Group Policy reporting tool. In this article, I want to show you a few different techniques that you can use.
Creating a Group Policy report
Windows PowerShell has a built-in cmdlet called Get-GPOReport that you can use to report on a specific Group Policy object. When you use this cmdlet, there are two (sometimes three) pieces of information that you will need to supply.
The first of these pieces of information is the name of the Group Policy object that you want to report on. For example, if you want to report on the Default Domain Policy, then you would need to include the phrase ‘Default Domain Policy’ immediately after the Get-GPOReport cmdlet.
The next piece of information that you will have to provide is the type of report that you want to create. PowerShell gives you two report type options; HTML and XML. The information that is included in the report will vary a bit depending on which type of report you choose to create. I will show you examples of both report types later on.
Finally, you may sometimes need to specify the path at which you want to create the report. The path is only necessary if you want to write the report to a file.
Creating an HTML report
So with that said, let’s take a look at how to create an HTML report. As previously noted, you will need to include the name of the Group Policy Object, the report type, and the path. Here is what the command looks like.
Get-GPOReport ‘Default Domain Policy’ -ReportType HTML -Path C:\Data\GPReport.html
The screen capture below shows what it looks like when you run this command.
The next screen capture shows an excerpt from the report itself.
As you can see in the figure, the report contains much of the same information that you can access through the Group Policy Object Editor. In fact, the report almost appears as though it was generated by the Group Policy Object Editor.
OK, so that’s how you go about creating an HTML-based Group Policy object report, but what about an XML-based report? Well, as you have probably already guessed, the process is nearly identical to what you have already seen. All we have to do is to change the report type to XML, and change the filename to something with an XML extension. Here is an example of such a command:
Get-GPOReport ‘Default Domain Policy’ -ReportType XML -Path C:\Data\GPReport.xml
The screen capture below shows what it looks like when you create an XML based report, and the screen capture beneath that shows an excerpt from the actual report.
Earlier, I mentioned that it isn’t always necessary to supply a path and filename, and yet I supplied a path and filename in both of my previous examples. That being the case, you might be wondering what types of situations warrant omitting the path and filename.
Writing report data to a file is not always necessary if your goal is to parse the data within PowerShell. In those types of situations, you might instead choose to write the report to a variable rather than writing it to a file.
In PowerShell, variables are usually defined by typing a dollar sign followed by a name and an equal sign ($MyReport=). However, if the variable is going to store XML data, then you can include the word XML in brackets just before the variable definition. This tells PowerShell to treat the variable contents as XML data rather than just plain text. So here is an example of how you would write a Group Policy object report to a variable in PowerShell:
[XML]$MyReport = Get-GPOReport ‘Default Domain Policy’ -ReportType XML
Once you have written the report to a variable, you can use PowerShell to display information from the report. Typing $MyReport.GPO causes PowerShell to list several categories of information such as Computer and User. You can see what this looks like in the screenshot below.
Although the information shown in the screen capture above may not be all that helpful, you can append a period to the command, followed by any one of these category names. This allows you to drill down into the category to get more detailed information. If you wanted to check out the security descriptor for example, you could type this command:
$MyReport.GPO.SecurityDescriptor
If you want to take things a step further and view the security descriptor’s permissions, you could do so with this command:
$MyReport.GPO.SecurityDescriptor.Permissions
Why use PowerShell?
As handy as it is to be able to export all of the various Group Policy object reporting information through PowerShell, most (if not all) of this information is also available through the GUI. One reason why you might wish to use PowerShell, however, is that PowerShell makes it possible to report on a variety of Group Policy objects. You could then perform comparative analytics to see if any differences exist between the objects.
Featured image: Shutterstock
