Active Directory 101 Do's and Don'ts

Active Directory (AD) is so prevalent on Windows networks that many administrators don’t really give it a second thought. In most cases, AD will continue to function even if it's not optimally configured. And in many cases, the decisions that you make during your initial planning of an AD deployment can come back to haunt, or help, you later on. Let's take a brief look at some of these initial decisions to ensure that you make the right choice the first time.

Picking an AD Domain Name

DO use a different suffix, a subdomain, or .local suffix for your domain name. Either one of these is a good choice. A different domain suffix (using .net for AD instead of .com) is fine as long as both domain names are registered to you. Another popular choice is to use a subdomain such as ad.mycompany.com or internal.mycompany.com. This is a good choice if you’re in a large organization and the group that manages Active Directory is far removed from the group that manages DNS as a whole. Finally, many administrators use .local; in fact this is the default used in Windows Small Business Server.

DON'T use a single-label domain name such as “mycompany.” While technically valid, this will wreak havoc on many applications that rely heavily on AD, such as Microsoft Exchange.

DON'T use a registered domain name that isn’t registered to you. Even though you missed out on snagging iloveclowns.net, it isn’t okay to use that as your AD domain name because “no one will ever see it.” People very well may; if you use Exchange it will show up in email message headers. Likewise, it will give you a huge headache if a client machine is pointed to the wrong DNS server and attempts to resolve AD resources using the DNS zones for the registered iloveclowns.net.

DO set up split-brain DNS. By segregating your DNS infrastructure during your AD deployment, you will tackle any problems solved by split-brain sooner rather than later. See the article “Split-Brain DNS” (InstantDoc ID 99772) for more on how to set this up.

Placing Domain Controllers

DON'T forget that placement of domain controllers (DCs) is important, especially DCs hosting Flexible Single Master Operations (FSMO) roles and those functioning as Global Catalog (GC) servers. Your first DC in a brand-new forest will contain all of the FSMO roles and function as a GC server. After you install additional DCs, remember to move FSMO roles around as appropriate and ensure that you have an appropriate number of GC servers.

DO consider application requirements in your initial planning. Microsoft Exchange Server and Office Communications Server are two that are heavily integrated into AD and require adequate access to AD resources. GC placement is essential for these workloads as well, so if you're even thinking about adding one of these applications later on, take some time and work out a preliminary deployment plan so that you’re prepared if and when you decide to deploy one of them.

DO place at least one DC in each site, and make one of those DCs in each site a GC server. This is a good starting point to ensure adequate availability to AD resources.

DON'T leave any of your DCs physically unsecured. Setting up a DC in the kitchen of the branch office might seem okay until the DC is borrowed one night for the office manager’s LAN party. Any DC that must, for some reason, be unsecured should be at least a Windows Server 2008 DC running as a Read-Only Domain Controller (RoDC). Note that some applications, again, including Exchange, need a writable DC to function.

DO keep things simple. The more complex you make your deployment initially, the harder it will be to simplify later on. Start out simple and build from there.

DO back up your DCs. You need to do this. Period. Use the built-in Windows Backup utility and backup to disk for a quick and easy solution.

DO record your Directory Services Restore Mode (DSRM) password and ensure that it's the same across all your DCs. Write it down and store it someplace secure.

DON'T make your domain design needlessly complex. Previously in AD, the only way to maintain separate password policies was to establish separate domains. Windows Server 2008 alleviates this problem, so don’t make up more domains than you have to. Use Organizational Units (OUs) instead.

DO pick an OU scheme and stick with it. If you decide to create OUs by physical location and then by department, resist the urge to one day create a top-level OU for newly created Basket Weaving department that is located underwater. One day, basket weaving will be done at more than one location or another department will live underwater. Keep the OU structure uniform.

DO create OUs specifically for testing. These will come in very handy when establishing and configuring Group Policy Objects (GPOs).

Keep these Dos and Don’ts in mind when initially setting up AD, and you’ll ensure a good deployment that can grow with your needs, without any painful gotchas.

To learn more about AD, check out these resources:

"Active Directory Auditing Tools"

"Avoid Active Directory Pain"

"Listing Members of an AD Group"

(If you would like to see an article available on a particular aspect of AD that's bothering you or that you need help with, contact the AD editor, Caroline Marwitz, at her email address on the Windows IT Pro author page link.)