Next,
we'll turn our attention to Group Policy in Azure AD Domain
Services. Well, Tim, where's the content?
The thing with Azure AD Domain Services in Group Policy is there's
really no difference from local Active Directory Domain Services,
and you'll see that in the next demo.
That's really the surprise/non‑surprise.
So what I want to do is roll up some Group Policy‑proven practices for you to
think about. Guidance nowadays tends to be using your built‑in Default Domain
Policy only for global account policies. Makes sense. Password, policies, and
account lockout, and that kind of stuff.
The built‑in Default Domain Controllers Policy,
it's recommended you just configure auditing for
your domain controllers in there.
You'll want to definitely think about and optimize
your organizational unit structure.
Why?
Because you want to scope your GPOs granularly at the OU
level. By targeting at the OU, it's going to dramatically
simplify your troubleshooting.
Trust me on that. I would recommend you avoid GPO blocking, enforcing, and
disabling policies, not only for ease of troubleshooting,
but you want to also think about simplicity in terms of
optimizing logon. The longer the logon, it may be that you've
got a whole bunch of Group Policies enabled,
some of which are disabled, some are enabled, and you've got blocking and
enforcement, and the more work you're forcing your domain controllers to
do to resolve all of these Group Policies,
you know who's paying the price for that? Whoever is signing on to that
station, or you're biting your nails waiting for your member servers to come
back up so they can start delivering services again.
So you want to think about sign‑in speed for sure.
To that point,
you can selectively disable user or computer configurations, and again,
this is going to have a positive impact on GPO processing and logons.
If you're delivering computer settings in a GPO,
you can disable the whole user configuration side of the GPO, and vice
versa. Unless you need both user and computer settings,
disable the one you don't need.
And lastly,
the pattern nowadays, and this goes throughout all of software development
if you're familiar with the microservices architecture, is to avoid
monolithic GPOs that try to do everything. Again,
the maintainability of those, on one hand,
you might think you're being simple, you know,
keep it simple.
I just have one big old custom GPO. Though, if there's a problem,
I know that it's in the one GPO, or chances are it's in the one
GPO. And you know what, that may be true, but then you're going
to have to look through that pile of settings to try to isolate
what the problem is.
If you've created a number of granular GPOs, you can
test by disabling those one by one,
doing a split half approach, and then when the problem occurs,
you know that the most recent GPO that is enabled is the problem.
In fact, I kind of explained that backwards. The split half approach would be,
for instance, to disable them all and enable Group Policies one at a time.
And when you get the problem recurred,
at least I know that it's from this most recently applied Group Policy object. Now, let's do that second demo.