1. Identify all related settings and remove them from the Group Policy before updating the Central Store, if currently configured
2. Create a management system (server or client) per version of the Windows Operating system present in your environment and configure the Group Policy objects for a specific version of Windows from the corresponding management system. If a Central Store is configured in the environment, configure the GPMC on these management systems to bypass the central store as described in this article:

• Annotations: General comments about the document
• ADMXOSAvailability This spreadsheet displays all ADMX files and their availability in different versions of Windows
• ADMXChangesFull All changes in ADMX files, starting Windows Vista up to Windows 10 and Windows Server, version 1709
• admx_IE11 All changes that occurred in the Internet Explorer 11 ADMX file
• Removed_Items A list of all ADMX files and Policy settings removed between Windows Vista up to Windows 10 and Windows Server, version 1709
• New_Items A list of all ADMX files and Policy settings added between Windows Vista up to Windows 10 and Windows Server, version 1709
• Changed_Items Changes made to Policy settings between Windows Vista up to Windows 10 and Windows Server, version 1709. Important changes, as Registry Key value changes, are marked red.

• Nano Server has different capabilities than Windows Server 2016
• Nano Server does not have the Group Policy editing, management, or client service.
• To manage Nano Server security policy, refer to this post: https://blogs.msdn.microsoft.com/powershell/2016/05/09/new-security-cmdlets-in-nano-server
• Windows Server 2016 and Windows 10 clients continue to have full support for Group Policy.

Many organizations still need to manage domain joined computers at a granular level such as Internet Explorer’s 1,500 configurable GP settings or very specific Windows Firewall rules. In these cases, Group Policy and System Center Configuration Manager continue to be excellent management choices. Group Policy is the best way to granularly configure domain joined Windows PCs and tablets connected to the corporate network using Windows-based tools. Microsoft continues to add Group Policy settings with each new version of Windows.

Jeremy Moskowitz blogs about how to use his product, PolicyPak, to disable various 3rd party software through Group Policy.

Derek Melber has launched a new site, http://auditingwindowsexpert.com/.

Alan Burchill has written best practice guides for Active Directory and Group Policy design .

This post (including the introduction) is a partial reproduction of a white paper written by one of our Group Policy MVPs, Darren Mar-Elia, with some additional comments and information. Darren has also written a free tool to help identity if your configuration might be susceptible to long logons.

This post covers:

•          Foreground vs. background processing.
•          Synchronous vs. asynchronous processing.
•          GPOs with WMI filters.
•          GPOs with scripts.
•          Group Policy Preferences.
•          Actions you can take in Windows 8.

Foreground vs. background processing

Foreground and background processing are key concepts in Group Policy. Foreground processing only occurs when the machine starts up or when the user logs on. Some policy areas (also called Client Side Extensions (CSEs)) can only run during foreground processing. Examples of these include Folder Redirection, Software Installation and Group Policy Preferences Drive Mapping. In contrast, background processing is that thing that occurs every 90 or so minutes on Windows workstations, where GP refreshes itself periodically. Background processing happens, well, in the background, while the user is working and they generally never notice it. While background processing doesn’t impact performance, foreground processing can extend start and login times. This post will be focusing on foreground processing.

Synchronous vs. asynchronous processing

Foreground processing can operate under two different modes—synchronously or asynchronously. The default foreground processing mode for Windows clients since Windows XP has been asynchronous. Asynchronous GP processing does not prevent the user from using their desktop while GP processing completes. For example, when the computer is starting up, GP asynchronous processing starts to occur for the computer, and in the meantime, the user is presented the Windows logon prompt. Likewise, for asynchronous user processing, the user logs on and is presented with their desktop while GP finishes processing. The user is not delayed getting either their logon prompt or their desktop during asynchronous GP processing. When foreground processing is synchronous, the user is not presented with the logon prompt until computer GP processing has completed after a system boot. Likewise the user will not see their desktop at logon until user GP processing completes. This can have the effect of making the user feel like the system is running slow. In short, synchronous processing can impact startup time, where asynchronous does not.

Foreground processing will run synchronously for two reasons:

1)      The administrator forces synchronous processing through a policy setting. This can be done by enabling the Computer ConfigurationPoliciesAdministrative TemplatesSystemLogonAlways wait for the network at computer startup and logon policy setting. Enabling this setting will make all foreground processing synchronous. This is commonly used for troubleshooting problems with Group Policy processing, but doesn’t always get turned back off again.

2)      A particular CSE requires synchronous foreground processing. There are four CSEs provided by Microsoft that currently require synchronous foreground processing: Software Installation, Folder Redirection, Microsoft Disk Quota and GP Preferences Drive Mapping. If any of these are enabled within one or more GPOs, they will trigger the next foreground processing cycle to run synchronously when they are changed.

