SEND US YOUR TIPS AND QUESTIONS.
You can also visit Bob Chronister's online Tricks & Traps at http://www.winntmag.com/ forums/index.html.


Be Prepared for Disaster
The region I live in has been subject to some nasty weather over the past few months. I thought I had everything under control, but I was unknowingly unprepared for the severe power outages and extensive line-voltage fluctuations. Despite all my UPSs, I lost an Axis print server, a computer running Windows 95, and the power supply of an asynchronous transfer mode (ATM) switch. As I discovered these losses, I began searching for the culprits. I found that three of my UPSs had faulty batteries, and I realized I hadn't checked these UPSs in 2 years. However, the neglected UPSs didn't account for the damage that the line-voltage fluctuations caused. To my disgust, I found out that the power company had refused to put a surge protector on my house because my house is not properly grounded. I am having the power company place a grounding rod on the house power system and add an external surge protector, which costs less than $5 per month. I feel lucky for how little damage I sustained considering how unprepared I was.


Tip of the Month
When Microsoft released Windows NT 4.0, problems (e.g., NT not recognizing Eagle cards) existed with the software-set NE2000 network cards. To solve this problem, you had to boot to DOS and set the IRQ and I/O. The problem is back, and it's worse. Plug and Play (PnP) firmware on the new ASUS motherboards, which are mainly PCI and have only two ISA slots, doesn't recognize older network cards on a cold boot. To solve this problem, you have to boot to a DOS disk, run the card setup, and soft boot the machine. What's the moral of this story? Throw away your old ISA NICs!

Q: When I turn on my machine, it runs very well and very fast. However, within a few minutes the system slows down and sometimes stops. Do you have any idea what's causing this problem?

I'm willing to bet you have a defective CPU fan. I suggest you change the fan to resolve your problem.

Q: I'm setting up a combined Token-Ring and Ethernet environment, and I'm concerned about source routing. Can you explain source routing and how I can avoid problems?

The differences between Token-Ring and Ethernet networks affect this complex situation. In Token-Ring environments, a source computer builds a picture of the network that it uses to determine the best route to a destination. The source computer inserts a list of these routes in the upper-half of the Open Systems Interconnection (OSI) model's data link layer. Then, TCP/IP resolves names to IP addresses, resolves the IP addresses to media access control (MAC) addresses, and finally routes the data from the source to the destination. TCP/IP attaches all this information to the IP header. The IP header is 20 bytes and contains optional fields that you can append to the header. These optional fields include record route, strict source and record route, and loose source and record route. When an application establishes a connection, it can request one of these options.

For an example of source routing, let's use the ping command to send data from a system with an IP address of 10.1.1.1 to a destination of 14.1.1.1 using strict source routing (i.e., the network allows no intermediate gateways):

ping -n 1 -w 5000 -k 11.1.1.1 12.1.1.1 13.1.1.1 14.1.1.1

This command tells the network to send one ping to 14.1.1.1, with a 5-second timeout interval. However, rather than rely on automatic routing mechanisms, we told the network to use strict source routing via routers 11.1.1.1, 12.1.1.1, and 13.1.1.1. This command means that the source computer must send the packet directly to 11.1.1.1, which forwards the packet to 12.1.1.1, which forwards the packet to 13.1.1.1, which delivers the packet to 14.1.1.1. If a router can't comply, it must return an error.

In this command, we used the following specific ping switches:

  • -n, which denotes the number of ECHO packets sent (the default is 4)
  • -w, which specifies a timeout interval in milliseconds
  • -k, defines the route (IP allows up to nine addresses) that the packets will follow

In addition, you can add a destination list that specifies the remote computers to ping.

At each hop, the router substitutes the IP address of the outgoing interface that it used (e.g., router 11.1.1.1 might use interface 12.1.1.2 for its link to router 12.1.1.1). Thus, the header records the route taken. The destination IP address reverses the recorded route to reply.

When you use the -k switch, you tell the network to use strict source routing. Use the -j switch to indicate loose source routing, in which each router must send the packet to the next indicated hop but might send the packet via intermediate routers.

In your situation, Windows NT sets the source routing bit in all IP addresses by default. Transparent bridges can discard source routing information that travels from Token-Ring to Ethernet media. The problem is with the IP-to-physical address translation tables that the Address Resolution Protocol (ARP) uses. To solve the problem, you need to change a Registry setting.

