The directory structure that Microsoft networks use to house their users and computer accounts is called Active Directory (AD), and the directory information is controlled and managed by Domain Controller (DC) servers. Two other server roles that almost always go hand in hand with Active Directory are DNS and DHCP, and in many networks these three roles are combined on each server where they reside. A lot of small businesses have always made due with a single server containing all three of these roles, but in recent years virtualization has become so easy that almost everyone runs at least two Domain Controllers, for redundancy purposes. And if you are going to have two DCs, you may as well put the DNS and DHCP roles on them both to make those services redundant as well. But I'm getting ahead of myself. For this recipe, let's get started building these services by installing the roles and configuring them...

Active Directory is the core of your network. It has ties in everything! As such, it makes sense that you would want this to be as redundant as possible. In Windows Server 2012 R2, creating a secondary Domain Controller is so easy that you really have no reason not to do it. Can you imagine rebuilding your directory following a single server hardware failure where you have 100 user accounts and computers that are all part of the domain that just failed? That could take weeks to clean up, and you'll probably never get it back exactly the way it was before. Additionally, while you are stuck in the middle of this downtime, you will have all kinds of trouble inside your network since your user and computer accounts are relying on Active Directory, which would then be offline. Here are the steps to take a second server in your network and join it to the existing domain that is running on the primary DC to create our redundant, secondary Domain Controller...

Active Directory is the structure in which all of your user, computer, and server accounts reside. As you add new users and computers into your domain, they will be automatically placed into generic storage containers. You could get away with leaving all of your objects in their default locations, but there are a lot of advantages to putting a little time and effort into creating an organizational structure.

In this recipe, we will create some Organizational Units (OUs) inside Active Directory and move around our existing objects into these OUs so that we can create some structure.

Most folks working in IT are familiar with using the ping command to test network connectivity. If you are trying to test the connection between your computer and another, you can ping it from a command prompt and test whether or not it replies. This assumes that the firewalls in your computers and network allow the ping to respond correctly, which generally is true. If you are inside a domain network and ping a device by its name, that name resolves to an IP address, which is the device's address on the network. But what tells your computer which IP address corresponds to which name? This is where DNS comes in. Any time that your computer makes a request for a name, whether it is you pinging another computer or your Outlook email client requesting the name of your Exchange Server, your computer always reaches out to your network's DNS servers and asks, "How do I get to this name?".

DNS contains a list of records that tell the computers...

Now that we are familiar with moving around a little bit inside the DNS management tool, we are going to create and test another type of record. This one is called a CNAME, and it is easiest to think of this one as an alias record. Rather than taking a DNS name and pointing it at an IP address as we do with a host record, with a CNAME we are going to take a DNS name and point it at another DNS name! Why would this be necessary? If you are hosting multiple services on a single server but want those services to be contacted by using different names, CNAME records can be your best friend.

In the Configuring a combination Domain Controller, DNS server, and DHCP server recipe, we installed the DHCP role onto a server called DC-01. Without some configuration, however, that role isn't doing anything. In most companies that I work with, all of the servers have statically assigned IP addresses, which are IPs entered by hand into the NIC properties. This way, those servers always retain the same IP address. But what about client machines that might move around, or even move in and out of the network? DHCP is a mechanism that the clients can reach out to in order to obtain IP addressing information for the network that they are currently plugged into.

This way, users or admins don't have to worry about configuring IP settings on the client machine, as they are configured automatically by the DHCP server. In order for our DHCP server to hand out IP addresses, we need to configure a scope.