Ask Dr. Bob Your NT Questions - 01 Feb 1998

Send us your tips and questions. You can also visit Bob Chronister's online Tricks & Traps at

Before I start with this month's Tricks & Traps, I want to share a personal story relating the trials and tribulations of my ISDN line at home. The line was working one day when I left the house but was down when I returned. I typically use a 3COM Impact IQ ISDN device, which uses lights on the front of the device to signal when the line is working. I was unable to establish a decent connection with the ISDN line more than half the time. When I could connect, the line didn't work. I tried everything and nothing seemed to work—I still couldn't get a connection.

In exasperation, I called BellSouth. A BellSouth engineer visited me and told me I had a faulty cable. I tried to tell him that all network cables are wired 1 to 1 (i.e., the connections are the same at both ends) except for computer-to-computer cables. He suggested I try using a cable he brought with him. Much to my chagrin, his cable worked. During the next week, I tried all types of cables, including one I made myself, but the line was still down. I then wired the ISDN device directly to the jack. The line came up, and my ISDN started working for the first time in 6 weeks. Despite an ugly connection hanging in my computer lab, I was a happy camper.

Two days later, the ISDN device was working, and the ISDN line was up, but I couldn't connect to my Internet Service Provider (ISP). I called my ISP (Mindspring) and was told that the connection was fine. The ISDN line was up, but no calls were getting through to my ISP (a local number, by the way).

I swallowed what little pride I had left and called BellSouth again. After going through the typical "Do you understand computers?" nonsense, I explained the problem to the engineer. He told me to hang on while he sniffed across the line and looked at my ISDN device. The engineer informed me that my device was online, and he proceeded to tell me my telephone dial-in numbers and Service Profile Identifiers (SPIDs)—we both had a good laugh over the lack of security. With the engineer listening in, I tried to dial Mindspring and received a "no answer" message.

The engineer captured my call session to Mindspring and sent it to a printer, which caused his computer to hang. He laughed when I asked whether he was running Windows 95, but I could sense the admission in his tone. He told me a specialist would analyze the call and that he would get back to me. To my great surprise, the engineer called me back that evening to tell me that I had established a connection with Mindspring, but the system was returning a message of incompatible protocols, which was causing my computer to shut down the session. He didn't know why this was happening but said he'd look into it.

