 Hello, Windows Server Hybrid administrators. Welcome to this Microsoft Learn Training module. The title of this module is Implement, Deploy, and Manage Azure Active Directory Domain Controllers in Azure. This module provides information on how to extend an existing Active Directory environment into Azure by placing IaaS VMs configured as domain controllers into specially configured Azure Virtual Network subnets. In addition to learning about these technical topics, this module is part of a playlist that also functions as preparations for objective domain one. Deploy and manage ADDS in on-premises and cloud environments of the first Windows Server Hybrid Administrator Associate Exam, AZ800. Other modules in the playlist on this channel deal with other Windows Server and Hybrid IT Pro topics. This module is adapted from a module that you can take on Microsoft Learn. The module itself provides more detail, references, demos, and knowledge checks to test your understanding. You can follow along with the contents of this module on Microsoft Learn at the address shown on the screen or listed in the video description. The Windows Server Hybrid Administrator Associate Certification is Microsoft's successor to the Windows Server MCSE. Certification has always been important for Windows Server administrators, and the Windows Server Hybrid Administrator Associate brings the old MCSE into the 2020s. To earn this certification, you need to pass two exams, AZ800 and AZ801. Being successful on the exams requires that you not only understand how to do common administrative tasks such as managing Active Directory, managing storage, networking, security, disaster recovery, monitoring, and virtualization on-premises, just like you would have had to do for the last years of Windows Server, but that you also know how you can integrate and extend Windows Server with the relevant services that are available in the Cloud. The process of deploying an Active Directory Domain Controller on an Azure VM is similar to the process of deploying a Domain Controller in an on-premises environment. One primary difference is that when you deploy a Domain Controller in Azure, you must place the Active Directory database on the data disk of an Azure VM to avoid potential database corruption. Database corruption might occur because of the read and write cache settings of the operating system disk on the Azure VM. Azure provides multiple options for implementing directory and identity services using ADDS in Azure. The different considerations and requirements are based on the deployment scenario that you select. Deploy ADDS only on an Azure VM involves creating a VNet, but doesn't require cross-premises connectivity. Typically, this deployment starts with a new forest and all the Domain Controllers run only on Azure VMs. In this scenario, you should consider setting static IP addresses for Domain Controllers. This scenario is common for apps that depend on Kerberos authentication but don't have any requirements that are related to on-premises directory services. Greenfield deployments where there's no existing on-premises ADDS environment. Deploy ADDS in both an on-premises infrastructure and on an Azure VM is common for apps that are LDAP aware and that support Windows integrated authentication. This scenario requires creating a VNet with cross-premises connectivity and proper IP address allocation for VMs that are running in the cloud. The primary goal of this scenario is to optimize the cost of a solution, considering that inbound traffic ingress is free but not outbound traffic egress. This is because systems and applications in Azure would refer to the ADDS Domain Controllers in Azure for authentication. This scenario provides faster performance and a better sign-in experience for users who access the apps by authenticating to the cloud-based Domain Controllers. When deploying ADDS in an on-premises environment and on an Azure VM, there are multiple options that Azure supports. Deploy an additional ADDS Domain Controller to an Azure VM. If your application is hosted partly on-premises and partly in Azure, it may be more efficient to replicate ADDS in Azure. This can reduce the latency caused by sending the user to an Azure VM or latency caused by sending authentication requests from the cloud back to ADDS running on-premises. This architecture is commonly used when the on-premises network and the Azure Virtual Network are connected by a virtual private network, VPN or ExpressRap connection. This architecture also supports bidirectional replication, meaning you can make changes either on-premises or in the cloud and both sources will be kept consistent. Typical uses for this architecture include hybrid applications in which functionality is distributed between on-premises and Azure and applications and services that perform authentication using Active Directory. Deploy a separate Active Directory forest or domain to Azure that is trusted by domains in your on-premises AD forest. ADDS stores identity information in a hierarchical structure. The top node in the hierarchical structure is known as a forest. A forest contains domains and domains contain other types of objects. This reference architecture includes creating an ADDS domain in Azure that is a member of the same AD forest as the on-premises domain. In this scenario, creating a trust relationship between the different domains is not required because domains in the same forest inherently automatically trust each other. Alternatively, you can create an ADDS forest in Azure with a one-way outgoing or a two-way bidirectional trust relationship with an on-premises domain. In this scenario, the forest in Azure contains a domain that doesn't exist on-premises because of the trust relationship. Signings made against on-premises domains can be trusted for access to resources in the separate as your domain. Typical uses for this architecture include maintaining security separation for objects and identities kept in the cloud and migrating individual domains from on-premises to the cloud. In terms of network recommendations, configure the VM network interface, NIC for each ADDS server with a static private IP address for full DNS support. You must also configure the Active Directory Subnet Network Security Group. NSG rules to commit incoming traffic from on-premises and outgoing traffic to on-premises. Because of security concerns, you should not configure the VM NIC for any domain controller with a public IP address. Intersite connectivity. A key design element is intersite connectivity between your on-premises environment and to ensure that as your hosted VMs can communicate with internal domain controllers, you must set up a VNet with site-to-site connectivity back to your on-premises network, or you must use Express for it. Cross-premises connectivity requires a VPN server that supports incoming connections from Azure, a static public IP address on your internet connection and a dynamic gateway for the VNet to establish connectivity with the on-premises infrastructure. Active Directory sites. You must configure sites in ADDS so that you can control replication traffic between the on-premises and as your base domain controllers. Knowledge consistency checker, KCC, controls the replication process with intersite replication, relying on a bidirectional ring topology that assumes connections with high bandwidth and that are permanently available. Replication traffic is not scheduled and updates are optimized for speed. By contrast, intersite replication uses a least-cost spanning tree topology with a default three-hour interval that can be restricted to certain times of the day or week. Trust relationship. A trust relationship is required in the scenario where your on-premises AD domain is contained within a different AD forest from the AD domain in Azure. To enable authentication of on-premises users in Azure, the domain in Azure must trust the log-on domain in the on-premises forest. Similarly, if Azure provides a log-on domain for external users, it might be necessary for the on-premises forest to trust the cloud domain. You can establish trusts at the forest level by creating forest trusts or at the domain level by creating external trusts. A forest level trust creates a transitive trust relationship between all the domains in the two forests. Conversely, an external domain level trust only creates a non-transitive trust relationship between two specified domains. Trusts can be unidirectional, one-way or bi-directional, two-way. A one-way trust enables users in one domain or forest known as the incoming domain or forest to access the resources in another forest known as the outgoing domain or forest. A two-way trust enables users in either domain or forest to access resources in the other. You should only create external domain level trusts between domains in different forests. Read-only domain controllers, RODC. This arrangement reduces the amount of egress traffic and the resulting Azure service charges. RODC is do not work in situations where a service or application needs right access to ADDS. Flexible single master operations, FSMR, roles and global catalog placement. Regardless of your domain topology, you should configure all of your Azure-based domain controllers as global catalog servers. This arrangement prevents global catalog lookups and evaluations of universal group memberships from having to traverse from Azure to the on-premises global catalog, thus incurring egress network traffic charges. If Azure domain controllers are in a separate forest, its operation masters need to be hosted in Azure. If your Azure domain controllers are in a separate domain, you will need to configure the domain's primary domain emulator master, relative ID master and infrastructure master on those VMs in Azure. You might consider designating one or more servers in each domain as standby operations masters in case connectivity to a server acting as FSMR or files. Availability, you should provision at least two AD domain controllers for each domain. This enables automatic replication between servers. You should also consider creating an availability set for the AD domain controller VMs and configure at least two servers for each availability set. Backup and restore, use the same procedure as for an on-premises domain controller to back up the system state on a domain controller. You should avoid copying or cloning the virtual hard drive as this could introduce an update sequence number rollback effect. This might also prevent the database from starting as the ADDS database file on the virtual hard drive might not be in a consistent state when it's copied management. You should not shut down an AD domain controller VM using the Azure portal. Instead, you should shut down and restart from the guest OS. Shutting down the AD domain controller through the Azure portal causes the Azure VM to be deallocated, which resets both the active directory repositories, VM generation ID and invocation ID. This discards the ADDS relative identifier, read, pull and mark the sysvol folder as non-authoritated. It might also require reconfiguration of the domain controller, monitor. Monitor the resources of the domain controller VMs and the ADDS services and create a plan to quickly correct any problems. For example, you can use Azure monitor to analyze the performance of your infrastructure, which enables you to monitor and diagnose networking issues without signing into your VMs. You can use application insights to provide metrics and logs to verify the state of your infrastructure. The requirements for creating a domain controller on an Azure VM as a replica domain controller or in a new forest are similar. Both scenarios require a storage account for creating the OS and data disk for the VM. And as a best practice, you should configure the domain controller with static IP addresses. However, in the first scenario, you must configure a VNet for cross-premises connectivity by using site-to-site VPN or ExpressRap. When you create in Azure VNet for a site-to-site VPN, you must specify the name of the virtual network, the DNS server addresses that point to your on-premises DNS servers, site-to-site VPN connectivity with the on-premises infrastructure. This involves creating a dynamic gateway with a public IP address for establishing a site-to-site VPN tunnel with the on-premises VPN device, the local network that defines the IP address assignment for the on-premises network, virtual network address spaces that define the IP address range for VMs that run in Azure. The address range cannot overlap the address space for your on-premises network. Additionally, you must configure an on-premises VPN device with a public IP address and the configuration rules that all connect to the previously created dynamic gateway. You can use ExpressRap instead of site-to-site VPN for cross-premises connectivity. With ExpressRap, you can extend your on-premises networks into Azure over a dedicated private connection that is provided by a connectivity provider. ExpressRap connections use dedicated lines instead of a public internet connection and provide faster speeds, more reliability and lower latency. To promote the server to a domain controller, you must add and then configure ADDS. You can add the ADDS role by using ed roles and features in server manager or by using the following Windows PowerShell commandlet, add Windows feature ADDS domain controller. ADDS setup allows you to automatically add the DNS role to the server. You can also install it later by using ed roles and features in server manager or by running the following Windows PowerShell commandlet, add Windows feature DNS, place the Active Directory database on a data drive with caching turned off. In this module, you learned how to extend an existing Active Directory environment into Azure by placing ISVM on specially configured Azure virtual subnets. Now, we publish IT Pro content regularly on this channel related to Windows Server, Hybrid and Azure operations. Remember to like and subscribe and hope to see you in future sessions.