Active Directory: Find and treat orphaned 'Group Policy Objects'

Introduction

Stale objects in Active Directory are one of the long time comrades of Active Directory administrators. You can nearly find them everywhere in Active Directory. User accounts that are never used for login, computer accounts that have been disjoined from the domain, groups with no ACL permissions and nobody inside them, OUs that are empty, dead SPNs and so on. These objects are all considered as stale ones. They have no use to anybody, but they are on your database and disk. Although these sort of objects are not considered the good beings in your Active Directory, it is not possible to have the same approach for all of them. It is simply because not all the objects should be treated the same way. Take user accounts as an example. If there are hundreds of stale user accounts in Active Directory, is it possible for us to simply remove all of them in a blink of an eye? Technically yes, but it is not practically recommended. However, other objects can be simply removed after verifying their contents. In today’s article, we will cover stale group policy objects or simply ‘Orphaned GPOs’ and how do we can treat them.

Orphaned GPOs

GPOs are objects, just like any other sort of objects in Active Directory.  Administrators will create GPOs and remove them depending on the needs of the organization. In a normal condition, once a GPO is deleted from GPMC, the corresponding folder will be also deleted from SYSVOL folder. So there is no need to check the SYSVOL folder to verify if you have folders associated to dead GPOs. However, in rare circumstances, the folder associated to a deleted GPO, is not deleted automatically. In that case, we will have a folder, which is associated to a GPO, which has been deleted before. These folders however may do no harm to our Active Directory, but also they are not useful. In this case it is better to clean up these GPO and their associated folders from your Active Directory.
This script however is so simple to understand. It tries to get all the GPOs from the PDC Emulator of our AD domain and compare the result with the real folders which are associated to GPOs in SYSVOL directory. For every GPO, the script will try to find a folder in SYSVOL, if it is found, that GPO is a good one, otherwise, it can be considered as an orphaned GPO. However, after running the script, you will have a rapid report of the GPOs in domain and their folder. Therefore, by running the script, we will have a fast report of GPO and their folder. We will discuss that in the next section.

Using the script

The script that I wrote for this manner can be found by following to this link. Once it is downloaded, you need to load it into the PowerShell.  Here are the steps that needs to be followed in order to have the report of the GPOs:

Download the script and place that in a folder where you can find easily.

Open the script in PowerShell ISE.

Once you run the script, you will realize that there will be no output. It is because that this script is written as a function. Therefore, we need to call the function again to start the script.

You will notice that once you are typing the name of the function, it is automatically suggested as ‘Get-GPOMappings’. Go ahead select that and hit ‘Enter’.

When you run the script, it will query the PDC Emulator of the domain and ask about the number of GPOs and then at the same time, it will match each GPO to a folder in SYSVOL structure. Right after the message box is presented, we will see a table with all the information you need. In this case there will be three different category that we will face:

Acceptable situation: Blue icon

If your Active Directory environment is in good state, you will be presented with a message box, which indicates that there is no inconsistency problems between GPMC and SYSVOL. This message box also indicates the number of GPOs and SYSVOL folders on PDC Emulator. This message box give you a quick glance of what is going on and how many GPOs and SYSVOL folders do you have. Take a look below:

Once we click ‘Ok’, another window will pop up which gives a more detailed report. This window will list the GPOs in domain and their GUID. In addition, there will be a third column that is called ‘Status’. By looking at this column, we can see the total status of each GPO. Once it indicates ‘OK!’ it means, that GPO in GPMC console has been associated to its corresponding SYSVOL folder, so there is no issue in regards with that one. 

However, this is not the only category as we said. There are two more categories to discuss.

Warning situation: Yellow icon

The second category will be ‘Warning’ situation. This situation can occurs where the number of GPOs in GPMC is lower than the total number of SYSVOL folders. As we discussed, this issue can be quite rare but it can happens in all sort of Active Directory environment. I was unable to recreate this issue in my lab, but since it was important to demonstrate this problem, I ran the script against my own production environment to find the results. However because I did not want to represent the name of the AD domain, the sensitive information are marked out. However the results was not sensitive and as you can see, there are 38 folders in SYSVOL structure, but there are only a total of 31 GPOs in our domain which means that we have 7 useless folders in our SYSVOL structure. These folders I tend to call them ‘Phantom’ or ‘Orphaned’ folders. Take a look at the below report:

Once we click on ‘Ok’, we will see the detailed report of the GPOs and their GUID and the status column. As we can see in the image below, there are 7 folders which is marked as ‘Phantom’. These folders are not associated with a GPO, so it is better to go ahead and remove them after verifying that they do not contain any valuable information.

Bad situation: Red icon

The third situation is quire worst! This can arrive when total number of SYSVOL folders are less than the number of GPOs. This can be super rare scenario but because I faced it one time in my entire life, it is worth mentioning. This situation can only occurs if someone has accidentally deleted some of the folders in SYSVOL folder and since there is no relation between SYSVOL as source and GPMC as target, the GPOs will be kept in place, however they are pointing to nowhere! Take a look at image below:

As we can see, the images above will also give us the GUID of the GPOs that are missing from the domain, so if you have a backup from them, you should restore them properly. If you do not know actually what those GPO are all about, you can grab those GUIDs and then use Get-GPO to find the name and commit the restoration process.

Just as a side note, once you try to click on a GPO in GPMC console where the associated folder is not present, you will face an error indicating that there is no file and setting for that GPO and the settings for those GPO will be empty:

Conclusion

In this article, we learned how to find orphaned group policy objects in our Active Directory environment. Orphaned GPOs are objects that are deleted from GMPC console but for different reasons, their corresponding folder is not removed. So in this case the folder remains in SYSVOL folder, however there is no GPO associated to it. The script which was mentioned today, use a simple way to  query group policy objects from PDC emulator and then compare them with the actual folders that resides in SYSVOL folder. However, if you are worried about using this script in your environment, there is nothing to worry about, because all it does is to inform us about the status of group policy objects.