Reader to Reader - July 1997

Editor's Note: Share your NT discoveries, comments, experiences withproducts, 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 protected]. 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 tocustomize 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 runningsetup.bat from the winnt40workstni386 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 isrunning; otherwise, the installation will stop when NT tries to start thenetwork and asks whether you want to see further error messages about DHCP.Also, you can specify the directory winnt instead of choosing the defaultduring your installation; otherwise, the install program might place NT inwinnt.0 or a similar directory if you have an existing boot.ini file hanging around.

—Timothy M. Gales
[email protected]

Problems with IPX/SPX and DOS Apps
I recently discovered a potentially significant problem running DOSapplications under Windows 95 on a Windows NT-based network. My company hasseveral 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 problemsduring network intensive operations. The errors usually show up in the form of aDrive Not Ready error for the network drive mapping where the program resides.Although I have seen other application-specific errors, in all cases, theapplications appear to lose their network connection to files on the NT server.The applications usually terminate abnormally, often causing file and datacorruption. 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.

—Jeff Nickles
[email protected]

Fixing a Boot-Sector Virus
I recently came across a Windows NT workstation infected with the AntiEXEboot-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.

—Steve Hong
[email protected]

Scheduling External Appointments in Outlook andSchedule+
If you're using Outlook 97 or Schedule+ and MS Exchange for email, you canschedule 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 orreject 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.

—Dennis Martin

Replicating Netlogon Shares on the BDCs toEnforce Policies
In Sean Daily's article, "Further Explorations of the NT System PolicyEditor," the author discusses the fact that the ntconfig.pol file (orconfig.pol for Windows 95) needs to be on the Netlogon share of the PrimaryDomain 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%system32replexport 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.

—Ron Melanson, MCSE
[email protected]

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