Let's look at some of the designs that we just talked about and see how they might play into a group
policy deployment.
So I've got actually both designs that I just showed you implemented in this ad tree for the sake of
example.
I've got a sales view and a marketing view, and they both have sort of the same structure where they
have subclass for groups, machines and users.
Under machines you'll see desktops, laptops, servers and VDI slash ideas.
And you'll notice that the VDI slash idea so you has black inherited said as we mentioned in the kiosk
scenario module that this is a good option.
If you want to segregate your VDI or RDC servers or workstations, you can put them in there so you
can set block inheritance and it simplifies the management of group policy for those devices.
Now again, I've got different form factors and I could have underneath the marketing, oh, you in
the machines or you I can have a GPO that sets policy for all machines.
Sort of any common policy that may be applied across all computer objects can be set at this machines
level.
Now, the only downside to this kind of business unit approach is that let's say I have some GPO settings
that apply to all machines across the organization.
Well, that GPIO that I define has to be linked both here at this machines level and also down here
under the sales.
Oh, you structure at the machines level.
The alternative, of course, is the first design I talked about, which is more of object type based
and that's represented by this machines and people top level all use and the machines top level.
Oyo has a similar structure to the marketing and sales oh use in that each of the different types of
machines is broken out by form, factor by function.
And then I can apply.
If all machine accounts in the domain are under the structure, I can very easily apply a GPIO or link
a GPIO to this level that has computer policy that applies to all systems regardless of form factor.
Then I could come down here at the desktop level, apply policy to desktop based machines.
That's different from laptop machines.
And then for sure, servers are going to have a different set of policy.
And so I can apply that at this level specific to servers and similarly with the VDI and RDC systems.
So this allows me a little bit more flexibility in terms of targeting GPOs.
I don't have to do as much linking and I could also have further differentiations underneath, for example,
under the servers.
Oh, you I can have observers and I can have web servers.
And so I could be applying policy at these sub levels as well.
Now on the people side with this structure, it's a little bit more challenging.
If all the user accounts in the domain are under the people or you, I probably will have the need and
desire to be able to subdivided further underneath people.
So for example, interactive users here in service accounts or I might even go so far as to have different
business units, people accounts under here.
So I might have, for example, a sales IOU for the sales users and a marketing oh, you for the marketing
users.
So I have some flexibility here.
This still allows me to set again policy that applies to all users linked here at this people or you
and then policy that is specific to marketing and sales down below here.
So both of those approaches are completely reasonable and depending on your business needs will drive
sort of which direction you go with this.
I tend to like just in terms of my own personal preference, I tend to like this machines and people
at the top level approach because I like the idea of being able to link in a single place to a place
sort of global policy and then be able to subdivide and segregate other policy based on sub AWAs.
Now the one thing you don't want to do is get too deep in your own use structure.
It becomes a lot more difficult to manage and you really just don't want to have, you know, five or
six levels deep on subdivisions.
You really only want to subdivide sort of to meet the needs of group policy and your ad administration.
So balance those two.
And if you find yourself having to create too many subplots to, for example, segregate group policy,
you might then start looking at filtering.
So doing security group filtering or you know, for example, WMI filtering and a good example of that
might be so within the sales, oh, you under people, you might have sales managers and sales users.
We don't really want to have to create an oh you called users and an all you called managers because
people are going to move around shift around and you don't want to have to be moving people around no
use in order to accommodate group policy.
So that's a scenario where you can use security groups and probably get the job done more efficiently.
I would say that as a rule of thumb, if you have to move objects between or use to meet your group
policy targeting goals, then you're probably taking the wrong approach and should rethink using, for
example, security group filtering or WMI filtering to accomplish those goals.
So that's just kind of a high level overview.
There's obviously lots of different design approaches you can take with Active Directory.
I've seen people take design approaches where under the machines or you they'll have different OS version
or use.
So for example, Windows ten might be underneath the machine.
So you instead of just this form factor type it tend to avoid OS version approaches because OS versions
change as machines get upgraded.
And again, if you're having to move objects between, oh, use to accommodate your group policy or
design goals, then maybe you need to rethink it.
I like the notion of using WMI filters for object version or for I'm sorry for OS version testing.
Very tried and true method.
So having a WMI filter that applies to all Windows ten machines linked to the GPOs if you want to target
in the desktop.
So you only.
The window, ten machines.
You can use a WMC filter for that.
And it's a lot more efficient and certainly a lot easier to maintain than creating new OS version or
use.
So again, lots of approaches, but there are some that have sort of shove shaken out over time that
have proven to be more sort of efficient than others.