Group Policy can be the most important parts of an IT groups tools to enforce IT standards and manage access, or it can be an indecipherable mess in which you do not want to touch. No matter where you fall in that mix, it is a good idea to take a look at the configuration with the Group Policy Diagnostic Best Practice Analyzer (GPDBPA) explained in this article to identify your risks and configuration.
Getting a handle on Group Policy in a Windows Server 2003 environment can be difficult. Properly implemented, Group Policy can help you get very granular control over your network. Improperly implemented and group policies can be a nightmare. That s where the Group Policy Diagnostic Best Practice Analyzer (GPDBPA) comes in.
The GPDBPA is simply a Microsoft provided tool that will search for configuration errors, export data, and identify problems in a Group Policy configuration. The GPDBPA for Windows Server 2003 Service Pack 2 and higher is now available for download. In this TechRepublic article; we will go through usage scenarios to show how the tool can identify issues with Group Policy configurations.
How to Get the Tool
The GPDBPA is a freely downloadable tool from Microsoft. It can be installed on Windows XP and Windows Server 2003 systems. It has a small footprint, 1.31 MB, so you may consider adding to your build process for servers as one part of troubleshooting a system that is not processing Group Policy Objects (GPOs) or domain functions correctly.
How to Use the Tool
Using the GPDBPA runs in a mode where you provide the context elements for the scan of the GPOs. The context elements include determining a name for the scan, providing the username, computer name if specifying a Domain Controller to test, and the test location which are managed node (which is a client computer) or domain controller. The scans are saved as .XML files locally in the C:\Documents and Settings\%Username%\Application Data\Microsoft\GPBPA path and are about 375 KB in size. The files are not deleted automatically when exiting the tool, so be sure to manage the files after use. Scans are saved to the system and are viewed by clicking the Select a Best Practices Scan to View link on the left side of the tool. You may wish to make a scheduled task to move them to a central repository or delete them from the local file system as they could chew up drive space unnecessarily over time.
Running the tool is intuitive enough, and the best way to get experience with the information it can retrieve is to use it on a test domain and make some configurations that would be blatantly an error like removing access to the default domain policy. A good way to do this in a very safe fashion would be to perform the following steps:
- Make a new domain controller as a virtual machine.
- Take that virtual machine off the main network and into a private network with no connection back.
- Run the GPDBPA to determine baselines before you make any changes to your GPO links.
- In the private network, run the tool and make configuration changes to the domain and see how the GPDBPA reports the configuration changes and issues.
Become familiar with what you want to look for before taking it to your live domain. In a domain with many GPOs, the data may be overwhelming.
When running the GPDBPA, the results are an XML file that can be viewed within the tool. This file will show categories of issues such as critical issues, non-default settings, recent changes, baseline, and informational items. Running the tool in a test domain initially gives me two errors, the first is that there are incorrect permissions on the default domain controllers policy and that there is a missing group Policy link for default domain policy. In this situation, these issues were corrected individually, and then the GPDBPA tool will report the errors as corrected. Figure A shows the results before and after the corrections.
One scenario where the GPDBPA would be particularly helpful is a pre-implementation of a major GPO change. Consider a test Active Directory domain that you may have isolated from your live network, you could make your major GPO changes and supplemental to your other testing processes, run the GPDBPA tool on this domain and ensure that the inventory of errors is not different from that which you are running on your live domain. Realistically, this tool will likely not return a clean bill of health for any live Active Directory installation, but in the test space what you want to ensure is that there are issues (especially the critical ones) that you do not already have on the live domain.
How Thorough is the GPDBPA?
The GPDBPA will traverse Active Directory based on the information you provide in the scan elements. Be careful to note that some configurations are not detected by the GPDBPA tool, namely password policies. For example, if you have an Organizational Units (OUs) with different password policies, the GPDBPA will not identify which OUs have the different policies applied. The best practice would be to set it as high as possible in either the default domain policy or a separate GPO. So keep in mind, the GPDBPA is not a security scanning tool in its core function, therefore the GPO for a bad password policy from the security standpoint would not be identified in a GPDBPA scan. However, some security elements are detected, especially those which would prevent other GPOs not to function.
Take time to look through the informational items section of your first and subsequent scans, this will confirm that many critical elements of the Group Policy configuration are correct. For example, if you specify a computer and user account in the scan parameters those accounts are verified to have the required access to the default domain policy.
Okay, So, Now What do I do with all of this Data?
The GPDBPA tool will likely show you a few issues with your Group Policy configuration that are listed in the critical configuration section on your first run. From an ongoing perspective, the main goal is that the critical issues do not continue to appear in the GPO configuration. There will be occasional error-state critical messages that would appear (like the DNS client service is not running on the domain controller, for example) and those issues may be noticed elsewhere first.
For the results of the GPDBPA, what is done with the information is up to you. If you are addressing a specific issue, the answer is pretty clear go ahead and fix it is you see it as a result in the tool. But, the Microsoft best practice for a GPO configuration may not necessarily be the configuration you wish to use in your environment. Consider all factors such as access, impact, scope, backing out a change, and relevance of any change before deciding to implement what is recommended by the tool. In the iteration example above, the two issues corrected were listed as Critical within the tool. However, there were eight issues not listed as critical. These issues included the Group Policy setting preventing users from installing printer drivers set to false (meaning users are enabled to install printer drivers).
While that is the default value, the GPDBPA tool identifies that as a configuration that could be set within Group Policy. One feature that the tool allows you to do is to suppress certain issues to not display on subsequent iterations. This is particularly useful if within your IT policies you decide you want a certain value set, yet do not want to be reminded of this issue with the GPDBPA tool.
The GPDBPA tool has a decent help file (GPDBPA.chm) installed locally in the C:\Program Files\GPDBPA\en path of default implementations that usage scenarios for both domain controller and client systems.
Additional Considerations for Domain Controllers
Using GPDBPA on a domain controller (DC) will determine if the SYSVOL share exists, if the DC can access the default domain policy, and how many cumulative GPOs are defined in the Active Directory database, among other things. This information may not appear to be incredibly helpful in that form, but consider the following scenario where it can help diagnose an issue. If one domain controller had the C:\ drive become full and it was not functioning correctly with its expected roles because the local copy of the Active Directory elements were not reconciled correctly with the rest of the domain.
Here, the GPDBPA could give results that confirm logon issues reported by clients and lack of GPOs being applied. With that issue, the best strategy may be to rebuild the DC (if it is not the only DC) and ensure proper drive space for the system. The GPDBPA is a generally safe tool in that it queries the Active Directory domain and does not modify the contents of Active Directory or GPOs. The GPDBPA also does not make a large performance hit on the domain controllers either while running. Also running the GPDBPA regularly can keep the baseline of the number of GPOs in use for your Active Directory organization, maybe leading to GPO consolidation as this tool provides information on all of the GPOs in use in the domain.
Go Ahead, Kick the Tires
Take the GPDBPA tool for a test drive, and take a look at any issues that are reported with a new look. With that information, you can evaluate if your IT policies are being correctly executed when reliance on Group Policy is critical.