Last week was one of those weeks where for every two steps forward, I slid one step backward. If computers had ears, mine would all be wearing ear plugs. My latest lab adventure started when I set out to test Windows 2000 Backup in my mixed-mode network, which has a couple of Windows NT 4.0 domain controllers, an NT 4.0 server running Exchange Server 5.5, two Windows 2000 Advanced Server (Win2K AS) machines, and a couple of Windows 2000 Professional (Win2K Pro) machines. According to the online documentation, Win2K AS knows how to back up an Exchange server. The online documentation doesn't specifically refer to Exchange Server running on NT 4.0, but it does indicate that you can simply check the Exchange icon that appears next to your Exchange server in the Win2K Backup browse list. However, Win2K didn’t recognize my NT 4.0 Exchange Server machine, so I did some research and found out that I needed to upgrade to Exchange Server 5.5 Service Pack 3 (SP3) for Win2K interoperability. Sounds easy enough, doesn’t it?
Because we all rely on our Exchange servers for basic everyday communication, most of us back up the Directory Store (DS) and Information Store (IS) before we perform an upgrade. I couldn’t back up my mail server with Win2K, so I decided to use Ntbackup on one of my NT 4.0 systems to back up the DS and IS, and this is when I started the one-step-backward dance.
I tried the backup with a machine running NT 4.0 SP3, but the procedure kept failing. I started troubleshooting and found two obvious potential causes for the failure. First, because my other NT 4.0 systems were running SP5 or later, I assumed that I needed to update the backup machine to SP5. Second, the Exchange server’s network adapter card started conking out— at least once an hour, and sometimes more often—so network connectivity loss was another potential problem. After I spent about an hour installing SP5 and another half hour downloading and installing a new driver for the network adapter card, I was ready to proceed. But the story’s not over yet, folks.
Every time I started the NT 4.0 backup of my NT 4.0 Exchange server, it failed and displayed the following error message in the Application Event Log (AEL), Event ID 8010 (the error message was identical for the DS and IS backup passes):
"Microsoft Exchange services returned ‘102’ from a call to ‘BackupRead() additional data "
So off I went to Microsoft Support Online. I found an article, Q156715, that exactly described the situation, except for one small point: The article documents the problem for Exchange Server 4.0. The article, which Microsoft updated on February 10, indicates that NT 4.0 SP5 corrects the problem. Not exactly—I had just installed SP5. I ran through the list of bugs that SP6a corrects, but found no mention of an Ntbackup problem with Exchange Server. So, after all this tinkering, I was back where I started.
I was stumped. I searched Microsoft Support Online to no avail and finally decided that the NT 4.0 Ntbackup and Exchange problem had resurfaced and that I was among the first to encounter it. So I took a deep breath and upgraded my NT 4.0 Exchange Server 5.5 to SP3 without a backup. In my experience, Exchange Server is Microsoft’s most robust and reliable product. In the past, all updates have worked properly, and my mail server has never crashed. It never occurred to me that perhaps I’d used up all my luck.
The setup program displayed the error message, "The specified service does not exist as an installed service" when it attempted to start the WWW service during the last phase of the service pack update. That’s right, I don’t have Internet Information Server (IIS) running on my Exchange Server machine. Because of the error message, I wasn’t sure whether the Exchange SP3 update installed successfully. Bravely, I shut down and rebooted the machine, and when I looked at the Internet Mail Connector (IMC) in Exchange Administrator, Exchange gave me yet another error message:
"Extension SMTP could not be loaded, unable to find the .dll file with the correct version number"
The file the event-log record referred to was Icadmin.dll. I returned to Microsoft Support Online and, as luck would have it, I found another article, Q147929, that described the situation. Apparently, Exchange Server has one internal version number for this .dll file, and after the service pack update, the internal version number didn't match the version number of the .dll file that SP3 installed. To correct the problem, the article explained, I had to run Exchange Administrator in raw mode and change the internal version of the IMC to match. To make matters worse, I had this version problem for all of the installed connectors.
Give me a break. How can Microsoft give us a service pack that doesn’t properly update version numbers? Furthermore, how was this error introduced, and why didn’t the test team find it before releasing Exchange Server 5.5 SP3? The problem is so obvious, you’d have to be in la-la land to miss it. Running Exchange Administrator in raw mode is probably no more dangerous than running a Registry editor, but we should never have to take such remedial action as the result of a service pack update.
Of course, there’s more bad news. I attempted to follow article Q147929’s instructions, but the procedure works properly only when you click every Yes, Apply, and Set button in two or three windows. I missed a button the first few times through, so when I examined the internal version numbers, they were same as they were before I made the edits. Aaaaargh. Finally, I clicked all the right buttons and the version number changes took hold. After I made similar changes for the other connectors, exited Exchange Administrator raw mode, and restarted Exchange Administrator, I could see the properties for my connectors.
However, I had burned up 8 hours, I still couldn’t back up the DS and IS with Ntbackup 4.0 SP5, Windows 2000 Backup still couldn’t see my NT 4.0 Exchange server, and I had the ‘102’ error message memorized. After more research, I discovered Microsoft released a bug fix for Windows 2000 Ntbackup (Q253910) on March 1 that deals specifically with Exchange server restore issues, but I couldn't find any mention of backing up an NT 4.0 Exchange server. Don’t you think there should be an easier way? If Windows 2000 backup can't back up an NT 4.0 Exchange server, why doesn’t the online documentation say so? When I refill my reservoir of patience, I’ll tell you how this all turned out. Hopefully, you won’t need earplugs.
