Tricks & Traps: Password Protection

Ask Dr. Bob Your NT Questions

Q:I recently purchased an Iomega Jaz drive. How can I get around the tool-drive password protection?

Interesting issue. Iomega claims the drive is not password protected, but I think it really is, or the partition and file information is proprietary. This problem is easy to solve, though. Reboot the system, and perform a low-level SCSI format on the drive. Then use Disk Administrator to set the partition and format the drive. Note, however, that Disk Administrator can't assign an extended partition to removable media.

Q: My 2940UW controller (1.23 firmware) is set for automatic termination. It controls a 4GB Wide Atlas, an UltraWide Hawk XL, a Quantum Empire 1080, and an HP DAT C1533a. The bus acts unstable and times out because of bus reset errors or event 9s in the Registry.

I thought the mix of devices was causing the problem, so I added a second 2940UW controller and moved the slow devices to it. Doing so caused my DigiBoard controller, which was set to D2000, to refuse to initiate. I ran winmsd.exe, but I didn't find any overlap. Can you offer some insight?

You have two separate issues. The first issue has to do with your bus.

Several factors about the bus configuration are important. You are running four devices with markedly different I/O speeds and characteristics. On the wide side, you are running a Wide drive and an UltraWide drive. On the regular bus, you are running a DAT drive and a hard drive that is known to have I/O problems on the 2940UW.

The other issue relates to termination because you're using both high and low SCSI bits. Your solution of separating the slow components from the fast was correct. Grouping the like-speed components makes controlling the termination patterns easier and eliminates the high- and low-bit termination issues.

I was able to reproduce the dual 2940UW/DigiBoard problem. When I added a second 2940UW, the DigiBoard PC/2e (8KB), which was set to D2000, no longer worked. Event Viewer offered the following message:

"Unable to properly access ntxall1's memory. Compare memory address settings with configuration. Otherwise, check for memory address conflicts with another device in the system."

Note that the DigiBoard did try to install. When I examined the winmsd.exe diagnostic tool in the %systemroot%winnt4system32 directory, I noticed that the second 2940UW was set to D4000. This setting interfered with the DigiBoard (I was surprised that the driver needed this much space). I set the DigiBoard to D8000, and the card initialized. According to winmsd, the following regions were occupied when I set the DigiBoard to D8000:

DigiFEP50x000d8000 0x00002000

aic78xx0xfabff000 0x00001000

aic78xx0xfadef000 0x00001000

mga640xfade8000 0x00004000

VgaSave0x000a0000 0x00020000

Tip: Adaptec technical support relayed the following guidelines to me after we discussed this 2940UW driver conflict.

1. Never assume that you've terminated a SCSI bus properly simply because it works in DOS or any OS other than Windows NT. Users who can run DOS, Novell, and UNIX (LINUX) off the bus can't always load NT because of an inaccessible hard disk error, and in fact, the user in this example terminated the bus incorrectly.

2. Always be certain that the cables match the device. Not all cables are comparable, and this problem is becoming a bigger issue as devices get faster.

3. As systems get faster, besides proper cables, termination becomes more important. Always terminate a bus with the most stable device; that is, terminate with Wide rather than UltraWide because the Wide drives have a more mature firmware and are consequently more stable.

Q: I've heard considerable discussion about having Windows 95 and NT on the same system. I am aware of the problems with different DLLs, and so forth, but do you know of any incompatibilities between the two OSs?

An excellent question. In general, I don't recommend dual-booting between Win95 and NT. My feelings about this issue are influenced by many problems that users have reported. (To be fair, I must admit I never hear much about success stories, and I did run the two OSs on the same system for a while.)

The only problem I am aware of relates to the Win95 Fdisk application. Delete the Win95 version of Fdisk and use Disk Administrator or the DOS Fdisk.

Q: After upgrading to NT 4.0, I've had three crashes in one week. If I disable the internal zipping and unzipping routines, I eliminate the problems, but I can't call NT 4.0 bulletproof or crashproof. I suspect that the problem is the result of Microsoft moving the drivers to Ring 0.