I called the BellSouth engineer back the next day, and his solution to the problem amazed me. With the increase in ISDN traffic nationwide, many telephone company switches are having trouble with high-speed connections. To solve the problem, I had to slow down the connection. With the 3COM Impact IQ ISDN device (I am not certain if this fix works with all other ISDN devices), I had to add a pound sign (#) after the dial-in number. Screen 1, page 212, shows a no answer response without the # sign, and Screen 2, page 212, shows a successful connection. This error and resolution is 100 percent reproducible.

I learned a few things while trying to solve my ISDN connection problem:

  1. I could always connect to Mindspring with a standard analog modem (Hayes Accura), even when dialing the same dial-in number I used with ISDN.
  2. I saw my ISDN device lose its SPIDs and dial-in numbers numerous times as the result of power surges. The easiest way to see whether the line is intact is simply to turn off and then turn on the ISDN device. In about 15 to 20 seconds, you will see the device reestablish the connection. Presumably, this problem usually occurs only when you have current surges and momentary loss of power.
  3. More and more users establishing high-speed connections will continue to strain the hardware on the Internet, and the situation will get worse before it gets better.
  4. The fact that BellSouth could easily and remotely look at my ISDN device and its configuration tells me that security is a serious issue.

My hat goes off to the BellSouth engineers. Their solution is certainly one I would never have thought of. (For another ISDN line installation experience, see John Enck, "Lab Guys," page 75.)

Q: Can you explain the difference between a boot device setting and a system device setting? If I set a SCSI controller to system, what is the effect?

Interesting questions. You need to understand what a device is to Windows NT. In your case, the device is not the SCSI controller, but the driver for the controller. Defining a device in this way has important implications. NT contains three device driver loading options (boot, system, and automatic) that work at startup, and these three options are easy to confuse. All three options start a device, but they do so in very different ways. The boot option starts the device driver on system boot before other device drivers that aren't set at boot. The system option starts the device driver as part of the NT system start, but after boot device drivers. The automatic option starts the device driver after the NT system start.

In general, devices that load at system boot (i.e., using the boot startup option for the device driver) and then fail with a blue screen of death are difficult to fix. I have had to reload NT several times because of such errant drivers. For example, you can't fix a SCSI driver that fails during the boot process if you're using the NTFS file system. Because of these considerations, I always recommend that you create two copies of NT on a production server—one for running the operating system, and the other for fixing or restoring system settings. Be careful when you assign startup options for devices.

Q: My company is deciding whether to use terminals to connect to Windows NT Server or use low-end workstations to access NT Server. Users want workstations, and management wants no-administration cost. What factors should we consider?

You need to consider several factors. A system running NT Workstation or Windows 95 needs a 200MHz Pentium with 32MB of RAM and at least a 15" monitor (by the way, NT Workstation will run 20 percent faster than Win95 with this configuration). Depending on the configuration and vendor, this type of machine will cost $2000 to $2500. I assume that your users will perform most work locally on the client machines and that you'll use the server for security and access to shared files and applications. In this environment, the server can either be Intel or Alpha based, and you can tune it to the application used.

Systems running thin clients on NT use Intel-based servers exclusively. These servers are memory hungry and use a basic formula of 32MB + (number of clients x 10). In other words, a server supplying 35 clients needs at least 382MB of memory. Vendors argue that 4MB per client is enough, but 10MB per client is more realistic. In addition, many users consider 32MB inadequate for a server. Furthermore, such a network has one point of failure and requires the use of clustering or similar software on the server. Obviously, such a server is very expensive, but it has some advantages such as administrative control. Microsoft recently unveiled the first beta of its entry into the thin-client computing market: Microsoft Windows-based Terminal Server, formerly code-named Hydra (for information about Hydra, see Randall C. Kennedy, "Beware the Hydra," January 1998). Citrix WinFrame, a leading thin-client NT computing solution with a major presence in the market, promises many benefits to its user base (reportedly at least 1 million users).

Currently WinFrame runs only a modified version of NT 3.51, which dramatically limits the number of applications you can run in this environment. However, despite this shortcoming, Citrix claims that WinFrame has several major advantages:

  1. For starters, WinFrame is based on Citrix's Independent Computing Architecture (ICA)-based universal client (Citrix's ICA is a general-purpose presentation services protocol for Windows software) that works with application server software. This thin-client architecture offers universal application access for users and single-point control and management for IS. The latest application manager provides one interface for assigning applications to a server and thus making the applications available to users. This approach is IS friendly, but not necessarily user friendly.
  2. Because of the basic design of the Citrix WinFrame network, security is enhanced dramatically and is truly server based.
  3. With WinFrame's design, you can add plug-ins to Netscape Navigator or Microsoft Internet Explorer. These additions let the browser act more like an operating system. This type of design lets you easily access any application without rewriting code.
  4. Citrix maintains that the kernel enhancements to its NT Server product triple WinFrame's level of C2 security. (Although this statement is dramatic, I am not certain what it means. C2 is a designated level of security, and stating that you can triple C2 is confusing.)
  5. Setting up Windows-based clients is done with a Win95/NT 4.0 setup wizard.

Running conventional workstations on a network is expensive but uses conventional NT and Win95 client software and probably handles custom or legacy software better than ICA-based systems. If you use mandatory profiles and install the same software on all systems, this type of environment does not have to be IS expensive, but it requires that you plan your environment.

With ICA-based software, the clients operate similarly to the X-Window connections of large server installations. The current crop of thin-client server software is all proprietary, and application choices are limited compared to a workstation environment. The server configuration in this environment is expensive, provides one point of administration, and also provides one point of failure.

Determining which approach is most applicable to your environment is difficult. If you have several types of applications that are memory and processor intensive (e.g., engineering applications), I recommend using the workstation model. However, if you deal primarily with point-of-sale applications that require simple data entry or you deal with a few stations running Microsoft Word, then an ICA-based system will work. (For more information about thin-client solutions, see Mark Smith, "Thin is In," September 1997.)

Q: Can I get the same depth of applications and hardware support running Windows NT on a notebook as I can get running NT on a desktop system?

Many users believe NT 4.0 doesn't run well on notebooks. I run NT 4.0 on an AST 133MHz Pentium notebook with 72MB of RAM and on an old 486 33MHz notebook with 32MB of RAM, and both work fine (the 486 is obviously slow). I don't know of any limitation that restricts a notebook from performing as an NT workstation or server. To illustrate this point, I installed the 133MHz Pentium as a Primary Domain Controller (PDC) on my network, as you see in Screen 3. Although this solution is not the best (most notebooks are too slow and lack the necessary power), the notebook functions well as a PDC. Likewise, I have installed Adobe Photoshop and Macromedia FreeHand on this machine, and both applications work well.

The one area where you might have concerns about running NT on a notebook is with your peripherals. My 133MHz Pentium contains an on-board 28.8Kbps modem, which simplifies configuring the PCMCIA slots for maximum flexibility. I typically install and use an Adaptec SlimSCSI card and a 3COM NIC in my PCMCIA slots. With NT 3.51, I had to have a peripheral attached at all times to the SlimSCSI; otherwise, the system would hang at boot. Microsoft fixed this bug in NT 4.0. I use the AST CD-ROM drive in the combined battery/floppy/CD-ROM slot and an inexpensive Dell floppy drive on the parallel port to give me floppy drive and CD-ROM drive access at the same time.

