Recovering a Windows NT Server Running NDS Account Management 2.1
Articles and Tips: article
Novell SysOps
Vikas Mahajan
Novell SysOps
01 Jun 2001
Imagine that it's late on a Sunday night and you've just installed Microsoft's latest NT service pack on your Primary Domain Controller (PDC). The files have finished copying and the server is waiting for you to click the Finish button. You hesitate momentarily as you wonder if you remembered to update your Emergency Repair Disk prior to installing the service pack. Oh well, you think, this is only a service pack. No harm can come from the update, right? So you click the Finish button, the server reboots, then promptly gives you a blue screen when you try to login.
Following your standard troubleshooting procedures, you take the option to use the last known good profile as the server reboots. Again, it dies a horrible blue death when you try to log in. You run through a few other things, but now the server isn't even able to boot. You've got roughly 11 hours before your users come back in Monday morning and your PDC is officially toast. What are you going to do?
Backup Domain Controllers Can Be Handy
If you've got at least one Backup Domain Controller for that domain, you're OK. All you need to do is go to that BDC, run Server Manager, then promote it to be the PDC. From your users' point of view, everything's back to normal-they can login, change their passwords, add machines, and so on. All you need to do is rebuild your PDC, this time installing it into your domain as a BDC, patch it to the current level-- the current known good level that is, and re-install the NDS AM 2.1 software on it. Then, if you'd like, you can promote it to be the PDC.
But what do you do if you don't have a BDC for your domain? Have you lost your NT user IDs? Will you have to remember all the global groups and what rights they had to what areas of your network? Will you have an NT domain object forever lost in your tree?
Fortunately, as long as you have a current Emergency Repair Disk (ERD) for your PDC, you can recover and relink it to NDS even if you have to build the server from scratch. This is the procedure we're going to cover here. Before we go over the recovery procedure though, let's talk about the history of the NDS Account Management product.
History of NDS Account Management
Novell Directory Services Account Management 2.1 started its life as NDS for NT 1.0. NDS for NT 1.0 introduced the concept of redirection and allowed you to migrate your NT domains into NDS. The domain controllers would then pass through to NDS any domain-based authentication requests they received. This version only supported IPX, as NetWare 5.0 and NCP/IP (NetWare Core Protocol services over IP) had not shipped yet.
The next version, NDS for NT 2.0, included some much needed enhancements, the most important being the ability to host an NDS replica on an NT server. This enhancement reduced the need to have the domain controllers next to NetWare servers and improved performance for remote sites that had slow WAN links to the corporate office. However, this version still operated in IPX-only mode. NDS for NT 2.01 added the ability to operate in an IP-only mode.
NDS Corporate Edition was the next version, and it is probably better thought of as a completely new product. It had the core NDS for NT product, with a few enhancements, but was bundled with NDS eDirectory for Solaris and Windows NT (also known as NDS on NT). The biggest change in this version from an NDS for NT point of view is the ability to operate without having a NetWare server available.
This brings us up to the current version: NDS Account Management 2.1, which includes the eDirectory product for Windows NT, Windows 2000, Linux, Solaris, and Compaq's Tru64. Also, version 2.1 includes a greatly improved domain cache when running in a Windows NT environment. The entire NT domain can be cached locally on each domain controller, thus reducing--and in some cases, eliminating--the need for a local NDS replica.
Recovering a Single Domain Controller
With all these enhancements and improvements came increased complexity in recovering from a crash. It's no longer sufficient to just insert the latest backup tape into the server and restore data. But it's still not that difficult to recover your crashed PDC running NDS Account Management 2.1, assuming you have the right items available.
At a minimum, you should have the Windows NT 4.0 installation CD (and know where it's located so you don't have to start the "frantic search" exercise we all know and hate). You should also have the hardware-specific drivers you need for your server, and a current Emergency Repair Disk (ERD).
When creating the ERD, you should run "rdisk /s" from a command prompt to make sure you've got a copy of the security files and registry entries. The ERD contains the HKLM\Security\NTMIGRATION key which holds the location of the NT domain object in NDS as well as the password the domain controllers use to connect to NDS. If you don't have a current ERD, then a copy of the C:\WINNT\SYSTEM32\NETWARE\NDS4NT.DAT file will work in its place.
Assuming the PDC is completely crashed and cannot be restarted, here are the steps you should follow to completely recover your PDC.
Rebuild the server as a PDC in a "dummy" domain. This domain can have the same name as your production domain, but it's not required. Just to keep things simple though, I'd recommend using the same domain name and server name. Do not use the ERD at this time. This installation should be a "clean" installation.
Patch the server to the same level as it was before it crashed. Do not install Client32 on the server at this time.
Once the server has been patched, rerun the NT setup (in most cases, this entails booting from the CD) but this time, select the "Repair a damaged Windows NT 4.0 Installation" option.
When asked what parts of the installation you want to check, select only the registry.
Two screens later, you'll be asked what parts of the registry you want to check. Select only the Security Profile/SAM database option. This will restore the HKLM\Security hive of the registry. After the registry has been restored, reboot the server when prompted.
After the server has rebooted, log in as the administrator. You'll need to use the administrator ID and password that was current when you created your ERD (since the SAM was restored).
Copy the entire contents of the NDS AM 2.1 CD to a folder on a local hard drive. Once it's copied over, go into the \NT\i386 directory and find SETUPNW.EXE. Once you've found it, change the name to NDSSETUP.EXE.
Now, go into the \NT\i386\GOODIES directory and run the NDS4NTER.EXE utility. It won't know where to find the NDSSETUP.EXE file, so you'll need to point it to the \NT\i386 directory.
This installs Client32 on your computer. While you can install it using the Standard method, we recommend you do a Custom installation and select only the options you want, particularly which protocol to use. If you're in an IP-only environment, select IP-only. If you still talk to NetWare 4.x servers, select IPX-only, even if you have IP-capable NetWare 5.x servers on your network.
After the server has rebooted, run SETUP.EXE from the root of the CD-ROM drive (or from the directory where you copied it to the server). This will install the necessary files for NDS AM 2.1 to function, including the Novell version of SAMSRV.DLL. Once the server has rebooted (again), you should have a fully functional PDC that is once again talking to NDS.
If you start to receive -355 or -356 errors in NDS when you use ConsoleOne to manage the domain, make sure that time is in sync between the PDC and the master server of the replica where your NT domain object is located. If the time is not in sync, change it on the PDC to match the NDS servers and then run DSREPAIR -RD on the NDS server. Better yet, use the TIMESYNC.EXE utility found in the NDS4NTTB.EXE utility that is available from Novell's file finder, or the Timesync utility that comes with the NT 4 resource kit. This way, you can point your Timesync application to a NetWare 5.x server that's been set up to be an NTP (Network Time Protocol) time server.
Conclusion
Whew! It's an hour or so later and everything seems to be working OK. Users can log in, change their passwords, and add machines in the domain. And it's all thanks to the current ERD you have handy in your fireproof cabinet. Umm, you do have a current ERD, don't you?
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.