Does Disabling User/Computer GPO Settings Make Processing Quicker?



AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at (hosted at Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either as you do today, or at our new site Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!


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: ##”


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