Hello and welcome to the section where we review the best practices for running a Windows Domain controller in Azure. Domain controllers work almost the same in Azure as they do on premises but there are a couple of considerations to be aware of specific to running Domain controllers in Azure. To understand the first consideration, let's get an understanding of how Azure provisions virtual servers. Just like any hypervisor, the VM is deployed on physical hardware and the OS and any additional data disks are stored on a highly available storage platform.

Most Azure VMS also have temporary storage mounted as a D drive. This D drive maps two discs located on the physical server. The D drive is a high performance disk for temporary data storage. Specifically, the page file is stored on this drive by default. The D drive is removed when the VM is de-allocated and re-provisioned when it started. The page file is recreated once it boots. The important consideration of the temporary D drive is not to put the Active directory database files on that drive. Instead, we create a new data drive for the active directory database, just like on premises. And just like on premises, that drive should have write-cache disabled.

There are a couple of VM series, the L series and the B series that do not allow disk caching to be changed. As we select VM sizes and add disks, we have to disable write-caching for the data disk that stores the active directory database. Also like on-premises, the domain controller requires a static IP address. But unlike on-premises, we don't do this through the ethernet adapter properties. Azure uses a service called the wire server to communicate with the Azure agent on the VM. The wire server has several functions including acting as a DHCP server that hands out IP addresses.

The server must use DHCP for IP address assignment in order for the agent communication to function properly. Instead of setting a static IP address on the server, we give the virtual network interface a static IP address in Azure. This configuration acts like a DHCP reservation. The server will always get the same IP address. For our clients to join Windows AD and Azure, the DNS settings on the VNet have to use custom DNS servers, the DNS server on the domain controllers in most instances. The default DNS servers are external Azure DNS servers and are not aware of our Windows domain.

We also have to plan for availability. One standalone domain controller is fine for a lab but in production, we should always have at least two. Let's look at some example configurations. First, we extend our on-premises network to Azure with a VPN or Azure express route. We have multiple domain controllers in this example, one of them in Azure. Here, we have multiple domain controllers in one region. This example places the two domain controllers in an availability set. An availability set provides high availability by placing the VMs in different vault and update domains in the same region. If an organization leverages multiple regions, it can place a domain controller in each and use global network peering to connect the two regions.

As you can see, there's a lot of flexibility in how we can deploy domain controllers in Azure. Finally, one common way to save money in Azure is to shut down and deallocate VMs when they're not in use. If we simply shut down the VM from within the OS, the virtual hardware still allocated to the VM and charges still apply. If we stop the VM from within Azure, the virtual hardware is deallocated and charges stop. On the domain controller in Azure, the deallocation process resets the VM generation ID and invocation ID. It also discards the current active directory relative identifier or red pool and causes the sysvol folder to be marked as nonauthoritative. It's best not to de allocate a domain controller running in Azure, it is safe to shut down and restart from within the OS.

Let's move on to creating a VM in Azure and deploying a domain controller.