If you’ve ever had a Windows server completely fail, you know that bringing the server back online is not a walk in the park. Bringing a member server or a stand-alone server back from the dead isn’t really that complicated. However, things get interesting when you start working with domain controllers. This is especially true of Windows 2000 domain controllers in an Active Directory environment. In this article, I’ll explain how to back up and restore domain controllers in an Active Directory environment.
Why you need to back up Active Directory
Over the years, I’ve discovered that many network administrators simply don’t back up the Windows operating system. They’ll back up data files and occasionally include applications, but more often than not, they leave the base operating system unbacked up.
The reason for this is that unless you have a specialized and expensive third-party backup system, you have to manually load Windows onto the system before you’ll be able to restore the backup. I’ve personally never bought into this idea. Even though you have to load Windows onto a failed system before you can restore your backup, I’ve always found it easier to restore a backup than to remember which drivers and applications to reload onto the system. Whatever your previous approach to backing up Windows, all of the rules change when you start backing up Windows 2000 domain controllers.
How backups worked in Windows NT
In Windows NT, backing up the domain controllers really wasn’t a big issue. In many ways, Windows NT does its own backups. To understand why this is the case, you have to understand the way that domain controllers work under Windows NT.
Windows NT uses a single master replication model. In English, this means that although each domain controller contains a copy of the Security Accounts Manager (SAM) database, all of the copies existing on backup domain controllers are read-only. This means that while backup domain controllers are capable of participating in the user authentication process, the administrator can’t directly update the SAM on a backup domain controller.
Instead, any changes that an administrator makes, such as adding a user account or changing an account policy, go directly to the SAM on the primary domain controller. The primary domain controller then informs all of the backup domain controllers that a change has taken place. At their leisure, the backup domain controllers then download the changes from the primary domain controller. The way that this process works means that in a Windows NT environment, even if you don’t back up all of your domain controllers, all is not lost during a crash situation.
Even though I’m a big believer in backups, let’s take a look at what happens if a domain controller fails in a Windows NT environment and you don’t have a backup. If the server was a backup domain controller, you can simply reload Windows onto the system, and the server will request a copy of the SAM from the primary domain controller. After the replication process is complete, the backup domain controller is as good as new.
But what if the primary domain controller fails? In such a situation, you’d promote a functional backup domain controller to the role of primary domain controller. This backup domain controller would have an up-to-date copy of the SAM database, minus any changes that might have occurred since the last replication cycle. However, because replication occurs frequently, you wouldn’t lose more than a few minutes’ worth of changes. You could then reload Windows onto the original primary domain controller and bring the system up as a backup domain controller. Once the temporary primary domain controller has replicated the SAM database to the damaged server, you can promote it back to primary domain controller, and you are back up and running.
What’s the difference in Windows 2000?
As you can see, Windows NT is very forgiving when it comes to domain controller crashes without backups, at least as far as the SAM database is concerned. However, Windows 2000 is much more complicated than Windows NT, and therefore much less forgiving. While Windows NT uses the single master replication model, Windows 2000 uses the multimaster replication model. In Windows 2000, there are no such things as primary domain controllers or backup domain controllers. All domain controllers are basically treated equally.
In Windows 2000, Active Directory takes the place of the SAM database. When an administrator makes a change to Active Directory, the change could potentially be applied to any of the other domain controllers. Whichever domain controller receives the change first then contacts the other domain controllers and informs them of the change. These domain controllers then request a copy of the change at their leisure.
The big difference between replication in Windows NT and Windows 2000 is that Windows 2000 doesn’t offer one central repository of the current administrative settings. Instead, the most recent changes are scattered throughout the network. If you aren’t in the habit of backing up your domain controllers, this fact may not bother you. After all, if any one domain controller were to crash, you’d only lose any changes applied to that domain controller in the last few minutes, right?
Unfortunately, this isn’t always the case. What many people don’t realize is that the Active Directory is absolutely huge. By default, the Active Directory is really big, but as you add users and computers, the Active Directory grows exponentially. Because of the sheer size of the Active Directory, Windows 2000 is designed to break it into pieces when it gets too big. This means that on medium- to large-size networks, there’s a very good chance that no one domain controller contains a complete copy of the Active Directory. Instead, each domain controller may house a separate chunk of the Active Directory database. So if a domain controller were to crash, you could potentially lose a large irreplaceable chunk of your Active Directory, thus crippling your network. As a result, it’s critical to back up your domain controllers in a Windows 2000 Active Directory environment.
The backup process
Okay, now that you understand why it’s so important to back up the Active Directory, the next question is—how do you do it? The first step in making a backup is to make sure that your backup software is Windows 2000-aware. Many of the backup software packages that were designed for Windows NT will run on Windows 2000, but they won’t back up the Active Directory because they don’t know that it exists. Fortunately, Windows 2000 ships with a backup program that is Active Directory-aware.
For the purposes of this article, I’ll be using this Windows 2000 backup program. You can access it by clicking the Start button and selecting Programs | Accessories | System Tools | Backup. If you’re using a third-party backup program such as BackupExec, the actual procedure may be different, but it should be similar enough that you can follow along without too much trouble.
When the Backup program loads, select the Backup tab to view a list of resources you can back up. Navigate through the list of resources, and you’ll see that beneath My Computer is a list of local drives and an object called System State. If you select System State, you’ll see several subcomponents, as shown in Figure A.
|The System State contains Active Directory and several other components.|
As you can see in the figure, Active Directory is just one of the components included in the system state. However, you might have noticed that the check box next to each component is grayed out. The reason for this is that the system state components usually can’t be backed up individually. In most cases, the components in the system state rely on each other to function. Therefore, it would be pointless to back up any one of them individually since that component would be worthless without the other system state components. If your system state components differ from the ones in the figure, don’t worry about it. The components included in the system state vary greatly depending on the configuration of your server.
Right now, you may be wondering why I said that backing up and restoring the Active Directory was a little complicated when all you have to do to back up the Active Directory is select the System State check box before you begin your backup. However, the complexities come during the restore process.
Preparing to restore Active Directory
As its name implies, Active Directory is constantly active. And as you probably know, you can’t restore an open file. Therefore, before you can restore Active Directory, you have to make sure that it isn’t in use. To do this, you’ll have to boot your system into what’s known as Active Directory Restore Mode. I’ll explain how to do this a little bit later, but for now, I want to familiarize you with the restoration process.
Once you’ve booted into Active Directory Restore Mode, you’ve got a choice to make. You can either perform an authoritative restore or a nonauthoritative restore. To understand what this means, you’ll have to remember the replication process that I discussed earlier.
In a Windows 2000 environment, administrative changes to the Active Directory can be applied to any domain controller. An authoritative restore tells Windows that you don’t care what’s on any of the other domain controllers; The settings you’re about to restore are the correct settings. You have to be extremely careful doing an authoritative restore because it can and usually does overwrite changes that have been made to the Active Directory since the time of the backup.
A nonauthoritative restore works a little bit differently. When you perform a nonauthoritative restore, all of the Active Directory settings stored in the backup are restored to the failed domain controller. However, all Active Directory settings contain a sequence number. After the restore process completes, Windows will begin checking the other domain controllers for any changes with sequence numbers that are more recent than those contained in the current copy of the Active Directory. If newer settings are located, they will be downloaded. These settings may overwrite some of the settings you restored.
Unfortunately, there’s no firm rule as to when you should use each type of restoration. I suggest using an authoritative restore when the backup is less than 24 hours old and you haven’t made any major administrative changes since the time that the backup was made. I recommend using a nonauthoritative restore in all other situations.
The restore process
To restore the Active Directory from backup, reboot the server. When you see the boot menu, press the [F8] key. You’ll now see a menu with several choices. Select the Directory Services Restore Mode option and press [Enter]. When Windows boots, log in using the local administrator’s account. (You can’t access the network because the Active Directory is offline.) You can now restore the Active Directory through the normal restore process. Just be sure to restore the system state data. I should point out that Windows is designed to prevent you from restoring system state data that’s older than 60 days.
You’ve just completed a nonauthoritative restore process. When the restore completes, reboot the server. Windows will go through several steps to make the Active Directory consistent and will then boot normally.
If you’d rather perform an authoritative restore, first do a nonauthoritative restore. But when the restore completes, don’t reboot the server into Normal mode. Instead, go back into the Directory Services Restore Mode. When Windows boots, log in using the local Administrator’s account. Now, enter the following commands at the Run prompt:
Of course, you can also do an authoritative restore of an individual subtree. To do so, use this command set:
RESTORE SUBTREE OU=…,DC=…
Your network is only as reliable as your last backup. Chances are you regularly back up your network’s data files but backing up your network’s Active Directory is critical, as well. In this article, I explained the procedure for backing up and restoring the Active Directory using the Backup tool included in Windows 2000.
Have you had to restore Active Directory?
We look forward to getting your input and hearing your experiences regarding this important topic. Join the discussion below or send the editor an e-mail.