The official blog for Windows Server Essentials and Small Business Server support and product group communications.
EPS Team Blogs
[Today's post comes to us courtesy of Jim Martin]
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:
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:
The following FAQs answer these and other questions related to SBS licensing and installation:http://www.microsoft.com/WindowsServer2003/sbs/evaluation/faq/licensing.mspxhttp://www.microsoft.com/windowsserver2003/sbs/evaluation/faq/setup.mspx
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.
Create a diagram of your existing physical network including:
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.
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.
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:
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:
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: ServicesIsmServ 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.
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:
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 http://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.
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”.
A DNS server that hosts a copy of the zones for the internal domain provides the following services for the 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.
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 http://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.
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 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/adsrv.mspx
In a nutshell these are the steps:
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.
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.
Note: Do not manually create any zones. The internal zones will replicate from an existing DC/DNS Server after promotion.
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 http://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 http://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.
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:
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.
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.
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.
PingBack from http://internet.blogfeedsworld.com/?p=6884
The Official SBS Blog: Debunking Myths About Additional Domain Controllers In SBS Domains http://blogs
Thanks for a great article. I've seen the information posted before, but it's always good to have another reminder.
If you are going to run additional DCs in a virtual machine (VMware, XEN or Microsoft) make sure you check out KB 890893 and KB 888794 :
Note that you will encounter USN rollback problems if you use an AD-unaware program to backup and restore DCs.
thank you so much for posting this, excellent guide that came in very useful for me today!