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.
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.
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:
If you want to take things a step further and view the security descriptor’s permissions, you could do so with this command:
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
Deep fakes are a catastrophe waiting to happen. Facebook’s attempt to create a tool that differentiates between real and fake…
Microsoft Intune is getting a bunch of new updates that will streamline the administration experience for users of the popular…
As businesses evolve into a SaaS/IaaS model for accessing applications, new network technology is crucial. SD-WAN is just such a…
What you don’t know about Exchange and your network can come back to bite you. Monitoring Exchange is one way…
Warnings are nice, except when they are annoying and unnecessary. Here’s a tip to show you how to remove warning…
Having a Group Policy Central Store in Active Directory made life easier for administrators. But does it still work in…