Select Page

It’s often the case in larger Group Policy environments, that over time you collect so many GPOs, that you no longer know what all of them do or what’s contained within them. If you’re in the process of trying to cleanup or streamline your GPOs, then finding EMPTY GPOs can be a useful exercise. But it’s not always that simple to find those empty GPOs. When it comes to Group Policy, there’s empty and then there’s “EMPTY”. As I’ve written before, whenever a change occurs to a GPO, that GPO’s version number is incremented. You can see the effect of this within GPMC, by viewing the Details tab on any GPO (see the figure below).

Viewing a GPO's Version Information

Viewing a GPO’s Version Information

As the figure shows, a GPO has both a per-user and per-computer version, depending upon whether the change was made to the computer or user side of the GPO. This version number continues to increment as any GPO changes are made. So, it stands to reason that any GPO who’s computer and user version numbers are zero (0), should be empty. That’s a pretty good first step for finding empty GPOs. I posted the following short PowerShell script a while back on the Microsoft TechNet Group Policy forum, to show how you could find GPOs who’s version numbers are 0, and I’m re-posting it here:

import-module grouppolicy
$gpos = get-gpo -All
foreach ($item in $gpos)
    if ($item.Computer.DSVersion -eq 0 -and $item.User.DSVersion -eq 0)
         write-host $item.DisplayName is empty

You’ll noticed that this script uses the Microsoft Group Policy PowerShell module built into GPMC on Windows 7 and above. Basically all it does is get a reference to all GPOs in the domain (get-gpo -all) then iterates through each one, checking to see if the per-computer and per-user AD versions are 0 (in this case, I’m ignoring the SYSVOL version because if the AD version is 0, it’s pretty much a guarantee that the SYSVOL version has to be as well). If both are zero, then I output the GPO’s name. Of course, you could do something more meaningful, like using the Remove-GPO cmdlet to delete the GPOs that are empty.

This is a good first step, but it’s not the whole story. It is possible to have a GPO that is empty of settings, who’s version number is not zero, but that no longer contains any GPO settings. Take the following example. You create a new GPO, edit it and set the following policy to “Enabled”: Computer Configuration\Policies\Administrative Templates\System\Logon\Always Wait for the Network at Computer Startup and Logon. By setting that policy, the computer side of the GPO has it’s version incremented to 1. Now, let’s say later you decide that you don’t really want that policy, so you go back into the GPO and set that same policy to “Not Configured”. Well that increment’s the GPO’s computer version to 2, but effectively there are no settings left in the GPO–it is empty. So, how do you find that? Well that is a much harder problem to solve, especially across all policy settings. You essentially need to query each policy area to determine if it contains any valid settings. Fortunately, this problem is solved pretty nicely using SDM Software’s GPO Exporter product. The Exporter contains 10 canned reports that return all kinds of useful information about your GPO deployments. One of those reports is the “Empty GPOs” report, which not only finds GPOs with version numbers of 0, but also scours the setting areas within a GPO to determine if any of them have been set. So the scenario I painted above can easily be handled. The figure below provides a sample of the report itself, which not only includes empty GPOs but also lists where those GPOs are linked.

Empty GPOs Report from GPO Exporter

Empty GPOs Report from GPO Exporter