Networking

Restoring servers from an image file

Bringing servers back online after a disaster can be a nightmare when dealing with domain controllers or Exchange 2000. Brien Posey underwent such a nightmare and is here to keep you from suffering your own.


Recently, I wrote a TechProGuild Daily Drill Down, “Delving into Windows 2000,” in which I discussed the way that I use image files to back up the configuration of the servers on my test network. However, I recently learned that you have to jump through several hoops to properly restore a domain controller or an Exchange 2000 Server from an image file. In this Daily Drill Down, I’ll explain why this is the case.

Why use an image file?
In case you missed my original Daily Drill Down, I explained that my personal computer network is actually two different networks that are bridged together. One of the networks is used for production machines, such as the machine that I use to write articles, the server where I save all of my data, and my firewall server. The other network consists entirely of test machines. I use these test machines to test various configurations as I write articles about them. Needless to say, since I constantly play around with the configurations of these machines, it doesn’t take them long to get messed up. In the past, I would manually reinstall Windows and then restore a backup from tape as a method of reloading my applications and other configuration options.

However, after using this time-consuming and sometimes unreliable method a few times, I decided to search for a better method of reloading my servers. What I came up with was a method that involved using Symantec’s Ghost 2001 to create a CD that contained an image file of the server.

Up until recently, the method always worked very well. I used the software to create a set of image CDs for each server. Anytime that I needed to reload a server, I would simply use the CD to do so, and I would have a completely restored system in about 15 minutes. The method seemed like a gift from God, at least until yesterday, anyway.

My disaster
Yesterday, I was trying out a new procedure and crashed a server. The crash was so severe that Windows wouldn’t even boot. At first, I didn’t think twice about the problem. I simply booted the system from my Ghost 2001 boot disk, inserted the first CD, and began the restore process. When the restore completed, Windows booted right up, and everything looked normal. However, when I looked at the machine a little closer, I noticed that the Exchange 2000 System Attendant service hadn’t started. I tried starting the service manually, but the service still wouldn’t start.

I decided to check and make sure that the network was functioning properly. I went into My Network Places and decided to browse the entire network’s contents. All of the other servers were showing up in the browse list, but anytime that I double-clicked on a domain controller, I received an error message stating that access was denied. I could access the contents of member servers with no problems, though. At this point, I realized that I had some sort of communications problem between domain controllers.

The problem with domain controllers
After doing some research, I discovered that all Windows 2000 computers have a machine password associated with them. The machines use this password anytime that they attempt to communicate with each other. A copy of the machine’s password is stored locally, and another copy is stored in Active Directory. When a domain controller tries to communicate with another domain controller, it submits its local password to the machine that it’s trying to communicate with. The other domain controller compares the password that it has just received with the password that’s stored in Active Directory. If the passwords match, then communications begin. If the passwords don’t match, the user receives an access denied message.

After reading this, I had two questions on my mind. First, how did the password get out of sync? Second, how do you reset a machine password? Apparently, the machine passwords change every so often. According to a friend at Microsoft, Active Directory is a dynamic environment and any backups that involve copies of Active Directory and are over 60 days old are considered to be invalid. However, this doesn’t mean that you can’t use an old image file to get the machine up and running again. Even with the machine passwords and Active Directory information out of sync, making the machine functional again is no big deal, once you know the trick.

Normally, when a machine password gets out of sync, you can resynchronize it by going into the Active Directory Users And Computers console and navigating through the Console tree to the Computer tree. When you do, you’ll see a list of computers in the column on the right. Simply right-click on the computer that you need to resynchronize and select the Reset Account command from the resulting context menu. Unfortunately, this technique doesn’t work for domain controllers.

Figure A
You can reset a computer account by right-clicking on the computer and selecting the Reset Account command from the resulting context menu.


To make a domain controller functional again after it’s been restored from an image file, you have to use a utility called NETDOM.EXE. Unfortunately, this utility isn’t installed with Windows 2000 by default, so you’ll have to install it before you use it. Before I show you how to install and use this utility, I should point out that there’s a lot of inaccurate information about this utility floating around the Net. The method that I’m providing is very different from some of the methods that I’ve read about, but it’s been thoroughly tested and works well. I should also point out that the syntax of this command may at first appear to be full of typos, but I assure you that what looks like a typing error is indeed the correct syntax.