I've also had problems installing "Designed for Windows 95" programs. I've had to manually install these programs because although NT 4.0 doesn't recognize them, they will run on the OS.

For these reasons, I traded in my second processor for a faster, single one and side-graded to Win95. Now I can run all my programs, but I have to substitute NT's security with encryption and CMOS security. I may upgrade to a future version of NT only if it becomes as stable as NT 3.51, has more drivers, and accepts more Win95 programs. Does anyone make a utility that tricks Win95 programs into installing under NT?

I don't believe that your conclusions are necessarily correct. When Microsoft moved part of NT into Ring 0, many users and writers brought up the gloom-and-doom scenarios trying to bury NT. They assume that the Ring 0 issue makes NT 4.0 more unstable than NT 3.51. Let's look at the Ring 0 issue and how it pertains to your example. Microsoft moved the graphic and user heaps in NT 4.0 to Ring 0. As a consequence, all video and printer drivers must be recompiled for NT 4.0. Other drivers such as NT 3.51 SCSI drivers and network drivers will generally work in NT 4.0.

If the zipping and unzipping routines are causing your system to crash, I find it difficult to believe that the problem is related to the Ring 0 issue. You need to run a debug program to show that the system crash was related to moving video and printer drivers to Ring 0.

I recall all too well the move from NT 3.5 to NT 3.51. Systems that ran well with NT 3.5 were consistently crashing with NT 3.51. Usually, the issue was related to new drivers and old hardware. In short, rumors about the death of NT 4.0 because Microsoft moved the graphic and user heaps to Ring 0 are premature.

The problems you're having with the installation of Win95 applications will soon be over. Most new applications install well in both NT and Win95. For example, Adobe is releasing Pagemaker 6.5 and will support it in NT 4.0. As of this writing, Microsoft was supposed to replace the Win95 logo at the end of 1996 with a new "Designed for NT and Windows 95" logo (for information about the new NT logo, see Mark Smith's Editorial, September 1996).

No utility exists that tricks an application into thinking NT is Win95 because you can't do that trick. The Win95 DLLs don't necessarily match those in NT.

Q: I have two hard disks, a CD-ROM, and a tape backup on an external SCSI chain connected to an onboard SCSI controller in my Compaq ProSignia (a 66MHz 486 DX2 with 64MB of RAM), which is running Windows NT 3.51. I want to upgrade the computer but keep the SCSI chain intact.

What happens if I disconnect the chain and connect it to a new machine with a different network card, SCSI controller, and CPU? Should I upgrade to NT 4.0 before or after the move?

Contrary to popular belief, NT can usually handle dynamic switching of SCSI controllers. Unfortunately, you have to load all the controller drivers before you make the switch. So if you use a Compaq SCSI controller and want to change to a 3940UW, you need to load both drivers before you switch to the new system. (Caution: Although you can usually safely load the new driver, it occasionally creates problems. Always have a fresh backup ready in case the new driver causes the system to lock up.)

To avoid potential problems with a new video card, choose the VGA mode option when you boot the new installation. You can then change the video to the new card after you transfer all the devices to the new system.

The NIC should not be an issue. However, wait until the new system is running, and then install the new card and remove the old one.

Because you're running a Compaq, you are probably using Compaq-specific files for some components. I suggest you transfer all the devices and run an installation upgrade of NT 3.51. This sequence keeps your security and other settings intact and places all the proper files in the NT directories. Then you can upgrade to NT 4.0. Assuming the system is a production server, you must contend with the following standard precautions:

*Pick an appropriate time when the server can be down.

*Have a backup in case of a move-over failure.

*Prepare a new Emergency Repair Disk by running rdisk /s before the move.

*Be certain that the system is stable with NT 3.51 before upgrading to NT 4.0.

Q: I don't want to spend the money for an HP color scanner. Do you know of alternative scanners that run under NT?