I have tested and used the following peripherals with NT 4.0 on my AST notebook:

  1. SCSI peripherals: I've used various devices, such as external hard disks, SyQuest drives, Microtek scanners, Iomega Jaz drives, Panasonic CD-ROM drives, and DAT drives for backup. You can safely assume that any standard SCSI device will work on the SlimSCSI card.
  2. Printers: I currently use an HP DeskJet 340 on the system. This excellent printer is small enough to carry with you and can function with a battery.
  3. Zip drive: The Iomega Zip drive is without a doubt the most standard peripheral removable drive. It is also a very proprietary drive. NT provides native support for the SCSI version of the drive, but this SCSI drive uses a 25-pin SCSI-I connection. Obtaining the proper cable can be a serious problem. The parallel port version of the Zip drive comes with NT drivers (you can download the file from or Installing these drivers is straightforward. On my system, the Zip drive won't work if I attach the external Dell floppy drive to it. However, the Zip drive will work when I attach the HP DeskJet 340 printer to it.

I have to use the Iomega utility to format my Zip disks and remove the password protection. For some inexplicable reason, on my system, NT sees the disk as write protected, and I have to unprotect the disk with the Iomega utility, as you see in Screen 4. The Iomega format tool readily formats the disk. Several interesting situations can develop with the Zip drive. For example, if the attempt to set up the drive in NT fails, Chkdsk automatically runs on boot. You can avoid this situation by booting the Zip drive without inserting a disk.

Most new devices work fine on a notebook running NT 4.0. Some vendors (e.g., Digital and Toshiba) also support the suspend and restart functions in notebooks.

Q: Can you explain some of the benefits of intelligent input/output (I2O)?

I2O evolved from the notion that the power of a server's CPU far exceeds the ability of the system bus to provide needed input/output. The CPU was either idle or handling the I/O. I2O circumvents this problem (which is only getting worse as CPU power increases) and handles the I/O on the server without involving the CPU.

Intel's I2O solution uses the i960 RP I/O processor, which is a complete I/O subsystem on a chip. This processor also provides an on-chip PCI-to-PCI bridge that lets the i960 directly connect to the PCI bridge without using add-ons. Interestingly, the i960 I/O subsystem architecture will work on non-Intel CPUs. This I/O subsystem has several advantages:

  1. Increased I/O throughput by offloading the I/O functions from the server CPU
  2. Improved I/O scalability
  3. Better I/O channel management
  4. Standardized device drivers and assured I/O interoperability
  5. Improved CPU scalability, which provides more data processing and achieves higher levels of CPU utilization without saturating the PCI bus

In an interesting white paper (, the Aberdeen group proposes the following benefits of I2O:

  1. Most important, I2O makes backup and restore faster.
  2. I2O improves bandwidth, which will lead to greater user productivity. Server-bound applications or data will appear faster.
  3. I2O simplifies installation of drivers and hardware, which will reduce the total cost of ownership.
  4. I2O increases bandwidth, so current server configurations will be able to handle more users (i.e., the I/O bottleneck will be greatly reduced).
  5. I2O increases availability because of greater autonomy allowing I/O intensive activities to occur in parallel with application processing.

Whether or not all these advantages pan out, the current definition of storage subsystems is changing. Hard disks are getting faster, CPUs are getting faster, and the current system bus can't handle this throughput efficiently. The system must provide some type of offload to let the increased speed break out of the I/O bottleneck. Vendors might soon discover that users want I2O-enabled workstations as well.

Q: How do I change the name of frozen objects such as the Recycle Bin on the desktop?

The new regedit.exe comes in handy for this task. Warning: Using the Registry editor incorrectly can cause serious, systemwide problems. You may have to uninstall Windows NT to correct them. Use this tool at your own risk.

Renaming objects on the desktop is easy. In Regedit use Edit, Find to locate Recycle Bin. Once you locate this object, you can use Edit, Modify to change the string value, as you see in Screen 5. I changed the name of my Recycle Bin to Trash Bin. For the change to take effect, you must reboot the system.

Q: Can you change Windows NT's security identifiers (SIDs)?

Yes, you can change SIDs using tools such as Mark Russinovich's NTSID, which is available for free at Two other SID-changing applications have also recently appeared. One is GHOST Software's GHOST Walker (, and the other is PowerQuest's SIDchanger ( PowerQuest provides SIDchanger as a service to registered users of Drive Image Professional, a disk imaging tool.

After I checked out these applications, I called a friend at Microsoft to ask him about Microsoft's position on this type of application. He said that Microsoft won't deny support to any installation that has been determined to have the application and cloning used. However, if any problem occurs with the installation, the user would have to create a new installation using conventional methods.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.