Plan and implement group policy strategy
Starter Group Policy Objects (GPO)
Starter GPOs are baseline templates you can use when building GPOs. Starter GPOs can be exported to other domains too. Starter GPOs are backed up and restored using the backup all and manage backups via the starter GPOs node.
Starter GPOs can only contain administrative template settings.
Group Policy backup and Recovery
Standard group policies can be backed up and restored from within the group policy objects node.
Group Policy Strategy
The best advice with Group Policy is to keep it simple; avoid too much inheritance blocking, organisational units with lots of GPOs, many organisational units linking to the same GPO, monolithic GPOs which change frequently and implement functional GPO where necessary i.e. where changes are frequent; this will speed up the client side extension processing.
It is recommended you disable the user and computer configuration portion of a policy if it is not used; note this is unlikely to speed up processing, the group policy client still has to query Active Directory to check if that portion of the policy is disabled.
The Group Policy ADMX files should be stored in a central store this stores domain controllers storing redundant copies of the same data. The central store should be configured with sysvol; to configure the central store create a policyDefinitions folder and copy the admx policy files to it, create a en-us folder within the policyDefinitions folder and copy the adml language files.
Starter Group Policy Objects should be used to create standardised combinations of administrative templates.
Troubleshooting Group Policy
The first step is to check the core configuration i.e. the computer is connected to the network, can you ping it, can you resolve DNS names, is the system clock within the limits defined by kerberos. Some of the above checks will also test services e.g. resolving DNS confirms the DNS service is working, logging onto the domain confirms the AD DS is working. Remember the core services for group policy are AD DS, DNS and TCP/IP.
Tools such as gpotool.exe, rsop.msc and gpresult.exe can be used to verify what policies are being or not being applied. rsop.msc can point towards why policies are not applied. gpotool.exe can be used to verify policies are correct.
The operational logs within Windows event viewer are also very useful when reviewing which policies have been applied and how long they took.
When policies are not being applied or take an inordinate amount of time to apply it is always good to understand how the group policy process works.
First of all the group policy client queries the nearest Domain Controller to get a list of Group Policy Object which apply to the logged in user and computer.
Next the client side extension processing starts; the newer Windows operating systems use Network Location Awareness (NLA) to determine whether they’re within the domain or on a public internet connection. NLA uses the connection specific DNS information and the NetworkName registry key, if they’re the same the client attempts to query the domain controller using LDAP.
Once NLA deems the client computer to be in the domain the group policy client reads the CSE information from the registry then the group policy client uses LDAP to search for GPOs with the gpLink attribute.
The group policy client then checks whether the user or computer has permission to read the GPO, finally the group policy client reads the gpt.ini to determine if the policy has been updated; it uses information within the client registry to determine this.