First published on TECHNET on Oct 22, 2018
Hi everyone! Graeme Bray with you again today to talk about an age old discussion point. Does Group Policy process quicker if you disable the User/Computer sections of a specific policy?
We're going to walk through my lab setup, grabbing the policies, comparing them, and then confirming that I actually did disable the policy section.
Without further ado… Continue to how I set up my lab for this test.
Lab Setup
- Two Domain Controllers, in distinct separate sites, with appropriate subnets for my test server
- Test server running Windows Server 2012 R2, fully patched (as of September 2018).
- 1 vCPU (Added: Oct 22, 2018)
- 1 GB RAM
- 18 Group Policies configured, some with WMI Filters, others with Group Policy Preferences, none with any specific Client Side Extension organization in mind. Also included is the Microsoft Security Baselines. All are currently configured for "GPO Status" of Enabled.
-
GPSVC Debug Logging turned on for system SERVER12 .
- New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name Diagnostics -ItemType Directory
- New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics' -Name GPSvcDebugLevel -PropertyType DWord -Value 0x30002 -Force
- New-Item -Path C:\windows\debug\usermode -ItemType Directory | Out-Null
These three PowerShell commands will create the Registry Key, the Dword Value, and the Folder necessary for the actual log.
Test #1 - All Policies Enabled
After setting up my lab, I ran a GPUpdate /force. I was not updating any policies, so the settings themselves didn't change. I didn't have many user settings configured, so I wasn't too terribly concerned about those. I wanted to focus specifically on the computer policy processing time. This tends to be the longest, due to any number of factors including Security Policies, WMI Filters targeting specific OS versions, and
I did my GPUpdate /force 3 times. The first test, from the beginning of processing at .031 seconds, finished processing Local Group Policy at .640 Seconds. 
This seems like a long time. If we adjust the time based on some things that BOTH tests will have to encompass, we can shorten the time from .609 down to something easier to get a median between my 3 tests.
We want to skip to the initial "Checking Access to…" entry. In the section of "Searching for Site Policies" we are doing bandwidth checks and other domain/forest information queries.
On policy GUID 244F038B-8372-494A-AE7D-BBCA51A79273, the reason it is slightly slower is due to a WMI Filter check to see if it is Windows Server 2016. 
The total time in the first test to process and get every policy is 0.265 seconds. Using the same methodology for the other two "Fully Enabled" tests, the times came to:
| Number | Time (seconds) |
| Test #1 | 0.265 |
| Test #2 | 0.25 |
| Test #3 | 0.172 |
| Average | 0.229 |
Test #2 - All Policies "User Configuration Disabled"
Without going into the same detail, the same methodology was used with all policies having "User Configuration Disabled". Times are below, with a couple screenshots to prove I'm not making up the data.
| Number | Time (seconds) |
| Test #1 | 0.234 |
| Test #2 | 0.265 |
| Test #3 | 0.156 |
| Average | 0.218 |
As you can see, the difference is a grand total of 11 hundredths of a second.
Test #3 - Policies Half and Half (Randomly Chosen)
Finally, I picked half of my policies and disabled the User configuration section. Results are below:
| Number | Time (seconds) |
| Test #1 | 0.297 |
| Test #2 | 0.25 |
| Test #3 | 0.203 |
| Average | 0.25 |
But But… How can you prove what you did?
I know, I see it coming… How do I know in your logs that a User section of the policy was disabled?
Great question, you can see details on the Flags when Group Policy Debug Logging is enabled on this MSDN article.
See my screenshot below, with "Found flags of: ##" 
Tl;dr:
Flag value 0 means Computer/User Enabled
Flag value 1 means User Disabled
Flag value 2 means Computer Disabled
Flag value 3 means policy Disabled.
Now, the question is, what does this mean? For years we've all heard, told, and explained that we should disable parts of a GPO that are not in use, especially for performance reasons. From this (somewhat) statistical approach, you can see that there are no obvious benefits to disabling any specific side of a policy, if not in use. The Group Policy engine still needs to query Active Directory to determine each policy that is linked to the Site, Domain, and OU. It still needs to determine what is in the policy, GP Extension wise, and get all of the information about the policy itself.
What should I do?
This is purely a decision you need to make. Some customers will continue to disable sides of the policy based on management and preference. Others will continue to forget that it exists. The choice is yours to make, but please stop proliferating the notion that disabling User/Computer sections within a GPO improves performance.
For what it's worth, don't combine User and Computer policies into the same GPO. Split them out, link them to the appropriate OU's, and for Pete's sake, please avoid loopback whenever possible.
Hopefully this article has helped detail reasons why it's not that important to disable portions of a GPO. The end result is at most, 11 hundredths of a second. Nearly instantaneous and within any margin of error, depending on environment.
Thanks for reading
Graeme