Daily Answers - 06 Sep 2000

Several dozen of my company's Windows NT Workstation 4.0 systems perform slow file transfers. The slow performance occurs only when a user uploads a file from a slow PC to another system. Downloads to a slow PC perform at the expected speed.

I'm convinced this problem is NT-related because I ghosted an image from a slow PC to a healthy PC, and the healthy PC became slow. To rule out any router, switch, network, or server problems, I connected a slow PC to a healthy PC with a crossover cable, but the problem remains. Do you have any idea what is happening?

A few potential causes come to mind. The first possibility is that your network adapter driver is incompatible with your NICs' firmware version or is simply buggy. Download and install the most recent driver for your NIC. If you're already using the most recent driver, try using an earlier one (e.g., the driver that NT provided, if one exists).

A second possibility is that the network adapter is defaulting to full-duplex mode instead of half-duplex mode. Often, enabling full-duplex mode on adapters—even when the network configuration (i.e., switches or NICs) supports it—actually reduces performance. In fact, I recently encountered a similar situation on my network. The solution was to disable full-duplex mode on both my switch and my network cards. I recommend you hard-code the network adapters—and the switches, after you reconnect them—for half-duplex mode, then retry your throughput tests.

A third (and less likely) potential cause of your problem is related to interframe spacing (IFS), or interframe gap. This problem can occur with certain 100Mbps NICs on NT 4.0 networks. Interframe gap is the amount of time a workstation waits before attempting to transmit on the wire. When a network adapter driver's default settings configure the adapter to use an interframe gap smaller than the IEEE 802.3 specification of 9.6 microseconds, a high rate of early collisions (thus, slower network performance) can result. Some network adapter drivers have settings that let you modify the interframe gap—either by configuring the driver in the Control Panel Network applet or in the Registry. Check with your NIC manufacturer for details about your card. For more information about this problem, see the Microsoft article "High Rate of Collisions on 100-MB Networks" (http://support.microsoft.com/support/kb/articles/q169/7/89.asp).

I want to enhance name-resolution performance on my LAN clients. Of the various WINS node types—B, P, M, and H—which is the best type to use?

For WINS-enabled clients (i.e., clients that have one or more WINS servers configured in their TCP/IP stacks, either manually or through DHCP), the default node type is H-node. Non-WINS-enabled clients default to B-node name resolution, which makes exclusive use of broadcasts in lieu of point-to-point queries to resolve names on the network. In general, H-node name resolution is best on larger networks because it reduces the amount of broadcast traffic on the network.

One notable exception to this rule involves clients on a smaller LAN (e.g., a branch office) wherein the WINS server resides across a WAN link. In such a scenario, I recommend configuring the clients on each of the smaller branch-office LANs to use a third type of name resolution: M-node. With M-node name resolution, the WINS client name resolver queries (i.e., by broadcasting) for names on the local LAN before querying to the remote WINS server. This type of name resolution can reduce WAN traffic and improve name-resolution performance. For more information about WINS node types, see "Navigating Name Resolution, Part 1," June 2000, "Navigating Name Resolution, Part 2," July 2000, and L.J. Locher, "Secure Channels in NT 4.0," February 2000.

The Windows NT rdisk.exe utility for making Emergency Repair Disks (ERDs) seemed to disappear from my system after I upgraded to Windows 2000. Are ERDs no longer necessary in Win2K? Also, I've been hearing a lot about System State backups in Win2K. Have System State backups usurped ERDs?

ERDs are alive and well in Win2K, but Microsoft has moved the utility for creating them to a new location. Instead of using a separate executable file (rdisk.exe) to create ERDs, you now use ntbackup.exe within Win2K to make them. Go to Start, Programs, Accessories, System Tools, Backup, or use Start, Run, and type

ntbackup

Click Emergency Repair Disk on the Welcome tab, which Figure 1 shows.

Think of a System State backup as an enhanced ERD that contains much more information. Unfortunately, because of their large size, System State backups don't fit on 3.5" disks. (They can exceed 200MB on many systems.) However, you can save System State backups to a hard disk or removable disk such as a Zip, Jaz, CD-Recordable (CD-R), or CD-Rewritable (CD-RW) disk.

System State backups, essentially a superset of an ERD, back up a Win2K system's crucial files (e.g., configuration databases, startup files). The contents of a System State backup depend on the type of Win2K machine you're using. For all Win2K systems, a System State backup contains a copy of the system Registry hive files, the COM+ class registration database, and copies of the files necessary for the system to boot (e.g., NT Loader—NTLDR, ntdetect.com, boot.ini). A System State backup also includes system data such as performance-counter configuration files and all files that Windows File Protection (WFP) protects.

On Win2K Server systems, a System State backup contains a copy of the Certificate Services database, and—on domain controllers—a copy of the Active Directory (AD) database (ntds.dit) and the contents of the SYSVOL folder. If the server is running DNS, the System State backup will also include AD-integrated and non-AD-integrated DNS zone information. On Win2K Advanced Server systems acting as cluster members, the System State backup will include a copy of the quorum recovery log file.

To back up System State data, run Ntbackup and choose the Backup tab. In the list of selections in the left pane, select the System State check box, as Figure 2 shows. You can select only System State backup information for a backup job, or you can include it as part of a larger backup that includes local disk volumes. Several third-party backup utilities can back up system state data—for example, Veritas Software's Backup Exec, Computer Associates' (CA's) ARCserveIT, and UltraBac.

Up-to-date copies of System State backups for all of your Win2K systems—just like up-to-date ERDs under NT—are important to have on hand at all times. System State backups are particularly important because Win2K ERDs no longer contain a copy of the Registry—only System State backups do. Therefore, to protect your Win2K system's crucial data, you must use ntbackup.exe or a Win2K-aware third-party backup utility. For more information about System State backups, see Zubair Ahmad, "Backing Up and Restoring the System State," http://www.win2000mag.com/, InstantDoc ID 7664.

Corrections to this Article: