In this module.
What I want to do is talk about group policy deployment, sort of this is more of the maybe the theoretical
or the logical around all the stuff we've been talking about so far, which is to say you've got the
basic skills about how to manage group policy, how to troubleshoot group policy.
Now I want to talk about how to deploy it in real world environments.
And I think the key here is that it's always a balancing act between designing a group policy friendly
Active Directory and meeting the needs of your aid management.
The challenge here is that aid design is often driven by different goals than group policy design.
What you have already being driven by the security needs of the organization, the needs to delegate
administration to subgroups of administrators, and all the applications that use aid driving you in
one direction.
I'll tell I'll give you a perfect example.
There's a lot of directory enabled applications that use LDAP and a lot of those applications are not
Windows applications, they're Unix or Linux or Java or some other kind of platform.
And oftentimes they only use aid for authentication and they only search on a single container.
Within adds, you provide a base distinguished name and given that they benefit highly from having all
of your users in a single flat view, that's not a great approach from a group policy perspective,
because then you get into the situation where if you want to distinguish policy by a particular set
of users, you then have to rely heavily on users being in particular groups and using security group
filtering.
In that scenario, you've got a design being at cross-purposes to group policy design.
Group policy is really about ease of targeting, the ability to differentiate by platform, for example,
server versus workstation or desktop versus laptop, and then sometimes also by delegation.
As I showed in an earlier module, you can delegate administration of group policy, for example, and
also admin.
So sometimes the driver will send you in a particular direction in terms of your aid design.
Let's look at some ad designs that are maybe friendly, if you will.
This particular design starts out with a top level of use based on object type.
So we've got machines, we've got people and we've got groups.
And then the sub AWAs are distinguished by either their role.
For example, under people we have interactive users, we have service accounts or they're basically
they're type or form factor which is under machines.
We have laptops, desktops, servers, VDI and RDA systems and each of those have their own view that
allow you to sort of more easily distinguish and manage group policy based on other factors other than
just a flat or you structure.
Another approach is to take the more geographic or business unit approach or your top level or use are
based on either geography, east or west or department or business unit, sales market, etc. And underneath
each of those you have sort of the secondary structure that's identical, that has users computers.
And under each of those users and computers you then have going back to our previous design or previous
diagram, the sub was based on role or form factor.
So you're essentially adding a layer that is the business unit or the geographic distinction and allowing
you to sort of further differentiate and target from a group policy perspective.
So that's a different approach that allows you to distinguish based on business function in addition
to things like form factor and user type.
Let's kind of poke around in on our test system and look at how that might work.