Ask Dr. Bob Your NT Questions - 15 May 1999

SEND US YOUR TIPS AND QUESTIONS.
You can also visit Bob Chronister's online Tricks & Traps at http://www.winntmag.com/ forums/index.html.

A friend recently asked me to troubleshoot a software upgrade. She was running Microsoft Excel 5.0, WordPerfect 6.0, Lotus SmartSuite, and Windows 3.1 on top of PC-DOS, and she wanted to upgrade to Windows 98. She employed a Microsoft-certified guru (i.e., a Microsoft Certified Professional—MCP) to perform the upgrade. The guru had no idea how to upgrade a PC-DOS system to Win98, so he called Microsoft for help. After he converted my friend's system to regular DOS, he performed the Win98 upgrade without a problem. However, he couldn't get WordPerfect 6.0 to load on the upgraded system and had to install Corel WordPerfect 8.0. He also had trouble loading Excel; the program told him he needed to load the share utility. When the guru told my friend he needed to research the share problem and would get back to her, she called me in frustration. I recognized the problem's cause immediately: Excel 5.0 requires that you load the DOS utility share.exe during the boot process. I upgraded my friend's system to Microsoft Office 97 because it doesn't require you to load the share utility. Her system now runs fine. The process took 15 minutes. The moral to this story is simple: Microsoft needs to make hands-on experience a certification requirement.

Q: I'm concerned about eliminating static mappings in my WINS database. One of my primary concerns is shutting down replication while I remove the mappings. How can I avoid stopping replication?

In general, you use static mappings only for clients that can't register with the WINS database. However, I've used static mappings when I set up trust relationships and I didn't want to deal with LMHOSTS files. The problem with removing static mappings is that you must usually stop the WINS server. (Using the Migrate On feature in WINS Manager doesn't require stopping replication, but this feature might not remove all static entries.)

To eliminate static mappings, you can use one of two methods that don't require you to stop WINS replication on your network. Both methods require a Registry change on all WINS servers.

The first method uses a new, temporary WINS server. To remove static entries, perform the following steps.

1. Install a new WINS server on your network. This server will contain only static mappings, and no clients will register with the server.
2. Find and record all the static entries, including NetBIOS names and record types, that you want to delete from all WINS servers.
3. Add each of the entries from Step 2 as static entries on the WINS server that you created in Step 1.
4. Configure the new WINS server to replicate the static entries to all other WINS servers. (Ensure that the replication occurs on a WINS server that reaches all other WINS servers.)
5. Using WINS Manager's Mappings menu, delete all the static mappings at all the original WINS servers.
6. After the static entries fully replicate, edit the Registry on all production WINS servers. (As always, edit the Registry carefully.)
7. Start a Registry editor, and go to the HKEY_LOCAL_MACHINE\SYSTEM\
   CurrentControlSet\Services\WINS\
   Partners Registry key.
8. Select Add Value from the Edit menu, and use the following parameters: Value Name is PersonaNonGrata, Data Type is REG_MULTI_SZ, and Data is the IP address of the new WINS server you created in step 1 (The PersonaNonGrata Data field has a limit of 99 IP addresses. IP addresses beyond 99 will probably prevent the WINS service from starting. The default is none.)
9. After enabling the value, stop and restart the WINS service. This Registry value specifies the IP addresses of WINS servers whose records the local database shouldn't receive during replication.
10. After adding the PersonaNonGrata Registry value and restarting the WINS service, you must perform the following steps on all WINS servers except the WINS server you created in step 1.
11. Using WINS Manager, select Show Database from the Mappings menu.
12. Click the new WINS server in the Select Owner list.
13. Click Delete Owner to delete all the records the new WINS server owns.

The Registry change you made prevents the replication of entries back before the new WINS server deletes the entries from the other WINS servers. You can then remove from replication the WINS server you created in step 1 and disable or remove the WINS service.

