As we all know, I don’t usually dive into servers or applications, my primary specialty and passion is the infrastructure which runs it all. Despite this, my current position requires me to be proficient in all of it so that I can provide advanced technical support and instruction to our less experience technicians.
After an in depth instruction with one of my junior Marines last night, which rolled over into this morning, I decided it’s a good time that I revisit some of the key elements of group policy.
What is Group Policy?
Group Policy is simple. It provides administrators the ability to centrally administer all workstations and servers connected to a domain. The function of Group Policy Objects (GPOs) can vary depending upon circumstances, ranging from enhanced security, improved functionality, compliance and overall consistency across the domain.
GPOs actually dive a little deeper, as we configure them, we see them in a simple, easy to read and navigate interface. However, under the hood GPOs are actually used to modify registry settings within the Windows operating system. This is great because the registry is difficult to navigate and dangerous if navigated improperly. It also would be virtually impossible to provide consistency across the domain if administrators had to modify the registry every time they needed to push a change to users or computers.
Within a GPO, there are two scopes which we can modify settings for.
- Computer Settings – generally applies changes to the HKEY_LOCAL_MACHINE registry hive.
- User Settings – generally applies changes to the HKEY_CURRENT_USER registry hive.
Registry settings can be viewed utilizing the registry editor (regedit.exe)
What can we do with GPOs?
The power of GPOs is limitless.
This is because GPOs can not only modify settings for Windows components, but also manage installed software, GPOs can install software remotely, run scripts, or modify the users interface. GPOs can do whatever you set your mind to do.
GPO Location and Components
For those not familiar with where GPOs are located, they are located within the SYSVOL. The SYSVOL (System Volume) is used in active directory as a method to share settings between domain controllers, as well as to workstations and users. The SYSVOL is replicated to all other domain controllers within the domain. It utilizes the Distributed File System (DFS) to provide these to servers, workstations and users.
Within the SYSVOL is the “Policies” folder, the policies folder will contain folders named with the Globally Unique Identifier (GUID) of each group policy object in active directory.
Also withing the “Policies” folder is the option to create a folder called “PolicyDefinitions” this folder, when created, will provide administrative templates which can be used and sent to any computer in the domain. This becomes known as the Central Store which computers will reference when they do not locally have an administrative template which the central store contains.
Without a central store it is impossible to make your domain entirely consistent, this is due to the fact that not every computer will have identical administrative templates installed which allow these group policy settings to be applied. Each computer maintains its own central store in the “%windir%\PolicyDefinitions” folder. If you fail to create the central store in the SYSVOL, the Group Policy Management Console (GPMC) will load the administrative templates from it’s local central store, these will be inaccessible to other computers in the domain.
What are Administrative Templates?
Administrative Templates are files which are released by software manufactures which provide Windows with the information it needs to allow us to modify the registry settings to a respective software. Administrative Templates are released for most software, although there are some exceptions such as Firefox. The default administrative templates each computer will have vary on the version of Windows installed, but it’s important to know that each computer will only have the bare minimum of these templates which Microsoft provided during its respective release.
There are two file types which contain settings: ADMX and ADM files. ADMX files are the newer version of administrative templates, whereas ADM are the legacy templates. There is also a third type, however, this is for language support (ADML).
It’s important to know that although ADMX and ADM files are great, they are limited in that they cannot make changes outside of the HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER registry hive.
Microsoft provides all their updated ADMX files in their download center, and can easily be googled. Something important to know with the advent of Windows 10 is that for each new major release, the ADMX files will be updated. This means that Build 1703 ADMX files are slightly different than Build 1709 and should be monitored and updated as your environment migrates to newer releases.
To install and Administrative Template, simple copy the ADMX files into the central store, if the ADMX has associated ADML files, copy them to the correct folder.
Windows Management Instruction Filters
About as important as consistent configurations across your domain is ensuring that policies get applied to their intended systems. This is where Windows Management Instruction (WMI) filters come into place. WMI filters are essentially just queries which obtain system information regarding installed software or operating system versions and any roles which they hold.
To create a WMI Filter, open the GPMC and navigate to the WMI filters container within GPMC. Right click and select “New…”
In the popup window, name the WMI Filter, we are going to be creating one for Windows 10. After you have named it, click the “Add” button. Leave the namespace set to “root\CIMv2”, in the query add the following. Once done, click “Ok” and “Save”
select * from Win32_OperatingSystem where Version like "10.%"
The following is a table of all of the WMI Filters for past and present Windows versions (not legacy of course).
[table id=4 /]
WMI filters can be applied to a GPO by navigating, clicking on the “Scope” tab and navigating to the bottom of the pane. You will see a section called “WMI Filtering”, in the drop down, you can select which WMI Filter you want to apply. A popup will appear asking you to confirm, click “Yes”.
Group Policy Inheritance
Now that we have covered the components which help us build and make our GPOs robust, let’s talk for a second about group policy inheritance. There’s a pretty simple acronym for remembering GPO inheritance.
LSDO
In the order that they are processed, top being first, bottom being last. GPOs which originate due to a link lower in the process will take precedence.
- Local – the group policy stored on the workstation or server
- Site – any group policy which is applied to the Active Directory site
- Domain – any group policy linked to the root of the domain
- Organizational Unit (OU) – any group policy explicitly linked to an OU
It does, however, get a little more confusing than that. Say you have a GPO linked to a parent OU, but a separate GPO linked to a child OU.
Example.
- GPO Applied to “OU=Test,DC=lab,DC=teachmehowtoroute,DC=com”
- GPO Applied to “OU=Child,OU=Test,DC=lab,DC=teachmehowtoroute,DC=com”
Active Directory (AD) will process GPOs applied at a higher level first. Meaning that the GPO in the child OU would be processed last. However, because it is processed last, it will technically receive more precedence than the GPO applied to the parent OU. This is because since it is processed last, it may (or may not) have settings which conflict with the GPO at the higher level.
Lets say you have alot of GPOs, and because of this, there are multiple linked to the same OU. There is something called link order, when you navigate to the OU, click on the “Linked Group Policy Objects” tab. Within this tab is a pane which depicts the link order, links with a lower order number (higher on the list) are processed first. Similar to the above situation, GPOs lower on the list do technically receive more precedence.
Along with the afformentioned, there is the option to “Block Inheritance” on a GPO. The purpose of this is to prevent unwanted or erroneous GPOs linked to a parent container from being applied to objected within an OU. To do this, simply right click on the OU and click “Block Inheritance”
Note: OUs with blocked inheritance will show up with a blue circle with an exclamation point in them.
Additionally, you can also “Enforce” GPOs, enforcing GPOs will push the GPO to objects in containers with blocked inheritance. To do this, right click the GPO Link in GPMC and click “Enforced”
Note: GPOs which are enforced will be depicted with a lock in the corner of them.
I think this concludes this discussion, the following are the basic tools you can use to help you troubleshoot GPOs. For best results, especially when troubleshooting Computer and not User configuration Settings, run the command prompt as administrator.
To force Group Policy Update to Local Machine:
gpupdate /force
To view applied GPOs, name only:
gpresult /R
To generate an HTML Report
gpresult /H GPOResult.html