In this demonstration, we'll set up Azure AD Connect synchronization.
I'm on my rootdc1 domain controller and the timw.info domain.
Now in the real world,
I would install Azure AD Connect, not necessarily on
domain controllers, but on member servers,
but it is supported to put the service on a domain controller.
Now there's some prerequisites that are also exam
alerts that we want to take a look at.
You want to make sure in your Azure subscription,
particularly in your Azure Active Directory tenant,
that you've configured your business domain names.
When you start your subscription,
you name your Active Directory with a globally unique DNS name, but that's
not going to work when you're synchronizing from on‑prem.
So I verified ownership of my timw.info domain.
You verify ownership by creating a resource record in your
zone, and Azure will perform a lookup.
And if the record exists, then you've demonstrated you own that zone.
Also,
if I go to the Users page and show you if we click New user to
create a new user directly in our tenant,
the actual sign‑in name is a User Principal Name format.
So you want to do everything you can to make sure that your
local Active Directory users have not only a UPN suffix that
matches the domain in Azure, but the best case scenario is that the username,
the UPN, matches the user's SMTP email address. This way, when you give your
users instructions for signing into your Azure AD cloud apps,
you can just tell them to use their email address. Now you know and I
know it's not an email address, but they don't need to know that, and
then the password that they normally use at work,
in other words,
their local password, okay? Now what if your local Active
Directory is not already named as such?
Fortunately, as you can see in my Domains and Trusts console,
my root domain is already called timw.info.
But what if you've got a multi‑domain environment or maybe even
a multi‑forest environment? You can add alternate UPN suffixes
and then update those local users.
What we can do in the Active Directory Domains and Trusts
console is select the root node and go to Properties, and
we can add that suffix in.
For example,
I'm going to add pluralsight.com. Now that's bogus, of course. I'm not
going to actually go forward with that, but notice that Active
Directory had no problem with my doing that.
And now what I would want to do is for the users that I want to
replicate into the cloud, I'm, by the way,
not going to replicate all accounts.
What I recommend is that you do this migration,
although it's not a migration. To do this synchronization,
let's put it that way, on an OU by OU basis.
So I'm just going to replicate my HQ Data Team, which consists of two users and
some groups. Now if we did need to update the UPN suffix for a user, we can go
to their account page, and the alternate UPN suffix will show up here under
User logon name. It's not showing up now because I'll have to restart the
computer for that change to happen.
But after I restart it, I would have the pluralsight.com entry here as well.
Now in the real world, I would also use PowerShell to do that update in bulk.
I wouldn't do it clicking, clicky, click through the GUI. Another
exam alert is understanding just what IdFix is.
IdFix is a click‑once streaming application.
It's open sourced now at GitHub. And what it allows you to do is scan
your local forest environment. First, you can go to Settings to
determine the scope of what you're looking at.
And by default, it will look at the current domain in the current forest.
You can provide alternate credentials.
And then when you have it run a check,
it will give you a run down of any possible errors or
synchronization errors that it finds, duplicate values and so on.
It looks like it's actually found some here.
And the idea is that you would then track those down and then requery until
your problems are fixed, or you can actually take whatever action IdFix
recommends and allow it to make the change for you. But IdFix is something
that you'll want to work through prior to doing your first synchronization to
help you avoid sync errors. Now you might think, well, Tim, why didn't you fix
those issues that you saw?
Part of this is that I want to show what happens if
something goes wrong because one of the exam objectives is
understanding Azure AD Connect Health.
Now I mentioned that in Azure AD, the current vanguard,
so to speak, with directory synchronization is a cloud‑based model.
So back in the portal, if we come down to Azure AD
Connect, we see Manage Azure AD cloud sync.
So Microsoft really kind of leads you down that road. And long story short,
what this is all about is you create one or more
configurations, as they're called,
where you tap into a local Active Directory domain, and there's
not a support for passthrough or federation,
so you're pretty much doing password hash sync. And you'll download a
smaller agent than from what we're going to do today, and then you
configure your scope of replication. And again,
long story short,
it's meant to just be a cloud‑hosted way to set up
Azure AD account synchronization.
That's about all I want to say about that because like I said, exam
AZ‑800 assumes that we're not using Azure AD cloud sync, but we've gone and downloaded the Azure AD Connect MSI.