The second method uses the ConsistencyCheck Registry key. If you want to use this method, all your WINS servers must run Windows NT Server 4.0. The method uses a lot of bandwidth and is inappropriate for slow WAN links. To use this method, perform the following steps.

1. Delete the static mapping from the owning WINS server.
2. Before the next replication, perform a consistency check by using winscl
   .exe from the Microsoft Windows NT Server 4.0 Resource Kit or by using the ConsistencyCheck Registry key.
3. Under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
   Services\WINS\Parameters Registry key, you can create the ConsistencyCheck subkey if you want WINS to periodically perform database consistency checks. Use the following values: Value Name is MaxRecsAtATime, Data Type is REG_DWORD, and Range is 1000 to the total number of records (decimal; default is 30000).

The ConsistencyCheck subkey stipulates the maximum number of records that will replicate in one cycle. WINS performs consistency checks on the records of each owner WINS server (i.e., the WINS servers that own the replicated records). After checking an owner WINS server, the local WINS server either continues to the next owner WINS server or stops. The local WINS server determines this process by the MaxRecsAtATime value.

Q: What is tombstoning in WINS? How does it differ from database deletion?

In simple database deletion, the administrator deletes WINS records from the host WINS server, but other WINS servers aren't aware that the administrator deleted the records. In tombstoning, the administrator flags records with tombstones, marking them for deletion from the host WINS server. Most important, the server's database doesn't delete the flagged records immediately. The records the administrator marked with tombstones remain, and the host server replicates the records to other WINS databases. After the host server replicates the records to the other WINS servers, the servers remove the records during subsequent removal operations on each server. The following steps detail the sequence of events.

1. On a host WINS server, an administrator marks a record with a tombstone to change the record's status to inactive. WINS treats records marked with a tombstone as inactive, and the server no longer uses them. The WINS server responds only if the administrator reregisters the records. The server doesn't recognize any queries on the names of records marked with a tombstone.
2. The WINS server with the marked records replicates the records as tombstones to other WINS servers during subsequent replication cycles. The host WINS server doesn't forcibly and immediately remove the records marked with a tombstone from every WINS server, but waits for an Extinction interval to pass. You set the Extinction interval in each server's WINS database properties. After the Extinction timeout, the WINS servers update their databases and no longer use the records.
3. The records become extinct on all replicated WINS servers, and the WINS servers eventually remove the records. After all the WINS servers receive the records marked with a tombstone and a preset Verification interval, a scavenging operation removes all the marked records from the database.

Q: I'm having problems moving an existing Windows NT installation from an EIDE hard disk to a SCSI hard disk. I've previously moved NT installations from one EIDE disk to another EIDE disk without any problems using PowerQuest's DriveCopy software. Can you shed some light on this situation?

The system drivers that NT uses for EIDE hard disks and SCSI hard disks are different. I suggest you reinstall NT on the new disk.

You can try to fix the system. However, you need to use these methods at your own risk. Start by copying NT from the EIDE disk to the SCSI disk and reinstalling the software to the same directory. If the installation process sees the old directory, a reinstallation will provide the proper drivers in the new directory. I have used this procedure with some success. Alternatively, you can perform a fresh installation of NT on the new disk, back up the old disk to tape, and restore the old disk to the new disk with the exception of the system hive, which contains all the old hardware settings.

Q: I installed Windows NT on a Digital HiNote Ultra 2000 notebook. I can't get the system to register on the network, and I get a No domain controller can be found error message. A Digital support technician told me the message was meaningless. However, I still can't access the domain. Can you help?

The error message you received can be benign, but it often indicates a general logon failure and denial of network resources. The Ultra 2000 has a built-in Xircom network chipset. You are receiving the error message when you try to connect to the network because the driver for the network chipset is not properly initializing the built-in network adapter. To resolve this problem, you can boot into NT and perform a software reboot that initializes the network adapter and lets you access the network.