Debunking Myths About Additional Domain Controllers In SBS Domains

[Today's post comes to us courtesy of Jim Martin]

Can you have additional domain controllers (Replica DCs) in an SBS domain?

The are several myths about SBS (see “The Top Ten (Plus One) Myths About Windows Small Business Server 2003” or the webcast “Debunking the Top 10 Myths of Small Business Server in Larger Environments”). But the most common one seems to be the misconception that you cannot have other domain controllers in a domain that has a Small Business Server. Let’s set the record straight right now. You can! In fact, in many cases it can be very beneficial.

The myth about this not being allowed probably originated from one or more of the following, which are themselves true. However this somehow got misconstrued to mean that you can’t have additional DCs:

  • You cannot have more than one Small Business Server in the same domain. This is most likely the main cause of confusion on the issue. You can have other DCs but none of them can be another Small Business Server.
  • You must take special steps to promote a Small Business Server into an existing Active Directory domain. I’ll go into more details on this later, but essentially because of the way that SBS is promoted as a DC in a new domain during the SBS integrated setup, it may not be immediately apparent how to successfully promote it into an existing domain. And with SBS 2000 you could not use the SBS media to do so, but rather had to use media for Standard Windows 2000 Server. Also, it is not supported to demote the Small Business Server after it is installed then promote it into another, existing domain.
  • The Small Business Server must own all of the forest and domain FSMO roles. Obviously only one DC in the forest can have this requirement.
  • The SBS domain must be the root domain of the forest and trusts or parent/child domains are not supported.

Note: For the sake of clarity, a “replica domain controller” is simply an additional domain controller. In an Active Directory domain there are no longer PDCs or BDCs and all DCs are considered peers. When another DC is promoted into an existing domain it is typically referred to as a replica DC. We have seen the acronym “ADC” used to refer to an “Additional Domain Controller”, but we will not use that here in to avoid confusion it with “Active Directory Connector”.

Check out the following links for more information about the top 10 myths about Small Business Server 2003:

What are the benefits of having replica DCs in an SBS domain, or in any domain for that matter?

  • Redundancy
    • If the Small Business Server cannot be contacted but another DC is available users can still authenticate.
    • If DNS is also installed and the zone for the internal domain is being replicated to all DCs/DNS servers, redundancy will be provided for local and public DNS namespace queries.
  • Disaster recovery
    • It is not necessary to rebuild your entire Active Directory domain if the Small Business Server crashes and you don’t have a good system state backup.
  • Improved user experience
    • If additional DCs are placed at remote sites and also made Global Catalog Servers, remote users can logon more quickly and reliably, and locate objects in the domain more quickly.

Before we look at how to deploy it, let’s review the real restrictions associated with deploying SBS.

  • There can be only one Small Business Server in the domain. (You can actually have more than one Small Business Server in the same domain for up to 7 days before one or both of them start shutting down every hour. This can be useful in some migration scenarios. However be sure to finish the migration and then demote and remove one of them from the network before they start shutting down!)
  • The Small Business Server must be installed into the root domain of a single-domain forest.
  • SBS does not support trusts with other domains or forests, including both implicit and explicit trusts.
  • SBS does not support parent or child domains.
  • The Small Business Server must own all 5 of the forest and domain FSMO roles.
  • The Small Business Server must be a global catalog server.
  • SBS supports up to 75 user or device CALs.
  • The components that come with SBS such as Exchange, SQL, and ISA can only be installed on the server that is running SBS.
  • Additional servers can be joined to or promoted to the domain but separate server licenses must be obtained for each additional server. However expanded client access license (CAL) rights in Windows SBS 2003 R2 allow client computers to access additional servers on the network (such as those running Exchange Server 2003, SQL Server 2005 Workgroup Edition, and Windows Server) without requiring additional CALs. This applies to additional DCs as well.

The following FAQs answer these and other questions related to SBS licensing and installation:
https://www.microsoft.com/WindowsServer2003/sbs/evaluation/faq/licensing.mspx
https://www.microsoft.com/windowsserver2003/sbs/evaluation/faq/setup.mspx

Deployment

Analysis and Planning

Planning is always beneficial, even in small environments. And sometimes you can gain some insight about your network just by drawing it out on paper.

Analyze your existing physical network

Create a diagram of your existing physical network including:

  • Sites – Keep in mind the definition of a site is a group of well-connected computers. Well-connected typically means they are connected to each other at LAN speed (10 mbps or greater) and that the connection is relatively consistent and reliable. This usually means they are on the same physical LAN (but not necessarily the same subnet). Physical sites are not related to the logical structure of your AD domain (Containers, OUs, etc.). If you have 2 sets of subnets connected via a VPN over the Internet, you should consider them to be different sites.
  • Subnets – there could be more than one at a site
  • Domain controllers – which of these are global catalog servers?; which ones are also DNS servers?
  • Member servers – Application servers, Exchange Servers, file and print servers, etc.
  • Workstations
  • Printers
Analyze the number and distribution of users

In particular note roaming patterns and which sites they typically logon from.

Using all of the information above you should then be able to determine the number and placement of domain controllers, global catalog servers, and DNS servers.

Backup every existing DC before making any changes

Perform a full backup of every existing DC, including system state, before making any changes to the network or the domain. If a configuration change or DC promotion fails or causes problems, you might have to rebuild a server or your domain if you do not have good backups.

Check the health of the existing network and Active Directory

Verify the DNS configuration

First decide on one DNS server in your domain to be the “master”. In reality they are all peers but you should choose one to be configured as the “Preferred DNS Server” for all domain controllers in the domain. This is very important to make sure that all host (A) and service (SRV) records are dynamically updated and replicated universally. Registering the domain controller DNS records is pivotal to AD replication working properly. You want to avoid inadvertently creating a situation known as “DNS islands” in which different DNS servers might have their own copies of the internal zones which differ from the copies on other DNS servers.

Next, verify the properties of the network connection on each DC. In each case the “Preferred DNS Server” should point to the “master” DNS server and the “Alternate DNS Server” should point to itself.

In the advanced DNS properties make sure the following are selected:

  • Append primary and connection specific DNS suffixes
  • Append parent suffixes of the primary DNS suffix
  • Register this connection’s addresses in DNS

If you make changes to these settings on any machine, re-register the DNS host and service records for that machine with the following commands:

  1. Ipconfig /flushdns
  2. Ipconfig /registerdns
  3. Net stop netlogon
  4. Net start netlogon

Verify the health of the network

One of the best ways to do this is to run NETDIAG from the Windows Support Tools or Resource Kit. I would run it once on each DC without any parameters just to see if there are any errors at a glance, then if there are some or if you want more detail, run it with the “/v” switch. For more options run it with the “/?” switch.

If it fails any test, investigate and resolve that issue before proceeding.

Verify the health of the domain

From the same set of tools as NETDIAG run DCDIAG. Again, run it once without parameters just to see a summary of issues and run it with “/v” to get more details. Use “/?” to see more options. Note that you can specify a domain controller name with the “/s” switch so you can run it for each machine from the same one provided there are no network or others issues preventing you from doing so.

One error you can safely ignore when you run it on SBS will be:

Starting test: Services
IsmServ Service is stopped on [SBSERVER]
......................... SBSERVER failed test Services

Fix any other errors before proceeding.

Verify the health of replication

DCDIAG will give you some indication if there are replication issues but you should use REPADMIN or REPLMON to thoroughly verify and analyze the replication status of every existing DC. Both of these can be found in the Windows Support Tools.

REPADMIN is a command line tool. In short, you can run “repadmin /showreps” on each DC to get the date, time, and status of the last replication attempt for each AD partition. Use the “/?” switch for more options.

REPLMON is a GUI that makes it easier to visualize the replication status.

Fix any errors before proceeding.

Domain controller placement

Having more than one DC at the same site is usually a decision based on redundancy, disaster recovery, and the volume of users at that site. I recommend that if you only have one site you should have at least 2 DCs at that site regardless of the volume of users. The costs associated with an additional DC can certainly be a factor but, although I won’t go into details about it here, keep in mind that virtualization technologies such as Virtual Server and Virtual PC provide a variety of low-cost options.

For the best user experience each site should have at least one DC. But several factors can dictate how practical that might be such as:

  • The number of users at the site
  • The reliability of the connection to other sites
  • How well the users at the site can tolerate a temporary outage or slow logon, access, or search responses
  • The hardware, software, and maintenance costs of an additional DC vs. the benefits

When a user logs on to the domain, in order to optimize their experience, the logon process attempts to locate a DC which is in the same site as the client machine from which the user is logging on. The site is determined based on the IP subnet of the client machine. If one cannot be found in the same site, a DC in the next closest site is used. So as long as the site’s connection to other sites is reliable, a DC is likely to be located to authenticate the user, although the user’s experience may not be optimal. Another thing to keep in mind is that if a DC cannot be located, the user will be logged on with cached credentials if the user has previously logged on to the domain from that machine.

The following article describes the process of locating a domain controller during the logon process:

247811 - How Domain Controllers Are Located in Windows https://support.microsoft.com/kb/247811

Another way that connection speed and reliability play a part in determining the proper location for domain controllers has to do with replication. This is a double-edged sword. That’s because if you have a large number of users at a site and perhaps a connection with limited bandwidth, the volume of authentication traffic might be a significant justification for locating a DC at the site. On the other hand, all DCs must replicate with each other to be healthy and up-to-date and replication traffic uses bandwidth as well. Usually the best practice in that situation, is to install the DC at the site if the user volume justifies it and configure replication to occur less frequently or after-hours (this is by default if the DCs are placed in the correct sites in AD Sites and Services). High-priority AD updates such as password changes and user account lockout updates will be replicated as soon as possible regardless of the regular replication schedule. And only objects or attributes that have changed are replicated which uses less bandwidth than if the entire AD partition or object had to be replicated.

Global Catalog Server placement

In a single-domain AD forest, as in the case of SBS (see SBS restrictions earlier in this post), a global catalog server is not needed during the logon process because any DC in the domain essentially has a complete copy of every object in the forest. This is regardless of whether universal groups are available or whether a UPN (Universal Principal Name) is used to logon to the domain. See sections “User Logon” and “Logon Process in a Single-Domain Forest” in the TechNet article “How the Global Catalog Works”:

However, certain applications such as Exchange and Outlook require a Global Catalog to locate objects in the forest, regardless of the AD structure. In the case of Exchange and Outlook it is used to populate address lists and resolve names. The white paper "Understanding and Troubleshooting Directory Access" has more detailed information about how Active Directory and Global Catalog location and access are handled by Exchange and Outlook.

So for SBS domains what’s the best practice for global catalog placement? If you have already made the case for a DC at a site, then you should also make it a GC. Since this is a single-domain forest any additional replication traffic resulting from making the DC a GC will be negligible. Thus your users at that site can enjoy a better experience for virtually no additional cost in bandwidth or overhead. See “How to create or move a global catalog in Windows Server 2003, Windows 2000, or Small Business Server 2000”.

DNS Server placement

A DNS server that hosts a copy of the zones for the internal domain provides the following services for the domain:

  • Resolves internal Active Directory names
  • Performs recursive queries on behalf of clients to resolve public names
  • Caches both positive and negative DNS query results to improve performance
  • Using dynamic DNS it keeps the internal zone up-to-date by registering and maintaining the host (A) and service (SRV) records for machines and services in the internal domain.

By default SBS hosts AD-integrated copies of the zones for the internal domain (contoso.local, _msdcs.contoso.local, and the reverse lookup zones). Since the internal DNS namespace and Active Directory are so closely linked, being able to locate, query, and update a DNS server is integral to maintaining and utilizing a healthy AD.

As with any other AD partition, the DNS application partition (the hosted zones) must replicate with other DNS servers. However, once the domain has been created and the initial member servers and workstations have been joined to the domain, the internal zone will likely be relatively static, and will only be updated when new machines are joined to the domain and when DHCP clients obtain new leases. And as with other AD partitions, only changes to the DNS partition will be replicated between DNS servers that host the internal zones. So, replication traffic associated with having a DNS server at another site is likely to be negligible during normal operations.

So the best practice for DNS server placement will in most cases be the same as that for GCs – if you have already decided on another DC, then install DNS on it and configure the hosted zones to replicate to it. Although there are other options such as making a server at a site only a DNS server or only a DC/GC, or dedicating a separate server to each, there is most likely very little benefit to doing so. In a domain the size of a typical SBS domain, the overhead of performing each of these functions probably would not be significant enough to justify the cost of having a dedicated server for just one or each of them. So again, once you have made the decision to dedicate a machine at a site to one of these functions, you should go ahead and incorporate all 3 functions on the same machine.

Check firewall configuration

Make sure that no firewalls between the new DC and its nearest replication partner will block traffic required for replication, DNS, RPC, and other required traffic. See the following article for more details on what protocols and ports need to be allowed for Active Directory:

832017 Service overview and network port requirements for the Windows Server system https://support.microsoft.com/default.aspx?scid=kb;EN-US;832017

Usually if you have a VPN configured between the new DC and its replication partner, the necessary ports will be open.

Configure Sites and Subnets

Next, if you will have more than one site you will need to configure the additional sites in AD Sites and Services.

If you will only have one site then you need only confirm that you have the single default site “Default-First-Site-Name” and that all existing DCs are already in that site. If you require additional sites refer to this article for more details:

Step-by-Step Guide to Active Directory Sites and Services https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/adsrv.mspx

In a nutshell these are the steps:

  1. Create new sites as needed
  2. Create new subnets and assign them to a the appropriate sites
  3. Define a bridgehead server at each existing site if there is more than one DC already at that site
  4. Run “Check Replication Topology” and verify the topology looks correct

Any new DCs will be moved to the appropriate sites automatically when they are promoted as long as the sites and subnets are defined correctly beforehand in AD Sites and Services.

The DCPROMO Process

Promoting a new DC into an existing SBS domain

This process is identical to the process used for promoting a replica DC into any AD domain.

Obtain a full backup of the new server, including system state, before making any changes.

If something goes wrong and you do not have a backup, you might be forced to rebuild the server from scratch.

Install and Configure DNS on the new server

It is vital that you install and configure DNS properly. Doing this correctly up front could save you a LOT of problems down the road.

You can install DNS by adding the role from the “Manage Your Server” program or from Add/Remove Programs, Add/Remove Windows Components.

Next, configure the properties of the network connection.

When verifying your current DNS configuration earlier you should have already decided on one DNS server in your domain to be the “master”. The “Preferred DNS Server” should point to the “master” DNS server and the “Alternate DNS Server” points to the new server itself.

In the advanced DNS properties make sure the following are selected:

  • Append primary and connection specific DNS suffixes
  • Append parent suffixes of the primary DNS suffix
  • Register this connection’s addresses in DNS

Note: Do not manually create any zones. The internal zones will replicate from an existing DC/DNS Server after promotion.

Run DCPROMO

Just run the command DCPROMO. You do not need to join the server to the domain as a member server first.

If you encounter any errors during this process, stop and resolve them before continuing.

When you get the option of creating a new domain or joining an existing one select “Additional domain controller for an existing domain”.

The next screen prompts you for the credentials of a user with the right to DCPROMO the machine to the domain. I recommend just using the built-in Administrator account for the existing domain. The domain name can be either the FQDN or the NETBIOS name.

Next you are prompted for the name of the domain you want to join. You can specify the FQDN or browse to the domain on the network using the browse button. Browsing is a good way to verify that the domain can actually be found on the network.

Next you are prompted for the location of the AD database and log files. I recommend accepting the defaults unless you are short on free space on the C: drive or have other reasons for locating them elsewhere.

Then you will be asked for the location of the System Volume (SYSVOL). Again, I recommend the default unless you have good reasons to choose otherwise.

You will next be prompted for the DS Restore Mode password. I recommend choosing the same one that you use on the other DCs or at least one you can remember perhaps much later on (perhaps months or years) . In SBS the DSRM password is automatically synchronized with the domain administrator’s password, but this is not automatic in non-SBS Windows Servers, although there are ways you can do it manually:

322672 How To Reset the Directory Services Restore Mode Administrator Account Password in Windows Server 2003 https://support.microsoft.com/default.aspx?scid=kb;EN-US;322672

Finally you will get a summary of the options you chose. This is your last chance to go back and change any of them.

When the promotion process is complete the server will require a restart.

If you have configured everything correctly, the new DC should continue replicating AD from other DCs and GCs after the restart. Open AD Sites and Services on a pre-existing DC and verify the new DC is in the correct site. If it is not, verify that the sites and subnets have been defined correctly. If those are correct, don’t take any corrective action at first. Give the servers a chance to finish replicating and check again later.

Even though the SBS domain might not be very large, it still takes a while for replication to get completely caught up. If you start running health checks too early, you are likely to see errors and spend a lot of time troubleshooting issues that will go away once replication has had a chance to finish completely. This is the perfect opportunity to go have a meal, take a break, etc. You have worked really hard to get to this point and you deserve a break.

After you enjoy a meal and a siesta it’s time to finish up.

Open AD Sites and Services on a pre-existing DC again and verify the new DC is in the correct site. Also check to see if the KCC has detected the appropriate inbound replication partners for each server. Try forcing replication between the new DC and a pre-existing DC just to get an initial indication that everything is configured and talking properly. If you force replication and get an error, you need to address that issue before proceeding. Check the Directory Services event log for ant applicable errors.

If replication has completed and the new DC is still not in the correct site you can manually move it as simply as right-clicking the new server in AD Sites and Services and choosing “Move”, then selecting the desired site.

Promote the new DC to a Global Catalog Server

This a simple process and is documented:

313994 How to create or move a global catalog in Windows Server 2003, Windows 2000, or Small Business Server 2000 https://support.microsoft.com/default.aspx?scid=kb;EN-US;313994

…but just go to the properties of the NTDS Settings object under the server in AD Sites and Services and check the box “Global Catalog”. After doing so, wait for event 1119 to appear in the Directory Services event log which indicates the DC is now acting as a GC before demoting or rebooting another DC or GC. Then force replication to other DCs from this one to ensure that change has been replicated.

Promoting a new Small Business Server as an additional DC in an existing domain

This process is well-defined in knowledge base article “884453 - How to install Small Business Server 2003 in an existing Active Directory domain”. I won’t go into all of the details here but in essence the steps are:

  1. Install only the base Windows Server 2003 OS from the SBS media and cancel the SBS integrated setup when it starts.
  2. DCPROMO the SBS server to the existing domain. (Same process outlined previously under “”Promoting a new DC into an existing SBS domain”)
  3. Install and configure DNS.
    1. Make sure the “Preferred DNS Server” value in the TCP/IP properties of the network connection points to an existing DNS server that , preferably the one and the “Alternate DNS Server” points to itself.
  4. Promote it to a GC.
  5. Transfer all FSMO roles to the SBS server.
  6. Complete the SBS integrated setup.

Be sure to follow 884453 completely and carefully and resolve any issues you encounter before continuing.

If the SBS is located at a site other than the default site, be sure to pre-define your sites and subnets as described previously so it will be placed into the correct site automatically.

Get fresh backups of all domain controllers after the DCPROMO and other changes

You want to make sure you don’t lose all of your work due to unforeseen circumstances. Get a good full backup including system state of every domain controller, both old and new.

Monitoring and maintaining a healthy network and Active Directory

The process for verifying the health of your network and domain after the new server promotion is pretty much the same as the process you followed before the promotion. Use NETDIAG, DCDIAG, REPLMON, and REPADMIN to check and monitor the health of the network, the domain, and replication. Also, make sure you add the new DC(s) to your regular backup procedures.