Now I'm going to talk about some group policy processing mechanics.
So essentially, let's just dig in here.
I want to kind of lay out some rules around how group policy processing actually works, because I've
seen a lot of misinformation about this over the years.
And I think it's important to understand what you can and can't do with group policy.
In the presence or absence of things like the network or access to domain controllers.
So the first note I will make here is that group policy processing only, only, only runs in the presence
of a domain controller.
In other words, if the client cannot find a domain controller in the domain that it belongs to, it
will simply not process policy.
So if no DC is found, the engine just stops, throws up its hands and say, I'm sorry, I can't do
any work.
And no changes are made on the target system.
And I think this is kind of an important point, because I've seen some people suggest that a way of
overriding policy that's being delivered from your domain administrator.
Is to simply disconnect the client from the domain or from the network, make a change to the local
GPO, and then the change will take effect on the system.
And the reality is, that's simply not true, that even if you make a change to the local GPO, the
local GPO is part of the normal group policy processing cycle.
And it will simply just be ignored.
Any change that you make will be ignored by the client until the main controller gets into becomes available.
And then, of course, if you try to make a change to the local GPO, that's circumventing a domain
based GPO because of the LSW processing order, your local GPO change will simply get overridden.
So it's kind of a key point to remember that that no group policy processing at all, local or domain
based, will happen if there's no domain controller available.
Now, in terms of finding a DC group policy, the group policy engine and group policy processing goes
through the normal ADC locator process to find a DC in the same site.
So it will always try to find a DC close to the client.
And this is a good thing because as it's downloading policy information from AD and Cisco, you want
that to be as close to the client as possible to have quick processing times.
And then contrary to some other popular beliefs that I've seen, group policy is not really cached at
all for offline processing.
In other words, there's no such thing as group policy running while a DC is not present.
And there is actually in Windows eight and above a group policy cache that was implemented.
But it is not this.
It is not for offline processing.
It really is to simply speed up group policy processing in the case of a synchronous foreground processing
cycle.
So essentially, without getting into too many gory details, the way that works is on a Windows eight
or 8.1 machine.
If the client detects that it's doing a synchronous foreground processing cycle, for example, you
have folder redirection or software installation policy that applies to the computer or the user.
Then group policy will have previously cached the GPOs that apply to it and it will use those policy
files out of the cache to process policy, to save time, to sort of make up for the fact that it's
a synchronous processing cycle.
But again, the cache is only called when synchronous processing is detected.
So it's not quite the same as like a real cash.
Another kind of behavioral change the group policy will go through is if a slow link has been detected
between the client and the DC.
Now by default that slow link is defined as less than 500 kilobits per second, which is pretty darn
slow in this day and age.
But if that kind of a link is detected and the test is that when the client is doing its DC discovery,
it'll do a series of build up requests at the domain controller that it finds.
And if those get calculated related out to a response time that equates to less than 500 kilobits per
second, then it will set a flag in the engine that says, Hey, this is a slow link.
If it's a slow link, then some policy areas will not run.
So admin templates runs over a slow link and most of the security policy runs over a slow link.
But there are definitely areas like software, installation, folder redirection and scripts that do
not run over a slow link by default.
Now you can modify those behaviors.
And also the slow link threshold itself.
That 500 kilobits per second value.
Within this policy area.
Under computer configuration policies.
Admin templates.
System.
Group policy.
But by default, those policy areas will not run over a slow link.
And keep in mind that this goes back to the days where 500 kilobits per second was actually pretty darn
fast.
And in the case of something like software installation, did you really want Microsoft Office installing
over a very slow link?
Probably not.
So I don't see these getting hit in this day and age very often.
But they are available and it is good to know that in the case of a slow link, for whatever reason,
you know, you've got a slow link between your client and your DC.
You may not see these policy areas getting processed successfully.
Now group policy over VPN is another I won't call it a fringe case because of a lot of people use VPNs,
but it's problematic to some degree for group policy.
So if you think about foreground computer processing, which is it machine start up, that's not going
to work unless ADC is available.
As I said, and a DC is not going to be available unless the VPN client is pinned up at the time that
the machine is booting, which is not usually the case unless you've got an external VPN connection
between wherever that client is in your DC.
So that's one issue.
The other issue is that on foreground user processing, which is that user log on, this is not going
to work either if the VPN is not already pinned up because the DC again has to be available for user
processing to complete.
So if you have that option, you've defined a VPN connection in your Windows system.
You have that option, that tick box at the log on screen that says, you know, connect to my VPN,
ID, log on, then you will get group policy processing for the user.
Foreground processing for the user happening.
And again, group policy processing in the background has no issues if the VPN is connected.
So you know, you're booted up, you're logged in, your VPN is connected and that 90 minute plus 30
minute random offset happens and background processing kicks off.
Well, that's going to run just fine if the vpn's installed.
But again, there are some policy areas like software installation and folder redirection that simply
aren't going to run in the background.
And then finally, some policy area processing differences.
Again, I mentioned some policy areas won't run over slow links like software, installation folder,
redirection scripts.
Some policy areas don't run in the background folder redirection software installation and prior to
Windows 8.1, GP preferences, drive mappings and all policy areas won't process unless something has
changed in that GPO list.
Then again, you can override this on a per year basis using that policy area that I mentioned in the
previous slide.
So just some oddities about group policy processing behavior that are important to note to ensure if
that policy's getting delivered the way you expect.