In this demonstration,
we're going to look at trust relationships in Active Directory,
but I want to start by sweeping up some shavings from the previous module,
and that is, I didn't show you how to promote a domain controller as an Azure VM,
as opposed to an on‑premises VM.
Now,
really there's nothing to show in terms of the procedure is exactly the same.
As long as you've extended your local environment into Azure with
a Site‑to‑Site VPN or an ExpressRoute link,
you're good to go,
and then you can deploy your Windows Server VMs to
the Azure VNet or virtual network, and install the server role,
promote the machine just like you would.
But the main catch that I need you to be aware of is configuring
DNS and making sure that in your virtual network,
those servers and any other machines that are going to be involved in
domain communications have the DNS server IP addresses.
So here we're looking in my Azure subscription at a
VNet I have called cloud‑vnet,
and I do have a domain controller deployed called rootdc3,
as you can see, that's consuming an IP address in this environment.
And what you do is you go to the DNS server settings right here,
and instead of using the Azure provided DNS,
you override that by selecting Custom,
and this is where you'll populate the IP addresses.
If you're Site‑to‑Site, VPN, or ExpressRoute,
you can use private non‑internet routable,
so you would add the domain controller IP addresses on‑prem,
on the local side, as well as your cloud‑hosted VM,
you would need to populate its address here.
So notice that you're configuring the virtual network with those
Active Directory domain controller DNS settings.
You're not RDPing into the VM and configuring the network properties.
Never make that mistake.
You want to make sure that your TCP/IP configuration in Azure
is always done in the Azure control plane.
Now you can actually configure custom DNS.
If you don't want to do it at the VNet level or if you do it at the VNet level,
you can continue to refine because remember that your virtual machines all
have their TCP/IP defined in the network interface resource.
Now we could take a look for instance at this rootdc2 network
interface and note that there's a DNS server here,
and the default setting is to inherit the DNS from the virtual network settings,
but you can override that if you want to or if you need to.
Another thing to consider is the private IP of your Azure domain controller.
You don't want a dynamic private IP address.
You don't want that private IP to change when you restart the domain
controller or shut it down and turn it back on,
so in order to do static addressing,
you do that again at the network interface level.
We come to IP configurations, we select the default IP configuration,
and then for your private IP address,
you'll want to flip the switch from Dynamic to Static,
choose a non‑conflicting private IP address in that subnet,
hit Save,
and you will have to restart the virtual machine for
that VM to pick up the change.
Now another Azure‑specific idea I want to go with before
I continue this lesson's material,
I want to make you aware of the Azure QuickStart templates repository at GitHub.
You can check the exercise files for links on this.
There's a public marketing page where you could easily look up templates,
or you could clone the entire repo like I did.
And there are some Azure Resource Manager deployment templates in
there that automate domain controller placement.
Specifically in the repo, if you go under application‑workloads,
active‑directory, active‑directory‑new‑domain,
this is an ARM template that walks you through,
and what it's using is PowerShell Desired State Configuration.
So what it's automating is the deployment of the virtual machine,
and notice that the parameters file, let me bring that up a little bit,
you need to specify your default credentials.
And I would strongly recommend instead of doing value here for
your admin password and your parameter file,
that you store your admin password in Azure Key Vault,
and instead of doing a value in your JSON,
you can actually do a reference, specifically to an Azure keyVault,
and you specify the resource ID to the keyVault,
and then the name of the secret.
And as long as you or whoever runs the deployment has
permissions in the Key Vault to read out that key,
this means that you can pass credentials in your deployment templates
without ever exposing the plaintext of those secrets.
But anyway, the magic here, like I said,
is that we're injecting a PowerShell script here that's
actually a desired state configuration file.
And as you can see, if you've worked with PowerShell DSC,
this is a configuration management platform that's built into PowerShell,
and this is responsible for, as you can see here,
ensuring that the DNS server role is installed,
configured, and available, Dnstools,
and then eventually we've got AD‑Domain‑Services,
and there's some additional nested templates in here
that deal with the rest of the process.
Actually,
you can do the domain controller promotion and including
the appropriate RSAT tools all in the context of this
Desired State Configuration script.
So the exam's not going to get to that level of depth,
but long story short,
deploying domain controllers in the VNet is
basically the same process as on‑prem,
it's just you want to keep your IP addressing and your DNS
configuration done in your VNets properly,
and then in terms of automated deployment using ARM templates,
you do have the ability, this is just one pattern, to automate the promotion of the domain controller if you want to.