Reader to Reader - June 1997

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