Active Directory: Project Plan to Clean and Organize Group Policies

A healthy Group Policy deployment is an essential part of any well run Active Directory infrastructure. In a lot of organizations, Group Policy Objects come to be over several years, administrators and acquisitions. As such, over time the rationale for creating those policies and the methodology applied varies greatly from policy to policy.

By adopting standards for GPO creation and applying them consistently going forward, Group Policies should become much easier to administrate leading to a healthier and more secure network infrastructure.
After recently being tasked to examine our organization’s current Group Policies in place, I developed the following logical plan to reduce the number of GPO’s, apply standards and, where applicable, consolidation.

This plan that I have developed covers five phases:

Phase 1: Removal of Empty Organizational Units in Legacy OU’s

Phase 2: Backup and Removal of Inactive Group Policy Objects

Phase 3: Verify Functionality of Active Group Policy Objects

Phase 4: Rename Active Group Policy Objects

Phase 5: Logically Consolidate Active Group Policy Objects

For us, Group Policy objects had come into existence over a period of years, and at one point almost everyone had rights to create new Group Policy objects… so it was really a mess. Our department did a hostile takeover of everything to do with Active Directory not too long ago, and so organizing and securing it became a top priority.

At the completion of this process the Group Policy implementation at your organization should be much more consistent and easier to manage (I reduced our GPOs by over half… we started with 150 of them). In addition, you’ll have a backup of all Group Policies you have removed “just in case.”

Hopefully, you can use this plan on your own network to clean up your Group Policy objects and begin to apply some consistency to your Active Directory infrastructure.

Phase 1: Removal of Empty Organizational Units
Many organizations create numerous organizational units over time that ultimately get emptied out, but never removed. Therefore, there may be Group Policies that were created specifically for these now empty OUs. By removing these organizational units as the first phase, we can identify a greater percentage of Group Policy Objects that are not currently in use.

Now, I know it’s tempting to try and clean up all of your organizational units at this time… but that should really be a project in and of itself. As this project is principally concerned with Group Policy Objects, only those OUs that are completely empty and unnecessary should be removed.

While it would probably be a simple matter to identify some additional, occupied OUs that could have their objects migrated elsewhere, it would distract from the primary goal of cleaning up our Group Policy Objects.

Phase 2: Backup and Removal of Inactive Group Policy Objects
If you’re reading this, you probably now have several Group Policy Objects that are not currently linked to any Organizational Units and that are not in use in the enterprise.

In Group Policy Management, it is a simple matter to back up an individual policy (just right click on the policy and choose “Back up”). In case any of these policies prove to be needed in the future, every policy should be backed up into a named folder prior to its removal.

Once you have the policy backed up and have verified it does not apply to any OUs, just right click and select delete.

Phase 3: Verify Functionality of Active Group Policy Objects
Some Group Policy Objects may be applied to occupied Organizational Units, but may no longer be functional for a variety of reasons.

For example, we had a Group Policy Object that at one time apparently installed winsnare.msi on Domain Controllers and Servers. However, the install point it referenced no longer exists on our network, therefore the GPO is no longer functional.

Once verified as non-functional, these Group Policy Objects can be removed as well… they’re not doing anything anyway.

The Group Policy Object must be 100% non-functional to be removed during this phase. If any portion of the Group Policy Object is currently functional it should remain intact during this particular phase. The goal of this project and its five phases is to avoid any unnecessary disruption while significantly decreasing and organizing the Group Policy objects.

Phase 4: Rename Active Group Policy Objects
A standard naming scheme for your Group Policy Objects is essential. If you’re like most organizations, you’ll have a ton of GPO’s and if they don’t have a consistent naming scheme it makes it very difficult to accurately identify why a particular policy exists and who it is meant for.

A simple naming scheme should therefore be constructed and applied to the existing group policies to remedy this. More importantly, this standard should be followed from this point forward.

The following scheme illustrates how proper naming can assist an administrator in maintaining a relevant and efficient Group Policy infrastructure.

[Region Code] [Targeted Object] [Policy Category] [Additional Information]

Region Code – Such as NA, EMEA, etc., this indicates who the GPO was created for.

Targeted Object – Such as user, computer, or server, this indicates the type of object the GPO applies to.

Policy Category – Such as WSUS, Display Settings, or Default, this indicates what type of policies are being applied.

Additional Information – Such as Install, Change, or Access, this would be any relevant information that may assist an administrator in identifying what this policy does.

Renaming a Group Policy is safe, it’s just a friendly name, and the computers on your network actually use the SID of the GPO to identify it, which isn’t changing. So, no worried, feel free to rename them at will.

Phase 5: Consolidate Active Group Policy Objects
While not advocating monolithic Group Policy Objects that contain all settings in one object or single-function Group Policy Objects that only contain one policy setting, there are many instances where multiple Group Policy Objects could logically be combined into one object.

In order to determine when it is appropriate to consolidate multiple GPO’s into a single GPO, the following criteria should be used:

  • Multiple GPO’s perform the same function
    • Note: This should be easier to identify once a standard naming scheme is developed and applied
  • Multiple GPO’s apply complementary settings
    • For example, if two GPO’s provide complimentary (not contradictory) settings for Windows System Update Services, then those two GPOs should be combined.

Consolidation should be considered on a case-by-case basis as there are no hard and fast rules for consolidation.

One Response to “Active Directory: Project Plan to Clean and Organize Group Policies”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s