Good day, Cloud Gurus, and congratulations
on making it to the end of this section.
It's been a pleasure to work through this section with you.
Let's take a look at some of the most important points
to remember from this section.
One area of confusion I often see for Azure Administrators,
Identity Administrators, and Windows Administrators,
is around Identity sync.
Now, we know that we can sync
our Active Directory Domain Services domains
to Azure AD using Azure AD connect,
and if we implement Azure AD Domain Services,
we can sync Azure AD to Azure AD Domain Services.
Let's summarize at a high level how this sync works.
Firstly, let's take a look
at Active Directory Domain Services Users.
These users can be synced from AD DS to Azure AD,
and from Azure AD to Azure AD Domain Services.
But Azure AD Users cannot be synced back
to Active Directory Domain Services.
And similarly, Azure AD Domain Services Users
cannot be synced back to Azure AD.
Now, Active Directory Domain Services Security Groups
can be synchronized to Azure AD
where they are created as Azure AD Security Groups.
And Azure AD Security Groups can be synced
to Azure AD Domain Services, where they are created
as Azure AD Domain Services Security Groups.
But there's no sync back of security groups
from Azure AD Domain Services to Azure AD,
or from Azure AD back to Active Directory Domain Services.
You can also create Microsoft 365 Groups
in Azure Active Directory,
And these groups can be written back
to Active Directory Domain Services with group write back.
If you have exchange installed on-premises,
and you have Azure AD Premium,
they will appear as Distribution Groups
in Active Directory Domain Services.
And Microsoft 365 Groups are synced
to Azure AD Domain Services from Azure AD,
where they are created as Security Groups.
No wonder everyone gets confused.
And it's important to remember
that you should only manage or update the user or group
in the source location where it came from.
Mostly, you're not able to modify users
that originated somewhere else,
but some changes are possible.
But it's still not recommended.
A good example is resetting the passwords
for Azure AD Domain Services sync to users.
While it may work, it's not recommended,
and it will cause your passwords to be out of sync.
All right.
There's some pretty decent gotchas in this section.
Let's cover off some of the most common tips
that will help you prepare for the exam,
because I don't want you getting tripped up
by some limitation or requirement that you weren't aware of.
Now, grab your notebook, and let's take a look.
Azure AD Domain Services is a Microsoft-managed
Active Directory Domain Services deployment
in your virtual network.
And you don't get Enterprise Admin
or Domain Admin-level privileges in the managed domain.
So you can't do anything that that allows.
Including deploying additional domain controllers
that you manage or updating the schema.
And you can only have one Azure AD Domain Services
managed domain per Azure AD tenant
and replica sets can be used to provide global redundancy.
And there are 2 Azure Active Directory Domain Services
forest types: the user forest and the resource forest.
User accounts are not synced
from Active Directory Domain Services
to Azure AD Domain Services
when using a resource forest.
Instead, a trust relationship is used for authentication.
And there are 2 Azure AD Domain Services SKUs,
and you should choose a non-standard SKU
to implement a resource forest.
And there are quite a few things that you cannot change
after the deployment of Azure AD Domain Services,
including the forest type, subscription, resource group,
domain name, virtual network, and subnet.
But you can change the SKU and the sync options.
It's also important to remember
that Azure AD Domain Services is dependent on DNS
and network connectivity to the managed domain controllers.
Remember that network security groups
can also block access to domain controller
if they're misconfigured.
And the AAD DC Administrators Azure AD group
is used to grant administrative access
to the Azure AD Domain Services managed domain.
What might catch people out about this
is that it is a group and not a role in Azure,
and that's because the group is synchronized
into the managed domain from Azure AD
to Azure AD Domain Services.
And to log on to an Azure AD-joined VM,
you need to be assigned
the Virtual Machine Administrator Login
or Virtual Machine User Login role.
And finally, it's important to remember
that Domain controller Virtual Machines
should have a static IP address
and must have the disk cache set to none,
where the Active Directory database
and SYSVOL data are stored.
All right.
There's been quite a bit to cover in this section.
Congratulations on making it to the end,
and I look forward to seeing you in the next section.