Problems from Configuring the PDC with External RAID
We set up a TCP/IP network that consisted of the latest and greatest workstations and servers.
The workstations run Windows 95 and the servers run Windows NT 3.51, Service Pack 4 (SP4). Two weeks
after we were up and running, the network started locking up, eventually forcing us to reboot the
Primary Domain Controller (PDC). After a couple months of searching the Knowledge Base, talking to
various third-party technical support teams, and removing and reinstalling third-party products, we
contacted Microsoft technical support. I spent several more weeks and tried many solutions with no
success. Finally, the MS support people suggested Knowledge Base article ID Q139320 because I got
the startup event ID 12 and 14 error message, "A stripe set or volume set member listed in the
configuration information is missing," every time I brought the PDC up.
Ftdisk produced these events because of the original configuration of the PDC with an external
RAID box that I later removed (because of incompatibility). The Knowledge Base article suggests
removing the \SYSTEM\DISK key under HKEY_LOCAL_MACHINE subtree, then using Disk Administrator to
re-create the DISK key with the current information, and reassigning the drive letters. I highly
recommend writing down or printing a screen capture (Ctrl+Print Scrn) of your Disk Administrator to
ensure that the volume letters are reassigned properly.
The good news is that we have been up and running now for three weeks with no problems. The
really good news is that people are once again talking to me and I get to keep my job until the next
problem, which I may not be able to solve.
—Jim Avazpour
vazsys@sound.net
No-Script Group Migration
Situation: You need to move or mirror a very large local group from one server or domain to
another server or domain on a Windows NT network. But keying in the data to look up user domains and
IDs would take days. Microsoft and high-level support people say you can't automate this migration
without writing lengthy scripts, but I've found a way.
To add a local group from one server and domain to a completely different server and domain or
to a server in the same domain, go to the command prompt and locate the name of the group you want
to copy. For example, you can key in
net localgroup <enter>
to get a list of all local groups on a server. Then, type
net localgroup <groupname> >localgrp.txt
where groupname is the name of the group you identified from the list. This command
writes the output to a .txt file that has three columns. Then, pull up the .txt file in Excel or
another spreadsheet and parse the three columns into one column, left justified, or manually move
the columns to the left. The next steps require that the usernames be in a column.
Next, go to the new server and domain you want to transfer the group to. Create a new group
name (it can be anything). Then open the localgrp.txt file in Notepad, select and copy all
usernames, go to NT's Add User dialog box, and paste the list by pressing Shift+Insert.
There's your list. Select OK and then OK again. You now have successfully inserted huge numbers
of users and domain IDs in one shot. I added more than 700 in one copy and paste operation. As a
bonus, I had created a master list of users in the group, and I can use it for maintenance and
sorting out security issues. You can also move large local groups remotely if you have set up trusts
on your domains.
I know people need this capability frequently. My solution is a great trick that saves a lot of
time and heartache for this mundane task.
—Jeff Hass
jhass@netcom.com
Repairing the Boot Sector
I came across a Windows NT workstation that was infected by the AntiEXE virus, which affects the
boot sector. This infection happened because the user performed a Shut Down, Restart with a floppy
in the disk drive. Using the NT Repair facility did nothing to fix the problem. I decided to try the
old DOS trick of rewriting the boot sector using FDISK /MBR. Then I ran the NT Repair facility to
fix the boot sector. This solution worked like a champ.
—Steve Hong
steve.hong@aexp.com