And you can get the Azure AD Connect software from
the Microsoft Download Center.
So I'm just going to run through a setup,
and this is laying down a wizard interface that we use to configure the service.
It's going to install the AD Sync Windows Service,
it's going to give us a PowerShell module called ADSync,
and it's also going to give us a couple other graphical utilities we
can use to customize the synchronization connection.
Now you could use, if you wanted to, the ADSync PowerShell module to configure,
but I'm going to use the wizard.
And, by the way, see this shortcut, AD Connect,
you would rerun the wizard whenever you want to
reconfigure the service on this machine.
So let's agree to the license terms and continue.
I'm not going to do Express, and I would recommend you not do that either,
because that just assumes that you've got a single forest,
one or more domains, and you're going to synchronize all attributes.
No,
you want to go customize so that you have much
better control over the environment.
Now, by default, Azure AD Connect installs the LocalDB,
which is the smaller, scaled‑back, free SQL Server database engine.
But you can use an existing full fledged SQL Server,
as you can see here,
you can map to an existing service account instead of creating a new one,
so these are just some overrides.
I'm going to click Install to let the service install
the dependencies as it sees fit, installing the Visual C++ Redistributable,
eventually it's going to show LocalDB,
and it's going to register the service account,
and so on, and so forth.
The service, by the way, is called ADSync.
I Think I mentioned that, but just in case I forgot.
Okay, this is an important page,
because it gives us our opportunity to choose Password Hash Synchronization,
Pass‑through authentication or Federation.
I'm going to go with Password Hash Synchronization and click Next.
Now you should know that if you start with,
say, Password Hash Sync, but then later decide that you want to change it,
you can, you just need to rerun the wizard.
And also, when you're using the non‑cloud sync version of Azure AD Connect,
you're going to have to repeat this process on other
machines for "high availability".
Now it says here that we need to authenticate to our Azure
AD Directory as a global administrator.
Now, global administrator is the most powerful RBAC,
or role‑based access control, role in Active Directory,
so it's pretty important.
I'm going to sign in as a delegated administrator account called melissa,
and we'll see if that goes through, if I typed the password correctly.
Yeah, it did.
So now we connect our local Active Directory to Azure.
So we've got DIRECTORY TYPE is just Active Directory,
and if we were in a multi‑forest environment,
we can select it here.
I'm going to choose Add Directory,
and now we have to authenticate with an Enterprise Admin credential.
This would allow Azure AD Connect to create and manage a service account for us.
So what I'll do is authenticate with my Enterprise Admin here,
provide those credentials, and click OK.
So far, so good.
We'll verify, yes, we just want the root domain here.
We'll click Next.
Now, we can see the child domain show up in the list,
our alternate UPN Suffix show up in the list,
and this allows you to verify that you do have a compatible domain in the cloud.
It says here Users will not be able to sign into Azure AD with on‑premises
credentials if the UPN suffix does not match a verified domain.
And you can continue without matching.
In my case, I know that I only want an OU from the root domain,
and that is in fact verified on the Azure side,
and we're using the userPrincipalName attribute to use.
Now, it is possible to use another attribute as the Azure AD username,
like maybe email address, for example, but I like to use userPrincipalName.
Now because we have these other references,
it's not going to actually let me continue unless I affirm that I'm
going to continue without matching every suffix.
That's fine.
This is the main piece here, Domain and OU filtering.
I want to deselect the child domain.
I'm going to select my domains and OUs here,
so I don't want to grab the child domain.
And in the root domain, all I want at this point is the HQ Data Team.
I'm doing a pilot, let's put it that way.
So once we've verified that, let's click Next.
This page allows you, again,
to custom match attributes so that your users are identified only once.
I mean, let's look at it this way, if you had child domains,
you had a tim@timw.info in the root and a tim@child.timw.info,
and you were looking at their sign‑in ultimately being tim@timw.info,
that can definitely run into some problems.
So this screen allows you to customize the anchor attribute to avoid conflicts.
I don't need to do that in this case fortunately.
Let's click Next.
Here's where we can do an even more granular subset of the
objects within that OU that'll be synchronized.
I'm going to synchronize everything.
Let me click Next.
Optional features, this is important,
because if you're going to support password writeback
and self‑service password reset, you need to make sure to tick this box.
Now note that that requires an Azure Active Directory
Premium license for those users, and the group writeback,
again, is something that's only available here in the non‑cloud sync version.
Let's click Next, and it looks like we're ready to rock.
Now, last point I want to mention.
I'm going to leave Start the synchronization process
on so we can actually run the sync.
The staging mode is what you'd want to do on your secondary server,
because if you're not using cloud sync,
you can only have one AD Connect box actually running at a
time because they're not aware of each other.
So on your backup machine,
you would run through the setup here exactly like we did on the primary,
but you would enable staging mode.
And then to take a service in or out of staging mode subsequently,
you'd rerun the wizard and you'd have access to that checkbox again.
That make sense?
So let's go ahead and continue this.
And while we're waiting for this to finish,
I want to show you a couple of the graphical tools that you
get when you install Azure AD Connect.
One is the Synchronization Service.
It's an old‑fashioned application for sure.
And the other is the Synchronization Rules Editor.
Now the Rules Editor, it's got a pretty difficult user interface,
but long story short,
this allows you to create and edit mappings between local Active Directory
schema attributes and Azure Active Directory attributes.
We have to remember that Azure AD is not an LDAP directory.
It's a totally separate thing.
But if you have extended your local schema,
you may have user properties that you do want synchronized into the cloud,
and you can extend the Azure AD attribute set to a degree.
Check the exercise files if you want more info on that.
So that's the Sync Rules Editor.
The Synchronization Service Manager allows you to see a record of
every synchronization option as it happens,
and you can just get more detailed information on the
connection between your local AD and Azure AD.
And you can also do things like forcing a synchronization to take place.
You just right‑click and choose Run, and it'll run a synchronization for you.
And then lastly, you've got a PowerShell module.
Unfortunately,
the PowerShell support in Azure AD Sync doesn't work with PowerShell Core,
so it's PowerShell Desktop only or PowerShell version 5.
If I do a get‑command in the module ADSync,
assuming that it's been installed, yes, it looks like it has,
there's quite a few commands in there for sure.
I don't think you're going to see any of these commands on your AZ‑800 exam,
but a common one is Get‑ADSyncScheduler.
This will give you your default replication interval.
Now, understand that outside of password writeback and group writeback,
this is a one‑way scheduled sync between local Active Directory and Azure AD,
and the default interval is every 30 minutes.
The Initial sync will likely be the biggest,
highest impact, then subsequent syncs will just be delta or changes.
Note that Get‑ADSyncScheduler also lets you know if
StagingMode is enabled on that box.
Fun fact, or not so fun fact,
is this ADSync PowerShell module is not available in the PowerShell Gallery.
You have to install the Azure AD Connect software to get it.
It looks like we're good to go here,
so let's check by coming up into our directory.
Let's go to our Users list, and to compare against local Active Directory,
we expect to see Brett Gordon and Betty Remy.
So let me do a search in my Users list for Brett, and there is Brett right here.
Note that his User principal name matches his local Active Directory name,
and we can see Directory synced is set to Yes.
If we do a search for Betty,
Betty is here, so now we can populate Betty into Azure
AD groups to our heart's content.
We can give Betty privileges on our cloud apps,
and we can give her role‑based access control assignments to our Azure subscription resources as well.