Group policy allows you to set up rules which can be applied to a group of users or computers. As the organization grows Group Policy Objects (GPOs) are added, changed and disabled. Enabling and disabling a group policy is fairly straightforward. However, changing a GPO can affect software settings, Windows settings and the administrative templates of users and their computers. If you accidentally delete a core file the impact can be devastating. It could prevent users signing on, prevent computer resources being accessed, or prevent users running their business applications. This article will discuss the six best practices and the tools that help you successfully make changes to Active Directory GPOs.
It is absolutely critical that you apply basic principles of a change management methodology to making changes to Group Policies whether you are a small business with one or two administrators or a multinational organization with tens of administrators. Change management is a methodological approach for how you move from the current situation to the desired situation.
The principles of change management start with an understanding of your current group policy settings and how the group policies are processed. Group policies are processed in a specific order. First the Local Group Policy objects, then Site group policies followed by the Domain and lastly the Organizational Unit. At each of these levels there can be multiple group policies. GPOs are typically applied at the Organizational Unit level, with organization wide policies such as password policies being set at the domain level. The order at which Site, Domain and Organization Unit policies are applied can be seen by clicking on the Linked Group Policy Object tab. You will also need to look to see if block inheritance has been applied and at what level. You can do this by right clicking the Organization Unit as illustrated in figure 1.
Figure 1: Check your group policy precedence and inheritance
You will find that looking at a group policy and how it is applied is like doing a logic puzzle. You have all the clues to work out what will happen, but the more levels and linkages between policies the longer it takes to work out the right solution. Some people find logic puzzles fun while others find them frustrating. Either way it is absolutely critical that you understand what your group policies are and how they are being applied. Incorrectly configured and conflicted GPOs can result in the Active Directory server needing to be taken offline. This type of downtime results in users being unable to connect and access computer resources.
There are all types of skills that you need to have as an administrator: technical knowledge, attention to details and effective communication skills. However, for managing your group policies it is absolutely critical that you recruit an administrator with good problem solving and logic deduction skills.
At the heart of change management is a process. A repeatable process used by all administrators for creating, changing or deleting group policies. A critical part of the process is defining who can do what. At a minimum you should define the roles of planner and approver. The planner determines the required changes to the group policy. The approver technically reviews the changes prior to them going into production. Separation of these roles not only gives an opportunity to identify problems during the review but it will also improve the communications on group policy changes. This latter consideration will help with the very common problem of administrators making changes that conflict with previous changes that they were not aware of.
Active Directory allows you to delegate different levels of responsibility. For example, you can give more junior administrators the ability to read Group Policy Objects but not the ability to change them. Whereas you can give your senior administrators read / write group access. Figure 2 shows how read / write permissions for an Organizational Unit can be set using the Active Directory Administrative Center tool. Unfortunately there is no approval processes defined in Active Directory Administrative Center. In other words administrators with read / write access can make changes in the live Active Directory system without needing a second administrator’s approval.
Figure 2: Set your administrators permissions based on their expertise
However there are tools available that will enable you to define different administrator roles. For example Microsoft’s Advanced Group Policy Management (AGPM), which is part of Microsoft Desktop Optimization Pack for Software Assurance, allows you to define editors, reviewers and approvers. Fortunately if you are a small to mid-size business there are standalone tools which will allow you to approve or reject Group Policy changes before they go into production.
A typical change management process would change the approval process depending on the risk associated with the change. Small changes may be considered a lower risk and you may be tempted to allow them to be made without going through a tool that requires a formal procedure to place the group policy into production. It is important to remember that even small changes to configuration settings can have a far reaching effect. Group policies should not be changed very often. It is a highly recommended best practice to have a formal review and approval process before making any changes to group policy settings.
Today we are being asked to do more with fewer resources. It is therefore easy to overlook the task of tracking group policy changes. However, not only is tracking group policy changes potentially part of your compliance requirements, it is essential for recovery in the event of needing to roll back a change or to recover your Active Directory system in the case of a major disaster.
There are also a couple of other advantages of implementing version control. First you will be able to compare the current group policy settings with the previous version. This can be invaluable in troubleshooting. Secondly, it also provides you with insights into how your group policy has evolved over time, which can be particularly valuable in identifying ways to optimize and simplify your group policy settings. For example, since implementation you may have defined several GPOs that are applied to users or computers, which could now be combined to form a single GPO. Optimizing your GPOs in this way will both improve performance and make it simpler to implement future GPO changes. Looking at the history of GPO changes also enables you to see if your design guidelines for creating GPOs are being followed. For example GPO naming conventions, and how group policies should be nested.
The Group Policy Management Console in Active Directory allows you to export and back up GPOs, but it does not provide version control. It is highly desirable to implement a version tracking tool to keep a history of changes and which administrator made them.
All new GPOs and changes to GPOs should be tested prior to being imported into the production environment. Some organizations maintain a lab environment to test the GPO for inconsistencies. Larger organizations generally have a lab environment running a full Active Directory system for testing purposes. In this case it is important that you know which GPOs are on the test system and which ones are missing. Alternatively IT departments can use third party tools that allow them to change a GPO prior to them going into production. These tools generally use scripts to create a staging area that mimics your production environment and they allow you to test GPO changes in an off line environment.
Another useful tool is Group Policy Modeling which is part of Active Directory. This feature allows you to run “what if” analysis. It can be useful when you wish to simulate basic group policy changes. For example if a user changes their job function and may you needed to change both the user and their computer to have a different group membership. In this situation you could make the changes in the modeling tool and it will generate a report showing you all the settings that would be applied to this user and their computer. You can then review the settings to make sure they are not conflicting before you implement the changes in the production environment.
A best practice for minimizing the risk of GPO conflicts is to restrict administrators permissions and allow them to make only certain types of GPO changes. For example different administrators could be responsible for specific GPOs such as an administrator that manages only the settings for install and updating software of networked computers or an administrator that manages the settings for a specific Organizational Unit.
Active Directory allows you to delegate administrative responsibilities. It supports delegation of individual GPOs, of GPOs at the Domain, Site or Organizational Unit levels, and who can run scripts. The delegation of administrator responsibilities should ideally reflect your business structure. For example if your IT department is distributed then you could delegate responsibility at the Organization Unit level. When delegating responsibilities remember the priority and inherited properties of group policies, for example when delegating an Organization Unit it could be for just the Organizational Unit or include its child Organizational Units.
Even with good testing the worse can happen and you could apply a GPO change and find that there is an unexpected adverse impact. The temptation may be to perform an initial analysis and try to fix the problem in the production system. However some of the biggest system outages and security vulnerabilities are caused by folks that try to fix the problem in the live environment but inadvertently compound the problem. A best practice is, when something adverse happens roll back the system to a known good state.
Active Directory does provide built in tools to back up one or more GPOs. You can do this in the Group Policy Management tool by right clicking the GPO that you wish to back up and selecting the Back-Up option. You can use these backups to either replace a GPO or overwrite a GPO’s settings. However it is not easy and it can often introduce new errors. Even something as seemingly simple as the deletion of an Organizational Unit may take an administrator more than a day to recover from.
Figure 3: You can back up individual GPOs
The Microsoft Advanced Group Policy Management tool mentioned above uses GPO versions to allow you to roll back GPO changes. There are other less expensive tools and even freeware that will enable you to roll back changes. Key features to consider when looking for a tool to enable roll back of GPO changes include the ability to restore at the individual GPO level, ability to report the changes made in the restoration process and the time it takes to revert to a known good state.
Active Directory protects your network resources and changes to group policies and are essential as your organization changes and evolves. Any disruption to the smooth operations of Active Directory can have a significant impact on the user’s ability to work and access computer resources. When applying GPO changes you should plan for the unexpected.
Best practices for making group policy changes encompass finding the right administrators, implementing change approval processes, keeping a log of changes, restricting administrator’s responsibilities, and making sure you can recover when the worse happens. There is one last best practice which is simple but essential. Make sure you are notified of GPO changes.
There are lots of ways to be notified when GPO changes are made, such as an email or a short message to your cell phone. You need to be aware when changes are being made so you will be in a better position to react should a problem subsequently arise. You also need to be aware if someone is making changes to group policies that are not authorized.
Make it your New Year’s resolution to implement the best practices outlined in this article and increase your control over changes to your group policies.