Tricks & Traps: Daily Answers (October 2000)

Article from Windows 2000 Magazine

By Sean Daily

Q: I'm having trouble with my connection speed. I have a new 56Kbps V.90 modem, but I connect at only 28.8Kbps over my MediaOne digital line. Download speed is only 4Kbps. A phone-company technician told me that 4Kbps was the best speed I could expect from my Microsoft OS. If my phone company truly provides a digital, fully capable V.90 cable to my house, can my Microsoft OS connect at 56Kbps?

A: Unfortunately, because of the number of variables in your scenario, pinning down the exact cause of the problem is difficult. However, I can recommend some good places to start digging.

First, rest assured that Windows 2000, Windows NT, and Windows 9x can definitely leverage the full capabilities of a 56Kbps connection. Although Microsoft's OSs certainly have strange quirks and cause mysterious problems, your ISP's comments don't ring true in this case. Think about your problem from a network-throughput perspective: If Win2K can fill a 100Mbps Fast Ethernet pipe (or faster in the case of Gigabit Ethernet), then certainly it can take advantage of the relatively miniscule pipe that a modem connection presents. I doubt very much that your problem is software-related.

Second, the digital line that your phone company provides piques my curiosity. I placed a call to a MediaOne representative, who informed me that—unlike standard connections to the local phone company—your line doesn't go through the old copper lines connecting to your local Regional Bell Operating Companies (RBOC—e.g., Pacific Bell, BellSouth, Bell Atlantic). Instead, your line goes through fiber-optic lines that are part of MediaOne's private network. I asked how this setup might affect your standard modem connections. Theoretically, you should see no difference: You should be able to achieve the same speeds that a regular phone line provides. Despite the enhanced features that MediaOne touts, I still wonder whether this digital line is causing the problem. I recommend that you take your system and modem to a location that uses a regular analog phone line (e.g., a different location in your house, a friend's house) and perform the same tests after connecting to your ISP from the new location. The number of digital-to-analog conversions that exist between the connection's endpoints might be greater than one—a condition that could be contributing to your problem. (See Remote Possibilities, "Unattended RRAS Installations, Part 1," September 2000, for more information about this condition.) If such is the case, a standard phone line might provide a better connection to your ISP's Point of Presence (POP) than your digital line does. Unfortunately, only direct testing can provide any certainty.

Third, modem incompatibilities could be the heart of your problem. Try dialing a different POP at your ISP or another ISP altogether, simply to compare the differences. If problems continue, try a different modem. Such testing will help you determine the root of the problem. If your modem is faster when you use a different number, you have a modem-to-modem problem with the ISP's POP. If the modem is never faster and a different modem works, you might have a firmware problem with your original modem or perhaps have faulty hardware.

Finally, some connection-speed problems are occasionally the result of fallibilities in the test tool—particularly if you're using Microsoft Internet Explorer (IE) or Windows Explorer's woefully unreliable throughput measurements. Although I'm not suggesting that your problem isn't real, faulty measurements could be exaggerating the severity. I recommend using a tool such as DSLreports.com's free upload and download speed-analysis tool (https://www.dslreports.com/stest/). Although this tool is subject to factors such as site, server, and Internet latencies, it can give you a general idea of an Internet connection's performance. The tool also provides two choices of endpoint sites to use during the line speed test—one on the East Coast and one on the West Coast.

Q: 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: 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" (https://support.microsoft.com/default.aspx?scid=kb;en-us;169789&sd=tech).

Q: 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?

A: 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.

Q: 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?

A: 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 (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.

Figure 1: Using Ntbackup to create an ERD

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, CE-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 (as the ERD does), 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 DS-integrated and non-DS-integrated DNS zone information. Finally, 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.

Figure 2: Including System State data during a backup

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," https://www.win2000mag.com/ , InstantDoc ID 7664.

Q: Can you recommend a third-party software package for creating and administrating user profiles and policies? I want a tool that is easier to use than the Windows NT System Policy Editor (SPE).

A: For system-policy files, the best tool I've come across is Tools4ever's Policy Template Editor—a must-have utility for creating custom .adm policy template files that contain custom Registry settings (the files from which .pol system-policy files are created). You can use Policy Template Editor's GUI to create per-machine or per-user policies—a much easier process than creating and editing the .adm files manually.

Another handy resource for creating custom system-policy files is the NT Zero Administration Kit (ZAK), which includes several excellent enhanced and custom .adm files for the OS and for particular applications. Using the ZAK's templates files, you can build a much more comprehensive system-policy file than you can with NT's default templates (i.e., winnt.adm and common.adm).

As for user profiles, you'll unfortunately find a dearth of profile-management utilities for NT. In fact, I've long felt that third-party utility vendors have all but ignored user profiles. The Microsoft Windows NT Server 4.0 Resource Kit includes one profile-management utility, delprof.exe, a command-line tool that helps with the deletion of a machine's unused user profiles. (For more information about Delprof, see Mark Minasi, This Old Resource Kit, "DELPROF," July 1998.) Unfortunately, Delprof represents the extent of Microsoft's built-in user-profile-management tools. Microsoft never shipped an NT 4.0-updated version of the handy User Profile Editor utility (upedit.exe) that shipped with the NT 3.5x resource kits. However, both Win2K and NT 4.0 support some techniques that might help you create your user profiles.

To create a master (or template) user profile, you simply need to create a user account for that profile, then log on as the template user. After you configure the profile to your liking—including applications and per-user Registry settings for the desktop—you can then use the Control Panel System applet's User Profile tab to copy that profile to a different location, as Figure 3 shows. This dialog box also lets you assign permissions for the users or groups that will use a particular user profile. If you'd rather not create a template or master version from scratch, you can copy a user profile by simply copying an actual user's existing profile (from a machine that holds the desired version of the user's profile). However, if you use this method, you need to ensure that this profile contains no sensitive data that might compromise security or user privacy.

Figure 3: Copying an existing user profile

For more information about user profile and system-policy management in NT 4.0, check out the Windows NT 4.0 Guide to Policies and Profiles. This file, called profiles.doc, is included in the NT 4.0 ZAK, available on Microsoft's Web site, and in the resource kit.

Sean Daily is a contributing editor for Windows 2000 Magazine. He is the technology lead at Xcedia, a consulting firm specializing in Win2K and Microsoft Exchange Server deployment and migrations. His most recent book is Optimizing Windows NT (IDG). You can reach him at sean@xcedia.com.

The above article is courtesy of Windows 2000 Magazine. Click here to subscribe to Windows 2000 Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

Click to subscribe