Action: Avoid synchronous CSEs and don’t force synchronous policy. If usage of synchronous CSEs is necessary, minimize changes to these policy settings.

GPOs with WMI filters

If you must use a policy setting that triggers synchronous processing, another area to take note of is the use of WMI filters. A WMI filter does not automatically slow down GP processing appreciably, but if a WQL query implemented in that filter is time consuming, it could slow down the startup or logon  process, This is true especially if that workstation is running Group Policy processing synchronously. A few long-running queries can extend the amount of time it takes to finish processing Group Policy. Costly WMI filters include those that rely heavily on network traffic, such as LDAP queries.

Action: Avoid costly WMI filters such as LDAP queries

GPOs with scripts

As with WMI filters, long-running scripts might impact performance during synchronous processing. Startup or logon scripts are not by themselves always a problem. But too many scripts running for a given user or computer, or scripts that hang or are no longer really in use, can add to startup and logon times. Frequently, people don’t recognize the number of scripts that are present. Try looking through your environment for startup or logon script policies and reviewing them to ensure they are responding (scripts that aren’t responding will not timeout for 10 minutes, by default) or otherwise taking a long time to execute.

Action: Look for costly scripts by running them in isolation and work to improve the scripts’ performance or avoid these scripts

Group Policy Preferences

GP Preferences settings that use Item- Level Targeting (ILT) are not inherently harmful. However, certain kinds of Item Level Targeting queries can take more time to run. You can find these targets in any Group Policy Preferences setting under the Common tab. Costly ILT evaluations include all of the ILT types that must work over the network against AD to be evaluated: OU, LDAP Query, Domain, Site and Computer Security Group filters.

Actions:

•          Don’t run ILT evaluations such as OU, LDAP Query, Domain, Site, or Computer Security Groups.
•          If you need to use security group filters, consider this KB article.

Similarly, Group Policy Preferences Printers can take some time to install a printer driver. If a printer item is set to “replace,” it will re-install the printer driver every time it runs. If you are deploying several printers at once, this can add up quickly. Instead of “replace,” consider using “create” or “update.”

Action: Don’t use “Replace” with Group Policy Preferences Printers.                 

Actions You Can Take in Windows 8

We made changes in Windows 8 to give greater control over synchronous processing. Synchronous processing takes longer over slow networks, because Group Policy makes many requests to domain controllers when applying Group Policy. To mitigate this effect, we added an option to allow computers or users on a slow network connection to avoid processing any CSEs that require synchronous processing. All other policy settings will apply as normal. Those synchronous policies that were skipped while on a slow network will take effect the next time a user or computer is on a fast network (as usual).

You can find this policy setting in Computer and User configurations under Policies -> Administrative Templates -> System -> Group Policy -> Change Group Policy Processing to run asynchronously when a slow link is detected

The Configure slow link detection policy setting in the same path allows you to configure the threshold at which Group Policy determines a link is slow. Slow link detection raises event 5314 in the Group Policy Operational Log (Located in the Event Log Viewer under Applications and Services Logs -> Microsoft -> Windows -> Group Policy) . Checking this event will show if Group Policy has detected a fast or slow link, as well as the detected bandwidth, and the threshold that has been set. 

Action: Disable synchronous logins when on a slow link

Summary

Windows 8 provides new mechanisms to help reduce the impact of synchronous processing. By utilizing available tools and being aware of the necessary difference in the design and deployment of GPOs you can substantially improve your user’s desktop startup experience.

Actions you can take to improve Group Policy performance:

•          Avoid synchronous CSEs and don’t force synchronous policy, or if CSE usage is necessary, minimize changes to these policies.
•          Avoid costly WMI filters such as LDAP queries.
•          Look for costly scripts by running them in isolation, and work to improve the scripts’ performance or avoid these scripts.
•          Don’t run ITL evaluations such as OU, LDAP Query, Domain, Site, or Computer Security Groups.
  •    If you need to use security group filters, consider this KB article.
•          Don’t use “Replace” with Group Policy Preferences Printers.
•          Disable synchronous logins when on a slow link.

This is one of those tidbits that when I come across them I wonder how I can use this for making it easier to create Group Policy reports. So, here’s what I’m thinking:

If you administer Group Policy in a somewhat large enterprise then you’ve probably got hundreds, if not thousands, of GPOs to deal with.

If you’re like me, I used to grab a listing of GPOs, throw the listing into Excel and start playing games with the data. Well, what if you could pretty quickly grab GPO data on the fly and play some games with it?

More importantly, what if you could grab GPO data on the fly, not just for a single domain, but for your whole forest? But wait, you say. We already did that. Actually, I already wrote a blog post on how to list all the GPOs for a forest. And if you haven’t read that, you can find it here: http://blogs.technet.com/b/grouppolicy/archive/2011/06/10/listing-all-gpos-in-the-current-forest.aspx.

But what if you could look for all the GPOs in your entire forest and list them based on the GPO status? In other words, list all GPOs in a forest with the disabled or partially disabled GPOs grouped separately. And you can do this in a single line of Windows PowerShell. Would you find that interesting? If you agree that this would be helpful then read on.

Jeffrey in his blog post explained that the Format-Table cmdlet has a parameter –GroupBy that tells Format-Table to generate a series of tables instead of one big table. These tables will be based on the –GroupBy parameter.

Big note here. Before we get into the guts of the blog post, you need to remember to import both the Group Policy and Active Directory modules before running these cmdlets. In other words, GPMC is installed on server or client and Active Directory role is installed on server or AD tools are installed on client. Then from the Windows PowerShell command prompt, I need to run these two commands at the start of my session:

Import-Module ActiveDirectory

Import-Module GroupPolicy

I still have my little test domain called, corp.Contoso.com, with a child domain of HQ.corp.Contoso.com. And I can very easily use the Get-GPO cmdlet with the –all parameter to see all the GPOs in the entire forest with the following command:

(get-ADForest).domains | foreach { get-GPO -all -Domain $_ }

This will display all the GPO information, but it will come as the GPOs are read from each domain.

Now, it becomes clear why I started this blog mentioning Jeffrey Snover’s blog post about sorting a table using the –GroupBy parameter. I want to see all the GPO information grouped by the status of each GPO. What happens if I add Format-Table (with alias of ft) using the –GroupBy parameter to the end of my previous command line?

(get-ADForest).domains | foreach { get-GPO -all -Domain $_ } | Format-Table -GroupBy GpoStatus

This will group the GPOs, but not quite as I expected. Instead of one table for AllSettingsEnabled, another for AllSettingsDisabled, etc., I seem to be getting clumps of GPOs based on status. You can see that in this partial display.

There’s a technical reason that Jeffrey goes into in his blog post. But the short answer is that the Format-Table cmdlet processes the input as it comes to the cmdlet. There’s no place to hold the input in order to group all of the results together at once. Presorting the information in this case will get us what we really want.

I want to make sure the GPO status is sorted first. Then it’s a toss-up of whether I want to see GPOs in alphabetical order based on the display name or an alphabetized list of GPOs first grouped by domain. For this example, I’m going to list the GPOs in alphabetical order within the GPO status groups. I’ll leave it up to you to play with changing the order of the sort to see what happens.

(get-ADForest).domains | foreach { get-GPO -all -Domain $_ } | sort GpoStatus, DisplayName | Format-Table -GroupBy GpoStatus

Now, we get what we wanted a series of tables that show GPOS based on status: AllSettingsDisabled, UserSettingsDisabled, ComputerSettingsDisabled, and AllSettingsEnabled. Much better.

My only problem with this is I can’t see all the data because my screen isn’t wide enough. The other way of displaying all the data for GPOs worked better in this case. So, how can I group by GpoStatus, and get all my data?

The answer is once again pretty simple. The –GroupBy parameter also works for Format-List.

Running the following command gives me the results I want:

(get-ADForest).domains | foreach { get-GPO -all -Domain $_ } | sort GpoStatus, DisplayName | Format-List -GroupBy GpoStatus

You can try grouping by other things than GpoStatus. For example, you can DomainName, Owner, or WmiFilter. Or try sorting by CreationTime or ModificationTime.

You may be asking yourself, “What does infrastructure status have to do with Group Policy”. Well, group policy depends on other technologies to ensure that policy settings are replicated throughout your environment so that end users / computers will get the settings that you configure.

And when you’ve run into problems you start wondering: did replication finish? Are there errors? And if there are, how am I supposed to see what errors have happened?

Since you are a GP admin and not necessarily an AD/DFSR admin, you only want to know that all of the replication that is supposed to be happening for Group Policy Objects is happening. In Windows Server 2012 we have added a feature that will tell you just this.

The feature is called Infrastructure Status and you can find it in the GPMC results pane for each domain object. Simply click the domain that you are interested in and in the result pane you will see a new tab labeled “Status”. This “status” tab will show the status of GPO replication (for both SYSVOL and AD) of all GPOs across your entire domain.

If you suspect you have a replication problem with a single GPO, to speed up your troubleshooting, you can check the infrastructure health status for that GPO. To see the status, open the Group Policy Objects node and select the GPO listed under that node.

Note: The infrastructure health status is not available when you click on GPO links displayed under the domain and OU nodes.

Initially, the Status tab will not have any information about replication status. Once you hit “detect now”, the GPMC contacts all domain controllers in your domain and collects information about Group Policy Object(s) from AD and SYSVOL. It uses a “baseline” domain controller to compare GPO information against GPO information from all other domain controllers. The baseline domain controller defaults to the DC that the GPMC is connected to but can be changed by clicking Change.

The first level of information will show the number of domain controllers that have GPO information “In Synch” with the baseline domain controller and the number of domain controllers that have GPO information that is “In Progress”. Domain controllers that are “In Synch” have all of the same GPO information as the baseline DC. Domain controllers that are “In Progress” do not have all of the same GPO information as the baseline DC. This may mean that there is a problem with GPO replication but it also may mean that replication just has not converged yet. For those DCs that are “In Progress” additional details are provided which explain exactly what is not in sync. The following is the list of reasons a DC can be “In Progress”:

Active Directory
	Accessibility	If the Active Directory service cannot be contacted on a domain controller, this message will be displayed.
	GPO Version	If the GPO version information in AD is different than the baseline domain controller, this message will be displayed and details about the GPOs that are different can be seen by clicking the message.
	Number of GPOs	If the total number of GPOs in AD is different than the baseline domain controller, this message will be displayed and details about the number of GPOs that are different can be seen by clicking the message.
	Created Date	If the created date stored in AD for any GPO is different than the baseline domain controller, this message will be displayed and details about the GPOs with different dates from the baseline DC can be seen by clicking the message.
	Modified Date	If the modified date stored in AD for any GPO is different than the baseline domain controller, this message will be displayed and details about the GPOs with different dates can be seen by clicking the message.
	ACLs	If the Active Directory permissions on any GPO are different than the baseline domain controller, this message will be displayed and details about the GPOs with different permissions can be seen by clicking the message.
File System (SYSVOL)
	Accessibility	If the SYSVOL folder cannot be contacted on a domain controller, this message will be displayed.
	GPO Version	If the GPO version information in the GPT.ini file is different than the baseline domain controller, this message will be displayed and details about the GPOs that are different can be seen by clicking the message.
	Number of GPOs	If the total number of GPOs in SYSVOL is different than the baseline domain controller, this message will be displayed and details about the number of GPOs that are different can be seen by clicking the message.
	GPO Contents	If the content of SYSVOL for any GPO is different than the baseline domain controller, this message will be displayed and details about the GPOs with inconsistent contents can be seen by clicking the message. The content comparison is performed by creating a file hash for all files within each GPO folder on SYSVOL. The hash from the baseline DC is compared to the hash from each DC.
	ACLs	If the SYSVOL permissions on any GPO are different than the baseline domain controller, this message will be displayed and details about the GPOs with different permissions can be seen by clicking the message.

Within the details of each of the errors a link is provided to help you further investigate why the DC is not In Sync.

Group Policy can be very difficult to troubleshoot and we hope that this feature allows you to find and resolve GP related replication issues more quickly.

Another change we made in Windows Server 2012 is in the Resultant Set of Policy reports. In previous versions of Server, you had to look at the results report, and the event log, and the tracing logs to find all the information you needed about why policy did or did not apply. Now, we’ve consolidated most of that information right into the results report to make troubleshooting Group Policy easier.

The biggest change we made is to the Summary section.

Here’s what the summary section used to look like:

And here’s what it looks like now:

As you can see, we summarized important information that was previously difficult to find, like loopback mode, slow link detection, and GPOs with enforce (or have block inheritance enabled)

We also added information to the computer/user details. Now we show how long client side extensions take to process, the last time an extension processed and detailed event log information from the latest pass of policy.

We also added more detail to the report, including sorting information by GPO, showing where the GPOs were linked, and reporting on modifiers like “enforced” or “disabled”.

How you run the GP results report hasn’t changed. If you choose to run it from the GPMC against a remote client, the client needs the following firewall ports opened:

· Remote Event Log Management (NP-In)

· Remote Event Log Management (RPC)

· Remote Event Log Management (RPC_EPMAP)

· Windows Management Instrumentation (WMI-In)

Running it this way against a downlevel client still gets you the new format and most of the new information.

The command line GP results functionality still works. You can run gpresult.exe /h out.html on a client machine to have the report created as out.html. However, this will only get you the new format and information when it’s run on a Windows “8” machine.