Editor's Note: Share your NT discoveries, comments, experiences with products, problems, and solutions and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (under 400 words) to Karen Forster at email@example.com. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll receive $100. Christa Anderson's March article, "Designing Unattended NT Installations," provided a good introduction to Windows NT 4.0's automated installation capabilities.
The article described how you can use uniqueness database files to customize an installation for a particular user. This feature is great for NT 4.0 users, but some of us are still installing NT 3.51 on enough machines to make custom unattended installations worthwhile. Fortunately, you can use a batch file to change one line of an answer file on the fly and customize the install for a particular user. I wrote the batch file in Listing 1 to do just that.
In this example, you can install NT 4.0 over the network by running setup.bat from the \winnt40\workstn\i386 directory on the machine SERVER, and right from the command line, you can specify the computer name you want to give the machine you are installing. The files 1.txt and 2.txt are the sections of the answer file before and after the line ComputerName =.
This method works equally well in NT 3.51. You can use this method with any other line in the answer file that you want to change from the command line.
A couple of hints: If your unattended installation needs to access your Dynamic Host Configuration Protocol (DHCP) server, make sure this server is running; otherwise, the installation will stop when NT tries to start the network and asks whether you want to see further error messages about DHCP. Also, you can specify the directory \winnt instead of choosing the default during your installation; otherwise, the install program might place NT in \winnt.0 or a similar directory if you have an existing boot.ini file hanging around.
Problems with IPX/SPX and DOS Apps
I recently discovered a potentially significant problem running DOS applications under Windows 95 on a Windows NT-based network. My company has several client machines that still run multi-user DOS applications across the network for critical business functions such as accounting.
While using these network apps, several of these clients reported problems during network intensive operations. The errors usually show up in the form of a Drive Not Ready error for the network drive mapping where the program resides. Although I have seen other application-specific errors, in all cases, the applications appear to lose their network connection to files on the NT server. The applications usually terminate abnormally, often causing file and data corruption. Administrators can spend numerous hours correcting the results of these crashes.
After a lot of testing and troubleshooting, I found that the problem is isolated to cases in which IPX/SPX is the default protocol. By removing the IPX/SPX protocol from the Win95 workstations or the NT server and running NetBEUI or TCP/IP instead, you can eliminate this problem. Of course, administrators have to be sure that all workstations and servers in their enterprise have at least one common network communications protocol.
An alternative in Novell NetWare server environments where you can't eliminate IPX/SPX is to set either TCP/IP or NetBEUI as the default protocol. I have not tested this approach as conclusively as the aforementioned solution, but this method works in at least a few field cases.
I hope this solution helps you avoid the pain we have endured leading to this discovery. Also, if anyone has encountered this problem or has more information about the issue, I would like to hear from you.
Fixing a Boot-Sector Virus
I recently came across a Windows NT workstation infected with the AntiEXE boot-sector virus. The machine contracted the virus when the user did a shutdown and restart with an infected floppy in the disk drive. Using the NT Repair facility did nothing to fix the problem, so I decided to try the old DOS trick of rewriting the boot sector using fdisk /mbr. Then I ran the NT Repair facility to fix the boot sector. It worked like a champ.
Scheduling External Appointments in Outlook and Schedule+
If you're using Outlook 97 or Schedule+ and MS Exchange for email, you can schedule meetings with people outside your company the same way you schedule appointments internally. In Outlook, go to your Contacts and select the person you want to meet with. Open the details screen for this person, and double-click or right-click the email field. Check Always send to this recipient in Microsoft rich-text format.
Once you set this option, the person you want to meet with can accept or reject an appointment the same way internal Exchange users can. Ask the person you want to set an appointment with to make that same setting for you.
In Schedule+, go to your Personal Address Book and highlight the entry for the person you want to meet with. Check Always send to this recipient in Microsoft rich-text format. Once you set this option, the person you want to meet with can accept or decline the appointment the same way internal Exchange users can. Ask that person to make that same setting for you.
Replicating Netlogon Shares on the BDCs to Enforce Policies
In Sean Daily's article, "Further Explorations of the NT System Policy Editor," the author discusses the fact that the ntconfig.pol file (or config.pol for Windows 95) needs to be on the Netlogon share of the Primary Domain Controller (PDC). This approach assumes the PDC is available 100 percent of the time. For some sites, this assumption is not always true. In fact, with all users accessing the PDC to get their ntconfig.pol file, you can experience slow network response and inacceptable logon times.
These sites, which may be connected by an on-demand or AT scheduled Remote Access Service (RAS) link, can also use system policies to enforce NT Workstation or Win95 restrictions, even without 100 percent uptime connectivity to the PDC. In this environment, you will want to enable replication of the PDC's %systemroot%\system32\repl\export\ scripts directory to replicate to the Netlogon shares on the Backup Domain Controllers (BDCs). Then you can use the System Policy Editor (SPE) to configure the workstations to obtain their copy of ntconfig.pol from any logon server (BDC or PDC) that is validating them.
Use the SPE (with the common.adm template) to edit the Default Computer Network | System policies update | Remote update key. Next, enable Remote Update and configure it to use Automatic Update Mode (available from the drop-down box), and enable the Load Balancing check box. These steps let the workstations pull ntconfig.pol from the BDC that validates them--anywhere in the organization.
MCSE or MSCE?
I'm working toward Microsoft Certified System Engineer (MCSE) certification. Last month, I was browsing Microsoft's training and certification Web site and noticed that MCSE was misspelled in the HTML <TITLE> tag in two places. Like a good microserf, I reported the errors to Microsoft and requested a T-shirt for pointing them out. Several days later, I received a reply thanking me and saying that although Microsoft had fixed the errors, I couldn't have a T-shirt. Instead, the reply said I should be thankful that I'm a Microsoft Certified Professional (MCP) because "being an MCP is a reward in itself."
I checked the Web site, and found that Microsoft had not fixed the errors. I sent another email to Microsoft but didn't receive a reply. I recently received an update to Microsoft's Training and Certification CD-ROM, dated February 1997. This CD-ROM, which replaced the old Training and Certification Roadmap CD-ROM, mirrors the Web site. Guess what? The CD-ROM contains the errors I reported to Microsoft. The company has now fixed one error on the Web site, but not both. Microsoft seems just as confused about the MCSE (or is it the MSCE?) acronym as many users, not to mention which logo certified professionals should use.
The Web site where the spelling is correct is http://www.microsoft.com/ train_ cert/cert/mcse.htm. The misspelling is still in place at http://www.microsoft.com/train_cert/cert/mcsebenf.htm.
Windows NT's Boot Partition and Migrating NT to Another Disk
Is the Windows NT boot process that different from its DOS counterpart? Yes and no. NT's boot process is more advanced, but it is still a series of events that locates and loads operating system files. NT uses a boot partition to load system files, similar to but more sophisticated than config.sys and autoexec.bat.
Despite these similarities, NT's boot partition differs from the DOS boot partition. If you create a boot partition on a hard disk using the sys c: or format c: /s commands, the disk will follow the DOS boot process. NT has no sys command, but you can change the boot partition using NT's setup disks. Boot the first NT setup disk and choose R to repair an installation. At the next screen, deselect everything except Inspect Boot Sector. Continue accepting defaults until the system prompts you for an Emergency Repair Disk--press Esc. Press Enter at the next screen to complete the repair.
Armed with this knowledge, some attention to details, and possibly a few third-party products, you can migrate an NT installation from one hard disk to another. The details will vary depending on your situation, but the following steps are similar to all installations:
1. Format the target hard disk as a DOS drive (format c: /s).
2. Copy all files from the source hard disk to the target disk. You can use the DOS xcopy command or third-party products such as LapLink or ArcServe.
3. Modify the target disk's boot partition with the method I described above.
As I mentioned, you need to pay attention and watch for the following details.
* NTFS Partitions: If your source drive contains an NT File System (NTFS) partition, you need to use a product such as ArcServe to copy the files to the target disk or an intermediate location such as a file server. NT keeps control of its system files when the operating system is running; therefore, a simple File Manager copy won't work. Booting with a DOS floppy disk that has network connectivity or LapLink (for example) will not give you access to the NTFS partition. I use ArcServe because it will copy all the NT system files even though NT is using these files.
* System and Hidden Files: If you boot with a DOS floppy disk and do an xcopy c:\*.* /s from a FAT partition, you will probably miss many critical files because they have System or Hidden flags. I recommend removing the System and Hidden flags with the attrib command. LapLink and ArcServe will let you copy System and Hidden files, and save you time and frustration.
* NetBIOS Name and TCP/IP Conflicts: The procedure I'm describing to copy your NT installation creates a duplicate of the source PC. If you maintain both PCs with the same files and run both PCs at the same time, you can encounter conflicts on the network. If you are handing the old PC to a new user, format and reload the old PC.
Scrolling with a Trackman in Windows NT
I use a Logitech Trackman Marble with Windows NT 4.0. When I checked Logitech's Web site, I discovered instructions for setting up this peripheral under NT. I followed the instructions for setting up "Mouse" on the Control Panel. I continued with the instructions to verify three-button support, which required opening the Registry. I discovered that the Registry entry still showed a two-button mouse. When I changed the entry in the Registry (following the Logitech instructions) and rebooted, I discovered that the middle button and trackball now operate in combination, similar to the wheel on Microsoft's IntelliMouse. I can activate and deactivate the scroll feature with the middle button and control the speed of the scroll with the trackball.
Watch for these hot topics:
- Service Pack 3
- NT 5.0 Security: Kerberos
- Microsoft's Steelhead Router
- ISDN Troubleshooting