Send us your tips and questions. You can also visit Bob Chronister's online Tricks & Traps at http:// www.winntmag.com/ forums/index.html.
Thin Clients on NT
In response to my February 1998 column, several vendors sent me mail concerning the use of thin clients in networks. They point out that I haven't kept up with Windows NT-related thin-client developments. With the price of PCs falling below $1000, thin clients must offer exceptional price and performance to make them attractive to enterprise computing. You don't have to look far to find companies taking advantage of the PC's price/performance benefit--Federal Express is moving from thin clients to small workstations. I can see thin clients working well for small networks, but the administrative costs associated with the servers, as well as the cost of the servers, can be substantial. Thin clients can work in the right situation, but I don't consider them a panacea for networks.
NT Boot Disks
I've received many requests asking how to make a Windows NT boot disk for an Alpha-based system. For your convenience, I've included steps for both an Intel-based system and an Alpha-based system.
I386. Format a disk in NT (this step is essential). Copy NTLDR, ntdetect.com, and boot.ini to the disk. You can now boot with this disk to access your NT installation (you have bypassed the hard disk boot sector).
Alpha. Format a disk in NT. Copy osloader.exe and hal.dll to the disk (the system BIOS performs the hardware detection on Alpha-based systems, so you don't need to include the ntdetect .com file). You can now boot with this disk to access your NT installation.
Q: I'm trying to install TCP/IP printing with an unattended script. How do I install the appropriate port?
You can't install the Line Print Remote (LPR) port as part of a standard unattended setup, but you can use the OemPreinstall portion of an unattended installation to accomplish this task. You must fulfill one major requirement for such an installation: The user must be a member of the Administrator group (however, the administrator doesn't have to log on to each workstation to install the port). You must provide a different shared directory for each LPR port configuration, and each share will consume about 80MB of hard disk space.
To install LPR ports, perform the following steps:
1. Go to a Windows NT server on your network, and install Microsoft TCP/IP Printing from the Network applet, Services tab under Control Panel. (You can also perform this procedure from a workstation on your network, but I don't recommend doing so.)
2. Reboot the server. Open the Printers applet in Control Panel, and select Server Properties from the File menu to install the LPR ports with the correct IP addresses and names. Alternatively, you can select Printers from My Computer, and then select Server Properties from the File menu. Screen 1, page 232, shows the Ports tab where you can add the new LPR ports and assign the correct IP addresses and names.
3. Open the NT Registry using reg edit.exe (you can't use regedt32.exe because it won't let you install .reg files), and go to the HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control \Print\Monitors\LPR Ports\Ports subkey. Select the IP address and name of the printer you just installed. Select Export Registry File from the Registry menu, and save the Registry file as lpr.reg. You must create a Registry file with a unique name for each LPR port installed. Close regedit.exe.
4. Go to the NT network installation share. Create an $oem$ subdirectory under the i386 directory. Copy regedit.exe and the .reg files you just created in step 3 to the $oem$ subdirectory.
5. Use a text editor such as edit.com (however, don't use a unifont editor such as notepad.exe) to create a cmdlines.txt file in the $oem$ subdirectory. Add the following lines, including quotation marks:
".\regedit /s .\lpr.reg"
For each port you are installing, you need to add a line with the appropriate .reg filename.
6. Add the OemPreinstall value to the unattend.txt file, and set this value to Yes. Use edit.com to modify the unattend .txt file so that it includes the OemPreinstall syntax and automatically installs the TCP/IP protocol and TCP/IP printing.
7. Run setup.exe from the i386 directory with the following standard command line:
winnt /b /s:<sourcefiledir> /u:<unattend file name>
If you're upgrading an existing NT machine, the command is winnt32.
Q: I just read your column about installing a Windows NT administrator account with a password other than blank. Although I've tried this method several times, I can't get it to work. What am I missing?
When you run an unattended setup of NT 4.0, you can specify the administrator password or leave it blank. During an unattended setup, the NT installer usually sets the password during the GUI mode, which the OemBlankAdminPassword = %value% key controls. A %value% of 0 means no, and a %value% of 1 means yes. To install the NT administrator account with a password other than blank, perform the following steps:
1. Create a $oem$ subdirectory under your i386 directory on the NT network installation share.
2. Use edit.com to create a cmd lines.txt file that contains the following lines, including quotation marks:
".\net user administrator <password>"
3. Place a copy of the net.exe file in the $oem$ subdirectory.
4. In the unattend.txt file, set the OemPreinstall value to Yes.
5. Run an unattended setup for NT 4.0. (I like to start the logon procedure by running the line
net start netlogon
and running the net user line in step 2.)
Q: When I'm running unattended installations, I want users to have minimum access to the machine. How can I limit users so that they can log on to the machine without seeing anything on screen?
You are trying to remove what Microsoft calls the Welcome to Windows NT Splash Screen. You can remove this screen using one of two methods.
To remove the screen using the first method, follow these steps:
1. Copy all NT system files you need for your particular processor from the NT CD-ROM to a network share.
2. Create the unattend.txt file with the parameters you need.
3. In the i386 directory (or the directory for the platform you are installing) on the network share, rename the welcome .ex_ file to welcome.bak.
4. Copy the txtsetup.sif file in the i386 directory to another filename, such as txtsetup.bak.
5. Use edit.com to open the txtsetup .sif file. Use the Search command to search for the word Welcome. You will find only one entry for this word, welcome.exe = 1,,,,,,,1,0,0.
6. Place a semicolon in front of the entry you found in step 5.
7. Save the revised txtsetup.sif file to the network share.
8. Copy the dosnet.inf file in the i386 directory to another filename, such as dosnet.bak.
9. Use edit.com to open the dosnet .inf file. Use the Search command to search for the word Welcome. You will find only one entry for this word, d1,welcome.exe.
10. Place a semicolon in front of the entry you found in step 9.
11. Save the revised dosnet.inf file to the network share, and exit edit.com.
12. Run the NT Setup routine. The first time any user logs on, the Welcome to Windows NT screen will no longer appear.
To remove this screen using the second method, follow these steps:
1. Copy all NT system files you need for your particular processor from the NT CD-ROM to a network share.
2. Create the unattend.txt file with the parameters you need. In the unattend.txt file, set the OemPreinstall value to Yes.
3. Create a $oem$ subdirectory under the network share directory.
4. In the $oem$ subdirectory, create a cmdlines.txt text file that contains the following two lines:
".\regedit /s nowelc.reg"
5. Also in the $oem$ subdirectory, create a nowelc.reg text file that contains the following six lines (the blank line after REGEDIT4 must be present):
6. Place a copy of regedit.exe (from the i386 directory) in the $oem$ subdirectory. The cmdlines.txt, nowelc.reg, and regedit.exe files should be in the $oem$ directory.
7. Run the unattended setup for NT 4.0.
Q: I am installing a new Win- dows NT network. What do I need to consider when performing this installation?
You need to consider several factors when you install any network. Some points to consider when you install an NT network follow.
Keep written records. Know what you have to work with, and keep a written record of network parameters such as types of cabling; NICs used in all machines; the topology related to every server; and the names and locations of the Primary Domain Controllers (PDCs), Backup Domain Controllers (BDCs), and Windows Internet Naming Service (WINS) servers. This simple approach will save you time and grief later. Every time I'm asked to look at a network setup, I ask to see the documentation. I usually get a look of confusion and a response of, "What do you mean?" At this point, I realize that any analysis of the network will be long and hard because of inadequate documentation.
Plan the network logically. Place the wiring neatly into wiring closets. Make sure you run the wire with care (e.g., don't drape the wire over electrical wiring).
Make sure you have adequate bandwidth. Consider where the network will expand, and make certain you have adequate bandwidth. For a real-world example, consider a large pharmacy chain that recently expanded. The company uses dumb terminals connected to a central regional server, which connects to other national servers through satellite communications. When the company turns on its East Coast system, the response time is very fast. When the West Coast system comes online later, the response time lengthens and the system might even crash. The major reason for the problem is a lack of appropriate bandwidth.
Supply redundancy where needed. In the previous example, a crashed network would be fatal; the pharmacy chain couldn't fill prescriptions and would start to lose money. If the company implemented regional backup servers, it could continue functioning without serious consequence.
Limit your equipment suppliers. Use standard equipment, and keep the number of suppliers to a minimum. If you're adding any component (such as memory) to your systems, use one vendor to supply that component. Also, carefully check that any component you add meets your specifications.
Place essential services on stable servers. Services such as Exchange, WINS, and Domain Name System (DNS) need to run on a stable platform. In addition, make sure you understand the hardware requirements of these services, and place them accordingly across the network.
Use failover NICs. Consider using the new failover NICs by vendors such as Intel on essential servers. These NICs provide critical redundancy by failing over to the backup NIC in the event that the primary NIC fails. NICs seldom fail, but failure can happen.
Plan your network backup scheme. Plan your backup scheme logically. Don't back up thousands of workstations and servers onto one backup server.
Use UPSs on your hubs, switches, and routers. One power failure can bring your network to a grinding halt. Make sure you're prepared--networks without connections aren't functional.
Keep an operations runbook. You need to maintain an operations runbook that documents how to respond to critical problem such as if the DNS server stops responding, a remote office router goes offline, the power supply goes out on the corporate router, the remote access server is randomly not answering, the money you saved on a tape unit is now in jeopardy because the tapes are no longer available, El Nino produces a storm that takes you off power for 2 weeks, or your secondary WINS server has not replicated the WINS database. These events happen, so plan for them.
Establish a company policy and stick to it. Like documentation, poli-cies get only lip service from many companies. Careful planning, documentation, and implementation will produce a functional network that isn't a malignancy.
Q: How do I set up a Microtek ScanMaker E3 scanner in Windows NT 4.0?
I've set up both HP and Microtek scanners in the past (see "Ask Dr. Bob Your NT Questions," January 1997). Here are the steps for setting up a Microtek ScanMaker E3 scanner in NT 4.0.
1. Make sure you properly set the SCSI ID and termination on the scanner (for example, on an Adaptec 3940 controller, you will want to install the scanner on channel A).
2. Insert the Microtek CD-ROM, and run the Microtek install wizard.
3. Reboot the system.
The scanner installation is that simple. I prefer to use Xerox's TextBridge optical character recognition (OCR) software instead of the Caere OmniPage Limited Edition OCR software that comes with the Microtek scanner. The OmniPage software doesn't function well in NT, and Caere suggests you purchase the full-blown application.
Q: Can you explain the Hardware Profile/Last Known Good menu? I've tried to use the Last Known Good configuration, but it never seems to restore the last known hardware profile as I understand it.
You are correct. In many situations, the Windows NT Last Known Good configuration doesn't restore your system as you might expect. In principle, the Last Known Good configuration is supposed to restore your system to the last successful NT logon that occurred; unfortunately, this feature doesn't always work the way it's supposed to.
When you see the Hardware Profile/ Last Known Good menu during the NT boot process, you press the spacebar and you see the Last Known Good option. NT stores the Last Known Good hardware profile information in the system hive. A control set contains the essential information, such as drivers and services, to load and start. Several different control sets exist, and NT maintains them in the HKEY_LOCAL_ MACHINE\SYSTEM\Select Registry key. The objects that NT maintains in this key are
- Current, which points to the actual CurrentControlSet
- Default, which points to the Control Set used the next time NT starts (typically the same as Current)
- Failed, which refers to the Control Set used the last time Last Known Good was used
- LastKnownGood, which is the last configuration NT considers to have worked
Unfortunately, the Last Known Good configuration doesn't always function optimally. On some occasions, NT considers a logon successful when it is not. Always have a tape backup on hand.
Q: I moved a 2GB SCSI hard disk from one system to another. When I try to look at the files on this drive, they appear in a strange order and disappear from time to time. At no time can I access any of the files. What's going on?
I have seen this problem on several occasions. Most likely, the drive had extended translation enabled on one controller card, but not on the other. This problem is DOS-related and can be problematic because reformatting the hard disk is often the only solution to the problem.
Q: How do I create Emergency Repair Disks (ERDs) during an unattended installation?
You have several options when creating ERDs. The first method is to create an ERD after setup. Create a directory (e.g., $oem$\d\temp) on the appropriate drive. Next, set up an rdisk.ini file in the directory you just created containing the following lines:
Run-Rdisk = rdisk.exe /s
Set up an r-rdisk.bat file in the same directory containing the following lines (regini.exe is from the Microsoft Windows NT Server 4.0 Resource Kit):
Finally, add the following line to cmd lines.txt (substitute drive D with the drive on which you install NT):
cmd /c d:\temp\r-rdisk.bat
The second method is to create a shortcut. Add a shortcut to the desktop of the default user who starts rdisk /s. (This method is not a good idea on a Primary Domain Controller--PDC--with a large security database.)
The third method is to create a logon script. Create a login script that runs rdisk /s on a routine basis.