Now I want to finish up this module by talking about performance and group policy performance in particular.
Remember that I showed in the Group Policy Results Troubleshooting section that you can see how long
group policy processing was taking for a given computer or user.
Or actually you could see the time elapsed for each client side extension.
So you could see very specifically what time group policy was spending doing its thing for computers
and users.
And I think it's important to note that sometimes group policy gets blamed for a lot of performance
issues when it's maybe not the cause of them.
But there are some things that group policy legitimately can impact, and those are the things that
I want to talk about.
And there are some things you can control and some things you can't control, some things that the OS
does and some things that you do with your design.
So I want to talk about those design based things first.
The very first thing is the use of scripts.
And again, I've, I talked about this in the scripts module, but.
Group policy based scripts can be problematic.
They can take a long time to run.
If you don't have good testing and logic in them, they can potentially hang and cause up to 10 minutes
of delay if they're hanging, which is not obviously great for the user experience.
And they're just sort of problematic because most folks don't implement them with sufficient instrumentation
and logic to prevent them from spending a lot of time doing work they don't need to do.
So if you can avoid using scripts in favor of things like GP preferences, I always recommend that the
second thing are using expensive what I call expensive client side extensions.
And the two examples that I like to use are file and registry security.
These are under the computer configuration, windows settings, security settings, and this is where
you can set file system and registry security.
And again, this can run every 16 hours by default because it's part of the security extension.
It can really churn through disk.
I mentioned this earlier.
I tend to do avoid doing file and registry security setting and group policy.
Use a script that runs once and gets done with it or runs once every once in a while.
Perfectly reasonable to take that approach.
I don't think it's worth doing it in group policy.
Another one is you end up having too many GPOs being processed for a given user or computer.
This can happen when you have way too many functional GPOs with just a couple settings in them and the
overhead of having to evaluate all those GPOs figuring out which apply and then processing them can
become a significant burden on group policy processing.
So always think about, you know, as you're creating new GPOs or as you're linking GPOs to existing
add hierarchies, how many is too many?
And I would say that if you a given user or computer is processing more than ten or 20 GPOs, you have
to start in think, well, maybe I can combine and consolidate some of these the grouping of client
side extensions.
This kind of hearkens back to what I just talked about with synchronous and asynchronous extensions.
If you can keep the synchronous extensions folder redirection software installation and group policy
preferences drive mappings out of the GPOs that have other settings in them.
So on their own, then you can minimize the impact when you make changes to those GPOs of having those
synchronous extension for of foreground refresh.
And then finally expensive WMI filters.
What do I mean by expensive?
Well, essentially, some WMI filters can take a long time to evaluate.
I wrote a blog post a couple of years ago about a WMI class called Win32 Underscore Product, which
was ostensibly designed to basically query all of the installed applications on a system.
But it had some really nasty side effects that caused it to really turn through lots of CPU and memory
when it was running, and it would take literally minutes to run.
So this is not a WMI query that you're going to want to use, and there are others that can take a while
based on that.
There are WMI queries you can do to determine if a particular file is on the file system.
And you know, that may not be the smartest thing to use WMI for.
I have a little tool if you go to Google.com, which is my website.
There's a free tool called the WMI filter validator.
And one of the things that it does is it validates to see if a filter will evaluate to true or false
on a given system.
But it will also times the query to see how long it takes.
And you can use that to sort of as a thumbnail to sort of guide you on whether a query is too expensive.
Let's then talk about those features that have an impact on group policy performance.
Microsoft introduced this concept of group policy caching in Windows 8.1.
It sounds really good, but it actually doesn't do much.
It only runs when one of the synchronous seasons requires a synchronous foreground.
Flash like folder redirection or software installation are the only two left on Windows 8.1 that require
a synchronous foreground refresh.
They fixed drive mapping so it no longer requires that.
So the group policy caching only kicks in when one of those two extensions is required a synchronous
foreground refresh.
So if you're using a lot of folder redirection in software installation, this may benefit you.
But otherwise you probably will never see the effect of this.
Another thing that they added in Windows 8.0 is called Fast Startup.
And this is a pretty much unrelated to feature that has a impact.
So it allows Windows to start from a shutdown more quickly.
It's essentially hibernating the OS.
When you turn off a machine normally and it's enabled by default, it's in effect whenever the user
selects shut down.
But group policy gets bypassed when the machine comes back up.
Because Fast Startup essentially bypasses the computer boot up processing.
So if you have startup scripts, they don't run.
If you have security settings, they don't run.
Whatever poor computer settings you have, don't run.
So while it's a great benefit for the user group, policy gets a little confused and it does require
the user to do an actual restart in order for that per computer policy to run.
So they have to do a restart rather than a shutdown.
Now you can turn this off using this admin template setting that I list here, and I recommend that
if you're in a critical environment where you need that computer settings, those computer settings
to be refreshing in the foreground, then this is the policy that you're going to want to enable.
And then finally, Microsoft added this so-called log on script delay and Windows 8.1 to help reduce
the contention that happens that user log on time when there's a bunch of stuff going on, including
log on scripts.
So what happens is they actually delay the execution of log on scripts by up to 5 minutes.
That's the default.
So the user logs on and then 5 minutes later they're log on, scripts run.
Well, this can really mess you up if you're relying on log on scripts for drive mapping.
But it does reduce that contention at log on time.
You can actually turn this off.
There's a policy under computer configuration policies, admin template system, group policy that lets
you turn off this delay in Windows 8.1 and Server 2016.
But essentially it's there and on by default.
So it's good to know about that.