Okay.
In this module called Group Policy Processing.
I'm going to dive in and talk a little bit more about how group policy is actually processed in your
Active Directory environment.
So how does group policy do its thing?
Well, it's strictly a pull based operation.
And what I mean by that is that group policy settings are always pulled from GPOs that reside in.
And so as an administrator, you can never really push settings to a client, you can't push a button
or flip a switch and make a setting go out to a client.
The one exception, sort of quasi exception to that is that you can, from a central console, touch
a client and say, pull.
Now, in other words, do an update of group policy now.
But that's as close as you get to a push, and it's really just telling it to do a pull at a specific
time.
So implicit in this kind of pull architecture, which I will make the point that it it's actually a
fairly scalable architecture.
Being able to have the client initiate the pull of group policy settings from group policy objects is
a very ends up being very scalable.
But the sort of implicit in that is this notion that you never really know for sure when a setting will
arrive at a given Windows computer or user.
So group policy, I like to say it's sort of loosely consistent at any given time.
If you push a setting, you know that setting has arrived.
But in group policy land, the pulling could happen when the user is logged on, when the user is logging
on or when the machine is starting up.
It could happen periodically in the background.
And I'm going to talk about all the different phases of group policy processing in the next module.
But the bottom line is you never can guarantee a setting has arrived at a particular time.
And that's kind of one of the challenges of group policy.
Again, you can fudge it by, you know, basically telling a computer or a user to pull settings now
using a command called Update.
And I'll show that in a later module for sure.
So what's the doing, the actual polling?
What is it on the client that's actually doing the polling?
Well, it's something called client side extensions.
I like to refer to those as CCS.
And they're basically a fancy term for an agent on that system.
So essentially, Microsoft has built in this agent infrastructure that is in Windows that is responsible
for pulling group policy settings from GPOs.
So CSC itself is really just a DLP or Dynamic Link library.
And it's called by another operating system component, which I'll refer to as the group policy engine
on a given Windows system.
And each policy area or group of policy areas in some cases provide their own CSC.
So, for example, wireless security is a policy area implemented in group policy, and it has a d l
l called w l l into d l l similar with folder redirection or scripts.
Microsoft ships these in the box and windows for the policy areas that they provide.
And in fact, third parties can build their own cases that just get registered on to the system and
are sort of along for the ride when the group policy engine kicks off.
And it calls the CC's that it needs to call for a given GPO.
So it's fairly extensible in terms of its architecture.
It's just a bunch of these cases that get called when a group policy engine has to do work.
And that's really what the agent of group policy is, is the engine calling all these client side extensions.
So you can find references to all of them in the registry under this registry path that I've shown here.
This is really just for information.
It's not you don't really ever have to touch or manipulate the stuff that you see in these registry
keys directly.
But it's good to know it's an easy place to come and look to see where client side extensions are registered
on a system and what client side extensions are registered.
If you ever have to troubleshoot that now, you can actually control CSC behavior for a given policy
area through group policy itself.
So group policy provides a mechanism to do this.
And essentially what you're doing is in a group policy object in GPIO ed under computer configuration
backslash policies backslash sys backslash group policy policy.
You can think do things like change the slow link behavior of a CSC.
The slow link behavior is something that controls whether the actual the CSC actually does any work
if a slow link between the client and a domain controller is detected.
I'll talk more about slow link detection in a later section.
But essentially you can do you can modify the behavior of CC's based on this, the options within these
group policy areas so you can change whether a CC runs when GPOs haven't changed.
By default.
If GPOs haven't changed since the last processing cycle, a CC won't do any work, but you can force
it to do work at every processing cycle if you decide to do so.
You can also change whether CC can run in the background or not.
There's two kinds of processing foreground and background.
And this essentially allows you to control that.
So let's dive into a demo of some of this.