To configure an NT 4.0 system to send IP broadcasts without source routing, you must add the following parameter to your Registry. In the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services\Tcpip\Parameters Registry key, add

ArpAlwaysSourceRoute

of type REG_DWORD. Set this parameter to 0, which disables source routing.

Q: Can I move a domain controller from one domain to another?

I moved a Primary Domain Controller (PDC) from one domain to another without demoting the PDC to a Backup Domain Controller (BDC). I used Systems Internals' NewSid utility (http://www.sysinternals.com) to assign a new security ID (SID) to the domain controller I wanted to move. This new SID eliminated any possible security relationship between the old domain and the new domain (previously, these domains existed in a trust relationship).

The old domain was Bobsplace3. I changed the name of Bobsplace3 to Bobsplace2, and the system told me that I had to change all security issues and trusts. I clicked OK and the system welcomed me to Bobsplace2. After I rebooted, the server easily joined Bobsplace2; however, the new domain saw Bobsplace2 as a workstation rather than a PDC or server. The PDC didn't recognize the user for the new member of the domain; thus, I had to add a user to the machine. After I finished this setup, everything seemed to function fine. However, if I reboot the new domain with the PDC off, the PDC moved from Bobsplace3 and became the new PDC of Bobsplace2—once a domain controller, always a domain controller.

If I had demoted the original PDC to a BDC and then joined the new domain, I could have run NewSid and synced the SIDs. The new system would become a BDC for Bobsplace2. Running NewSid increases the Registry size; as a result, I am uncertain if changing or syncing SIDs leads to any long-term effects.

When multiple PDCs exist on a network, you can choose which PDC to demote by colliding its Netlogon service with the other PDC's Netlogon service. The first computer to successfully start the Netlogon service and browser service will remain the PDC. Thus, you can demote the PDC that tries to start its Netlogon service second.

Q: How do I turn off printer notification banners in a mixed Windows NT and Novell NetWare environment?

I have answered this question several times, but it's a valid question worthy of repeating. The solution is a simple and relatively innocuous Registry change.

Open your favorite Registry editor and go to the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Print\Providers key. Set NetPopup of type REG_DWORD to 0, as Screen 1 shows. This modification should solve the problem.

Q: We currently run a mixture of Windows 98 and Win95 workstations, and we want to upgrade to Windows NT 4.0. Will we have problems converting to NT, and will Win95 applications run on NT 4.0?

You can't upgrade from Win98 or Win95 to NT 4.0. As a result, you'll have to reinstall all applications on each machine when you upgrade to NT 4.0. How difficult this upgrade will be depends on the complexity of your current applications and your system setup. NT and Win9x are 32-bit OSs, but they don't handle the Win32 APIs in the same manner: NT follows 32-bit conventions precisely and supports legacy drivers, which makes it more tolerant of poor 32-bit coding practices. Because of sloppy API use, some programs might try to make Win9x-specific API calls when running NT and subsequently fail.

Security might also cause problems. For example, if you set up an NT 4.0 system to run in NTFS, users might not have sufficient rights to access the needed aspects of a Win95 application. Also, NT is a Unicode OS. This factor might cause problems when you run a Win95 application, which passes ANSI information.

In my experience, most Win95 programs run well in NT, particularly new applications. Set up a few test machines and see what happens.

Q: When I use cmdlines.txt to run an automated installation of Service Pack 4 (SP4), I have a file copy problem with several files, including appserver.class, context.class, imtxas.class, objectcontent.class, and securityproperty.class. What is causing this problem?

All the files with copy errors have names that don't fit the DOS 8.3 format—cmdlines.txt uses the DOS 8.3 format. An easy workaround exists: Create an SP4 subdirectory in the $OEM$ directory. Next, copy sp4i386.exe or nt4sp4i.exe to the SP4 subdirectory. Add the following lines to your unattend.txt file:

\[Unattended\]
OemPreinstall = yes

Next, create a cmdlines.txt file in the $OEM$ directory that contains the following lines:

\[Commands\]
".\sp4\sp4i386.exe -z -u"

This workaround creates an unattended installation of SP4.