Introduction
I know I am a geek! I think you are too, due to the fact you are reading this article based on the title! It is ok… as there are a group of us that just love Group Policy. That is right… love Group Policy. Actually, I have a group of friends (yeah, I will consider them friends!) who love Group Policy as much as I do. They are all MVPs in the area and they are some of the most amazing colleagues and friends I know. They help me, I help them and we try to make Group Policy fun and try to help every corporation understand how to leverage Group Policy better. So, over the years, I have heard and seen some amazing things said and misunderstood about Group Policy. Here is a simple list of statements and comments as to the truth about each.
Statement: All Registry Modifications Through Group Policy Tattoo
Truth: Fiction
Comments: There are four Registry paths which are volatile to overcome this concept of tattooing the Registry using Group Policy. They all four have the key “Policies” in the path. There are two for HKLM and two for HKCU. The concept is that when a GPO configures a Registry entry which can also be written in one of these four paths, the setting is duplicated in the original path and also in the special “Policies” path. If both exist, the Policies path controls. If only the original exists, due to the fact the Registry entry has not been configured using Group Policy or the GPO no longer applies, thus removing the Policies path entry, the original setting takes over once again.
Statement: If a user alters the Registry entry, which a GPO configured, the GPO at next refresh will alter the Registry entry back to what the GPO is set to.
Truth: Fiction
Comments: Group Policy is a rather simplistic technology. Each GPO modification updates the GPO version number, which is also stored on the target computer at refresh time. So, if the user of a target computer alters the Registry, the version number of the GPO does not change, thus at refresh the GPO version number of the GPO did not change, so no updates occur. This can be overcome by the use of gpupdate /force, which ignores GPO version numbers and applies all settings in all GPOs which apply to the computer where you run the command.
Statement: A Group Policy extension, such as Group Policy Preferences or PowerBroker from BeyondTrust (original maker of Group Policy Preferences) can be installed and controlled by an OU Administrator
Truth: Fact
Comments: Group Policy extensions are easier than anyone can imagine. A Group Policy extension has two components. First, there is an update to the GPMC and Group Policy Editor, which allows the administrator to “see” the setting in the editor for configuration. This only requires local administrator privileges on the desktop or server where the GPMC is being used. Second, there must be a client side extension (CSE) installed on every target computer that will have the “new” Group Policy extension setting applied to it. This can be done manually or via Group Policy Software policy, which again does not require anything more than the ability to edit a GPO and link it to an OU of computers.
Statement: Using RSOP.msc can give a false reading of what the computer settings really are
Truth: Fact
Comment: RSOP.msc stands for Resultant Set of Policy. This tool shows ONLY the settings that are being deployed to a target computer from a GPO within Active Directory. That means that local policy settings and all computer settings (via a GUI or application) don’t show up in the RSOP results. Only settings that are deployed from a GPO linked to the domain, OU, or site show up. Thus, if you have a setting which you configured in the desktop image or via an application, that setting will not show up using RSOP.msc. If the setting is a security setting, I highly suggest using secpol.msc, which will show the “actual computer setting”, regardless of where the setting came from.
Statement: Once I have Windows Server 2008 and/or Server 2008 R2 domain controllers, I can have multiple password policies using Group Policy Objects linked to OUs
Truth: Fiction
Comment: If you use Group Policy Objects to configure the Account Policies (which includes the Password Policy settings), you can only have one password policy per domain. The default password policy suite of settings is configured in the Default Domain Policy, which is linked to the domain node of your domain. Any GPO that you link to an OU will never effect domain user accounts. Instead, these GPOs and the password policy settings contained within them will only effect the local user accounts stored in the local SAM of the computers which are located in the OU. Using Group Policy, the only way to effect the password policy for domain user accounts is in a GPO , linked to the domain node. Now, Windows Server 2008 and 2008 R2 does have a new password policy feature referred to as Fine-Grained Password Policies. These settings are not configured using Group Policy! Instead, these settings are configured using ADSIEdit! These password policies do allow for multiple password policies in the same domain, but you must create additional AD objects to configure them. They are also controlled by the security access control list associated with the AD object created, which means the password policy will be group based, not OU association based.
Summary
I know this only includes a few Group Policy concepts, but these are the common issues that I see Group Policy and AD administrators struggle with. The one thing to always remember with Group Policy is to test, test again, then test those results. Just because the technology “looks” like it works the way you want, does not mean it actually does. From my perspective, the simpler you make your Group Policy implementation, the better. Stay away from settings such as Enforce, Block Inheritance, and Security Filtering. These settings can cause troubleshooting issues that are more complex than most administrators want to manage. Try to link your common Microsoft Group Policy settings and the GPOs they are configured within to OUs. There should be very few GPOs linked to the domain, unless you have third party Group Policy extensions, such as BeyondTrust PowerBroker, which can handle GPOs linked this high in the AD structure. I also highly suggest you stay away from technologies that state they are “Group Policy” based, but don’t use the built-in Group Policy service and overall Microsoft Group Policy technologies. These technologies can cause strange behavior and cause issues beyond what you need and want to manage.
