Letters to the Editor

EDITOR'S NOTE: Windows & .NET Magazine welcomes feedback from readers about the magazine. Please send comments to letters @winnetmag.com and include your full name, email address, and daytime phone number with your letter. We edit all letters and replies for style, length, and clarity.

Thanks for the Nuts and Bolts
Sean Daily's article "Repairing and Recovering AD" (September 2002, InstantDoc ID 25957) was good. Not enough articles are written about this topic, and much of the writing focuses on the fun stuff, such as new features, rather than the nuts and bolts of making the technology work. We just went through a disaster-recovery exercise and did most of the things that Daily mentioned in his article. I wish we had had the article before we started.

Even with Microsoft's support, we weren't able to fully restore an Active Directory (AD) server if the NICs were different than that of the server we restored to. Restoring to the same server or an identical server was a snap and followed the steps outlined in your article. But in a disaster, you usually wouldn't restore to identical hardware.

I restored from one server to a newer model that had different NICs. I almost had the machine running. One glitch was that I could set the Ethernet address and netmask, but when I opened the dialog box a second time, the system was set to DHCP. I changed the address and closed the box, and the address would remain changed until I rebooted the server. Rebooting reset the address again.

I tried restoring at home on another system and found that if the NIC cards aren't the same, the registry isn't updated and confusion results. I worked with a super Microsoft support person who concluded that no one is exactly sure what registry keys are affected when you do a system state restore. I would be interested to know whether someone has done a system state restore of an AD server from one vendor's server to another vendor's server. Did we just miss something, or is restoring Windows servers to dissimilar hardware a problem?

—Edward Cheadle
edward.cheadle@benlife.com

Thanks for sharing your experiences. I, too, have run into some of the problems you mentioned regarding system state restores, and I've also found the Microsoft documentation about this topic to be insufficient. Restoring to different hardware is always tricky, particularly with domain controllers (DCs). You might find the following Microsoft articles helpful: "How to Move a Windows 2000 Installation to Different Hardware" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q249694), "How to Move a Windows XP Installation to Different Hardware" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q314070), and "How to Restore a Backup to a Computer with Different Hardware" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q139822). I also addressed the hardware problem in "Recover Crucial Data from a Win2K Server" (June 2002, InstantDoc ID 24813). And Paula Sharick compiled tips in "A Disaster-Recovery Reference List," (http://www.winnetmag.com, InstantDoc ID 22517).

—Sean Daily

Ensuring that Deleted Data Stays Deleted
In "Win2K Disaster Recovery" (September 2002, InstantDoc ID 25954), Ed Roth described how to restore a system by using a normal backup and a differential backup. I'm not familiar with the NTBackup program, but I don't think it's fundamentally different from other backup programs (we use Computer Associates'—CA's—ARCserve). After you restore a normal backup and a differential backup, the system might not be an exact copy of the system before the crash. Files that were deleted after the normal backup and before the differential backup will be on the system after the restore operation. This reintroduced data could be a real problem if your software relies on time-stamped files. To solve this problem, you should generate a complete filelist right before the differential backup. After restoring the differential backup, you should compare the restored filelist with an actual filelist. Another solution is to use object auditing and check the Security logs for deleted objects.

—Kees Schouten
kschouten@dcoalkmaar.nl

You make an excellent point. Sometimes we focus so much on not losing any data that we don't think about intentionally deleted files and the repercussions of reintroducing them. I should have mentioned this problem in the article.

—Ed Roth

After reading Mark Weitz's "Clustering Software" (September 2002, InstantDoc ID 25951), I have a cluster server question. I teach at a community college, and we're interested in implementing a two-node server cluster in our teaching lab. We don't have the budget to buy a turnkey cluster solution but want to construct a cluster from standard parts: two tower PCs and a shared RAID unit. Can you recommend resources that explain in detail how to construct a two-node cluster from base units? Connecting the nodes to a common RAID subsystem is an unknown step for me.

—Phil McCue, MCP
phillip.mccue@nhmccd.edu

You can build your own cluster configuration, but if you plan to use Microsoft Cluster Service, Microsoft will support only complete turnkey solutions listed on its Hardware Compatibility List (HCL—http://www.microsoft.com/hwdq/hcl/search.asp). In addition to complete turnkey solutions, the HCL also lists components that passed Microsoft's Cluster Component Candidate testing. Microsoft intends for only OEMs to use this list; the company will not support your homebuilt cluster even if you construct it from approved parts. If you don't mind forgoing Microsoft support, however, you might want to use this list as a starting point. I'm not aware of any references for constructing your cluster, but the component vendors on the HCL might be able to provide the guidance you need.

If you need a fully supported solution, you might be better off with one of the clustering products I mentioned in the story. NSI Software's Double-Take for Windows, for example, doesn't require a shared storage array and, according to the vendor, will work with any Windows servers. This type of approach should simplify your cluster configuration and might be cheaper because you won't need cluster-aware versions of your applications.

—Mark Weitz

FASTFACT
27% of respondents to a recent Windows & .NET Magazine Instant Poll said their organizations planned to support Windows NT 4.0 machines beyond 2004.

OOPS
In "Best Storage Products" (Windows & .NET Magazine's Readers' Choice, September 15, 2002), the photo that accompanied the section about Quantum's Snap Server was incorrect. We apologize for any inconvenience this error might have caused.

End of Article