With that said, let’s get started with the installation process. To install the NETDOM.EXE utility, insert your Windows 2000 Server installation CD and wait for the splash screen. On the splash screen, select the option to explore the CD’s contents. Next, navigate to the \Support\Tools folder and double-click the Setup icon. When you do, you’ll see a wizard that’s used to install the Windows 2000 Support Tools. The wizard is pretty much self-explanatory. Once you’ve completed the wizard and installed the Windows 2000 Support Tools, reboot your server. When the server reboots, it’s time to resynchronize your domain controller.

For the resynchronization process to work, you must run the NETDOM.EXE utility locally from the server that you’re having problems with. To do so, select Programs | Accessories | Command Prompt from the Start menu to open a Command Prompt window. When the Command Prompt window opens, enter these commands. If you installed the Windows 2000 Support Tools in a drive other than C: or in a different path, substitute your machine’s file location for the one that I’m using. Once the process completes, you’ll have to reboot your server. If you have difficulty getting the command to work, try rebooting and then entering the command again.

In the NETDOM command, everything in lowercase represents a variable. Here’s a breakdown of what the variables point to:
  • ·        Domain_controller_name: The name of another domain controller that’s in the same domain as the domain controller that you’re working with
  • ·        Domain_name: The name of the domain that you’re repairing
  • ·        Administrator_name: The user ID of the domain administrator account

For example, in my case, I was repairing a server named ANIMAL. It existed in a domain called POSEY.COM, and I was trying to communicate with a domain controller called CARTMAN. In my case, the command looked like this.

Bringing Exchange 2000 back online
As you can see, resynchronizing the domain controllers is a big job. However, in my case, the Exchange services wouldn’t start even after I had resynchronized the domain. In my particular case, the Exchange System Attendant service wouldn’t start. Of course, none of the other critical Exchange services will start unless the System Attendant is running.

On my server, the problem ended up being that the server I had restored was originally the global catalog server. After the restore process, it had lost its global catalog server status and none of the other Exchange servers had assumed the role of global catalog server.

To flag the server as a global catalog server, open the Active Directory Sites And Services console and navigate through the Console tree to Active Directory Sites And Services | Sites | Default First Site Name | Servers | your server. When you select the server, you’ll see something called NTDS Settings appear in the column on the right. Right-click on NTDS Settings in the column on the right and select the Properties command from the resulting context menu. When you see the NTDS Settings Properties sheet, select the Global Catalog check box on the General tab. Now, click OK and reboot the server. After the first reboot, I had to manually start the Exchange services, but they did start.

As you can see, fixing the Exchange problem was easy. The difficult part of the problem was figuring out why the Exchange services wouldn’t start so that I could fix the problem. If you’ve had a problem with Exchange 2000, you might have noticed that Exchange 2000 doesn’t write much diagnostic information to the event logs. There is a way, however, to increase the logging level so that you can diagnose a problem with less difficulty.

To change the logging level, open the Exchange System Manager and navigate through the Console tree to your organization | Administrative Groups | your group | Servers | your server. Now, right-click on the server and select the Properties command from the resulting context menu. When you see the server’s properties sheet, select the Diagnostic Logging tab. On the Diagnostic Logging tab, you’ll see a list of the Exchange Services, as well as the level of logging that’s associated with the service. Select the service, set a higher level of logging to go with the service, and click OK.

At this point, try starting the failing service again and then check the event logs. There should now be something in the logs to give you a clue as to the cause of the problem. Remember that every error that appears in an event log has an ID number. Many times, you can go to Microsoft.com and search the Knowledge Base for the event ID number. Without the increased logging level, it would have taken me much longer to find and cure the problem.

Conclusion
Creating an image file of your server’s configurations provides you with a method for bringing a server online quickly after a disaster. Unfortunately, simply restoring the image doesn’t quite get the job done if you’re working with a Windows 2000 domain controller or an Exchange 2000 Server. In this Daily Drill Down, I discussed some procedures for bringing these types of servers back online after a disaster.

Editor's Picks