I'm starting this demonstration on my Windows 11 administrative workstation,
and what I want to do actually is first start by opening
the run prompt and typing gpedit.msc.
This is a shortcut that opens the MMC console for the local systems, and this
applies to a Windows Server, as well as Windows Client,
the local Group Policy.
So this is just to remind you that Group Policy is built
in natively into any Windows system,
whether it's part of a workgroup or an Active Directory domain.
And we have, as I mentioned before, the two sides of the fence,
computer configuration, which maps to the registry hive HKEY_LOCAL_MACHINE,
and the user configuration, which, depending on the setting,
normally it's going to be HKEY_CURRENT_USER,
the currently logged on user.
And we have within each subdivision a Software Settings branch,
a Windows Settings branch, and Administrative Templates.
The thing about Administrative Templates is that this is where you
can extend the capabilities of your Group Policy.
Notice here, we can right‑click Administrative Templates.
These are what are called ADMX files.
So, for instance,
if you want to apply Group Policy to the Office Suite or some
third‑party product, if they offer an Administrative Template,
it's pretty easy to incorporate that into Group Policy.
So that's a wonderful extensibility.
Now, why would you choose to do a setting,
like an Administrative Template, under Computer
Configuration rather than User? Well,
it depends. Computer would be affecting all users on that
system, whereas User Configuration normally would affect
just the currently signed‑in user, you see what I mean?
So you want to think about the scope of policy. Now, I can't disable
Computer or User Settings in the local Group Policy Editor,
but if we do a run and do gpmc.msc,
this opens the domain Group Policy Management console.
And again,
the reason I'm able to get to that on this Windows 11 workstation is
that I've installed the remote server administration tools, or RSAT
tools. Now we can see here we've got my forest,
we've got my domain, and we can Show Domains, and we can browse to the
child, and we can work across our domain tree if we want to.
We have the Sites level, where we can apply Group Policy
objects to our Active Directory sites.
We have the ability to model Group Policy.
There's a wizard, if you right‑click here, and you can step through,
and this is simulating a policy deployment to see how those settings
in a new GPO you've created might affect users, groups, etc.,
depending upon where they are.
And then we have the Graphical Group Policy Results wizard,
Resultant Set of Policy, or RSOP, as it's also called.
We have within our domain structure the Default Domain Policy.
This is the built‑in domain‑scoped policy.
Now, it's an exam alert.
You want to see that in order for a policy to apply to users in your
domain, those users are going to have to have read permissions to the
policy and the policy is going to need to be linked. Notice that we can
right‑click to enable or disable a Group Policy link, and the default
domain is going to affect the entire domain by default, and read
authenticated users means that all domain users are going to be affected
by this system.
Note that domain admins and enterprise admins have custom permissions.
Basically, the policy will not apply to
administrators, but you can override that.
It depends.
Now, in domain controllers, we have Default Domain Controllers policy. And
this again is going to be policy settings that are scoped to the enterprise
domain controllers identity, and this is a good place to enable auditing, for
example, on those domain controllers.
Let me show you. I'll right‑click and choose Edit, and then to get
to the auditing, password, and security settings, we can go under
Computer Configuration, Policies, Windows Settings,
Security Settings, and we have our Account Policies,
Local Policies,
Event Log. Under Account Policies, we have Password, Account Lockout, and
Kerberos Policy. And for Local Policies, we have our Audit Policy. And so for
each of these policies, we can choose to define them, and in this case, are
you going to audit account logon events that are successful and failed, or
just failed, for example? Notice that the graphical interface here does have a
really nice explainer.
I want to draw your attention to that.
All right,
let me close out of here and come to the Default Domain Policy and edit that.
This is a good place to scope your security and password policies,
as I mentioned before. If we go to Policies, Windows Settings,
Security Settings, Account Policies, Password Policy,
we can see here we've got maximum password age.
That's where you would enforce changing a password
if that's going to be your thing.
Don't want to explain each of these.
We don't really need to.
You could search the Pluralsight library.
We have plenty of training on Group Policy.
But again,
I want you to see, the explainer will give you some
suggestions, that if you put in 0 for this,
if you define it and put in 0 days,
then the passwords will not expire. And you may be on board with that idea,
that it's better to enforce a stronger password policy and have the user keep
that strong password than force them to change the password regularly and then
have a weaker password over the time net.
Now, you see here, we've got an OU that I've created called Domain Workstations.
Let me actually go to Active Directory Users and Computers, and
I'll show you that I have my CLI, that's this Windows 11 domain
member box, scoped in this new OU.
And watch what happens, if I move this computer, and the
same thing applies if I tried to move a user account, you
get a warning here that says,
are you sure you want to do this because by moving this computer account,
I'm going to be taking it out of scope for any GPO or GPOs
that would be linked to domain workstations.
And instead, cli1 would pick up any linked GPOs that are on my test OU. So
this is just for you to think about, rather, before you arbitrarily start
moving user group and computer accounts around, that this will affect Group
Policy processing on those machines for sure.
Now, you might want to think, domain admins,
of course, they're going to have full ability to author and edit Group Policy.
What about delegated administration for GPO Management?
As it happens, if we go to the users container, this is an
exam alert, I want you to be aware of the built‑in Group
Policy Creator Owners group.
As you can see,
this is a global security group that says members in this
group can modify Group Policy for the domain.
So if the exam asks you about delegating the ability to author
and manage Group Policy objects in the domain,
a convenient thing to do is populate that domain user, or group, as the case may be, in the Group Policy Creator Owners global group.