You're in luck. Microtek's scanners work well in both NT 3.51 and NT 4.0. I've successfully configured them both. With NT 3.51, you have to add a section called [twain] to win.ini in the winnt directory and add the line

DeFault Source=%:winntTwain_32ScanwizScanwz32.ds

in which % is the drive where you've installed the winnt directory. With NT 4.0, the installation is automatic.

The scanner card that Microtek supplies uses sparrow.sys as the NT driver. When using this card, set the card's IRQ to 11. With Award or Ami BIOS, you have to reserve IRQ 11 as an ISA IRQ. With Phoenix BIOS, you have to reconfigure the system. With the system off, place the card in an available slot. Attach the scanner cable, and turn the system on. Immediately enter the system setup menu, and tell the BIOS to reset all IRQs. The BIOS will generate a new IRQ table and reserve IRQ 11 for the scanner card.

I'm currently running a Microtek scanner on a 3940U SCSI adapter. The scanner must be the last device on the SCSI chain. In my case, the scanner works well. However, you need to be aware of the following issues:

*Any SCSI card you use for the scanner must be Advanced SCSI Programming Interface (ASPI)-compliant because ASPI32 is loaded.

*You must reboot the system after you install the scanner and software.

*The limited version of Omnipage that comes with Microtek's scanners won't run in NT. You can install the supplied version of Omnipage and register it. Then, you can upgrade to the full version of Omnipage 6.0 that runs in NT.

Q: I noticed a deptools directory on the NT 4.0 Server CD-ROM (supportdeptoolsi386 as an example). I also noticed a setupmgr.exe file that I assume is an NT 4.0 version of the application that prepares an unattended answer file for setting up clients. What are rollback.exe and sysdiff.exe? I've heard horror stories about the use of rollback.exe. Why is such a dangerous application on the CD-ROM?

rollback.exe is an important application, but you must use it as designed. NT has two installation stages--a DOS-like text stage and a true NT graphics stage that the setup wizards control. Microsoft insists that all users use the graphic phase of the installation. Specifically, each user must see the following:

*Microsoft End User License Agreement (EULA)

*product identification

*appropriate username and company screens

This requirement is a serious burden to OEMs that supply NT 4.0 on your system. The OEMs can't supply you with a fully functional version of NT 4.0 on the machine, so they use rollback.exe. OEMs simply install NT 4.0 and perform a full installation. After auditing to ensure that everything is working properly, the OEMs run rollback.exe and the system reverts to the graphic stage of the installation. When you turn on the machine, the system will boot into the graphic stage, and you can enter all the appropriate user information. This method satisfies at least part of Microsoft's OEM licensing agreement.

If you examine the system32config directory, you see the following files:

appevent.evt

default

default.log

default.sav

sam

sam.log

secevent.evt

security

security.log

software

software.log

software.sav

sysevent.evt

system

system.alt

system.sav

userdiff

After you run rollback.exe, NT renames and then deletes some of these files on reboot. After the reboot, you see the following new files:

def$$$$$.$$$.log

def$$$$$.del

sof$$$$$.$$$.log

sof$$$$$.del

sys$$$$$.$$$.log

sys$$$$$.del

You can repair a system that you've accidentally run rollback.exe on, but you need an up-to-date Emergency Repair Disk to repair the Registry.

sysdiff.exe is more complicated. It lets a vendor create a snapshot of an installation, install applications, and then create a file that identifies the differences between the original configuration and the current configuration. Systems administrators can put this difference file on a centralized server and apply the changes to all OEM-prepared machines before running rollback.exe. For example, suppose an OEM decides to supply Office 95 with Windows NT. sysdiff.exe lets the OEM set up a master machine and create a file to apply to all new installations.

The use of sysdiff.exe is complicated and involves numerous switches and alterations to the sysdiff.inf file. Although sysdiff.exe is a potentially hazardous utility and primarily designed for OEMs, it can be powerful for large-scale NT deployments.

"In general, I don't recommend dual-booting between Win95 and NT."