Send us your tips and questions. You can also visit Bob Chronister's online Tricks & Traps at http://www.winntmag.com/forums/index.html.
Q: I'm trying to convince my company to upgrade its desktop systems to Windows NT Workstation 4.0. Can you provide any insight into the differences between NT 4.0 and Windows 9x?
I frequently get questions about the differences between NT 4.0 and Win9x. This question is especially important and deserves careful attention when you're deciding which systems to implement. Let me give you facts that might help in your decision.
NT 4.0 lets you run 16-bit Windows programs in their own address space. This feature helps prevent any one application from corrupting or unexpectedly stopping other applications that run in the same address space. Win9x doesn't offer this functionality.
NT 4.0 supports multiprocessor systems, and Win9x doesn't. This functionality is especially significant in high-end graphic and CAD environments.
NT 4.0 offers file-by-file security, and Win9x doesn't.
NT 4.0 is truly 32-bit, and Win9x contains a significant amount of 16-bit code. As a result, Win9x systems can run more DOS and 16-bit programs than NT.
Primarily because of the 16-bit code, Win9x contains significant non-reentrant code, and many threads run in single-thread mode. As a result, Win9x isn't as robust at multitasking as NT.
Win9x contains several operating system (OS) pages that applications can write to from user mode. As a result, many of these user applications can crash the system, which makes NT more robust than Win9x.
Q: I installed Windows NT on a Digital HiNote Ultra 2000 notebook. I can't get the system to register on the network, and I get a No domain controller can be found error message. A Digital support technician told me the message was meaningless. However, I still can't access the domain. Can you help?
The error message you received can be benign, but it often indicates a general logon failure and denial of network resources. The Ultra 2000 (for a review of this system, see Brian Gallagher, "Digital HiNote Ultra 2000," page 98) has a built-in Xircom network chipset. You are receiving the error message when you try to connect to the network because the driver for the network chipset is not properly initializing the built-in network adapter. To resolve this problem, you can boot into NT and perform a software reboot to initialize the network adapter and let you access the network. Or, you can start the boot process and refrain from logging on to the network for about 5 minutes to allow time for slow services to respond (an ugly approach, but one that works).
Q: About once a month, my Primary Domain Controller (PDC)/application server and database/print server experience unexplained periods of 100 percent CPU usage. Windows NT Event Viewer doesn't show any unexplained processes or errors, and Task Manager provides no insight into the problem. I must reboot the servers. What's causing this problem?
Experiencing unexplained periods of 100 percent CPU usage is not a simple problem with a simple solution. I suggest you use Performance Monitor to carefully analyze your network and ensure that your network performance is constant. I have seen businesses reboot their servers every Sunday for the same reasons you describe.
Task Manager shows you many active processes, but not necessarily all active services. For example, Screen 1, page 218, shows several services running in the Control Panel Services applet on a PDC that also serves as a TCP/IP print server. In contrast, Task Manager lists the processes running, as Screen 2 shows, but doesn't display all the network services.
If you activate a CPU-intensive application, Task Manager lists the process. For example, if I send a 10MB color .tif file to the print server, the CPU utilization for the spoolss.exe (i.e., print server) process jumps to 98 percent. This activity can freeze the server until the system finishes the print job rasterization. This type of bottleneck is easy to spot because you can see it by viewing the processes in Task Manager. However, if you have a network-related (e.g., TCP/IP) bottleneck, you can't see it in Task Manager; you have to use Performance Monitor or a network monitor to view the details of your network problems (for information about using these tools, see the Microsoft Windows NT Server 4.0 Resource Kit).
I have seen several network problems cause memory leaks and increased CPU utilization. Start by examining the network cards on your network. Are the network cards on the problem servers different from other cards on the network that don't exhibit the problem? If so, change the network cards on the problem servers to match the other network cards. Are you running Messaging API (MAPI) 32 applications? MAPI32.dll can easily cause 100 percent CPU utilization. In short, check to see what hardware and software you're running on the problem servers that aren't running on the other systems on your network.
Q: My company has a local Backup Domain Controller (BDC) and a remote Primary Domain Controller (PDC) that connect across a WAN. If I restart the BDC after both servers have been running for more than 30 days, all future local user logons will process the logon script from the PDC only, even though the BDC appears to be functioning as usual. If I reboot the PDC, the logon scripts will run again from the BDC. Do you have any suggestions?
Rebooting a BDC can cause the system to act as a backup browser. As a result of the reboot, the PDC and not the BDC authenticates any client attempting to log on to the network. To correct this situation, you need to use the Windows Internet Naming Service (WINS) in m-node. NT enables m-node broadcasts when the WINS server and PDC are on one side of a router and the BDC and workstations are on the other side of the router. You don't want broadcasts to travel across the WAN to the PDC (unless routing is necessary), and m-node broadcasts stay on the local segment of the network before authenticating the user logon. The m-node method of name resolution uses the b-node method first and then uses the p-node method. The m-node method doesn't increase performance, but it lets name queries (NetBIOS) occur locally using b-node resolution.
Another way to ensure that the BDC authenticates some local user logons is to set up the BDC as a WINS server and assign IP addresses to clients manually or using Dynamic Host Configuration Protocol (DHCP). As a last resort, you can skip WINS and load the BDC's IP address and domain in the clients' LMHOSTS file. To load this information, you enable LMHOSTS lookup and give every workstation a copy of the LMHOSTS file with the BDC address included. For more information about using WINS and LMHOSTS files, see Darren Mar-Elia, "Implementing Enterprisewide WINS," November 1997.
Of related interest, you might want to tune TCP/IP to work better over the WAN and perhaps help with some of your problems by maximizing performance. Be aware that tuning TCP/IP entails hacking the NT Registry, so make sure you have a recent backup of the Registry. For more information about optimizing TCP/IP across the WAN, see Microsoft Support Online article Q140552, "How to Optimize Windows NT to Run Over Slow WAN Links w/ TCP/IP," (http://support.microsoft.com/support/kb/articles/q140/5/52.asp).
Q: When I ran the chkdsk command on my NTFS volume, I received a message that said the system discovered minor inconsistencies on the disk. I tried to run the chkdsk /f command, but the problem recurred. How serious is this problem?
The chkdsk command message is generally benign and relates to the way Microsoft designed NTFS. If the message states that the inconsistencies are minor, don't worry about the message. If chkdsk finds serious cluster-related problems, you will see a message in the event logs and you will probably need to replace the drive.
Q: Several of my company's customers use Windows NT 4.0 servers and Windows 95 or NT 4.0 clients. These customers use Pervasive Software's Btrieve 5.12 to access the DOS-based portions of my company's database and Btrieve 6.15 to access the Windows-based 32-bit portions of the database. Aside from the Registry setup and shortcuts on the workstations, the software is completely contained on the server. Many of these customers experience file locks when they access the database files. What's causing this problem?
Before you can resolve the problems associated with file locks, you need to understand how opportunistic locks (Oplocks) work. With many versions of Btrieve, Oplocks can pose a serious performance and access problem. Fortunately, you can hack the Registry to modify Oplocks.
Oplocks increase network performance by letting clients dynamically control file buffering locally. The three types of Oplocks are exclusive, batch, and Level II. With an exclusive Oplock, the client opens a file in a non-exclusive (deny none) mode and requests an Oplock of the entire file. As long as no other process has the file open, the server grants the Oplock to the client. The Oplock gives the client exclusive access to the file; lets the client perform read-ahead, write-behind, and lock caching; and prevents other processes from opening the file. When a second process attempts to open the file, the server asks the original owner to Break Oplock or Break to Level II Oplock. At that point, the client must invalidate cached data, flush writes and locks, and release the Oplock or close the file. This process can slow performance dramatically.
I won't go into detail about batch Oplocks here because they don't relate to this particular situation. However, batch Oplocks help reduce unacceptable amounts of network traffic that client programs cause.
Level II Oplocks provide a method for granting read access to a file by more than one client. These clients can cache read data (i.e., read-ahead) locally. As long as no client writes to the file, multiple clients can open the file using Level II Oplocks.
To access the file, the first client requests an Oplock for that file from the server. If no other client has the file open, the server grants the first client an exclusive Oplock. When the second client requests to open the file that the first client has open, the server asks the first client to Break to Level II Oplock. The first client complies by closing the file or by flushing locally buffered locked information to the server. If the first client flushes the information to the server, the first client informs the server that it has gone to Level II Oplock. The server can now respond to the second client's request to open the file and grants Level II Oplock access to the second client. Any other client on the network can open the file, and the server will assign that client Level II Oplock. When any client sends a write request Server Message Block (SMB), the server asks all clients to break-to-none (no Oplocks held by any client). To comply with this request, the clients flush all locally cached read-ahead data.
You can control and change how NT uses Oplocks by altering the Registry. In some cases, you might need to add the necessary keys. Make sure you back up the Registry and are prepared for system failure before you start changing Registry values.
To control whether the client uses Oplocks, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters Registry key and edit the UseOpportunisticLocking parameter. This parameter is of type REG_DWORD, takes a value of 0 (false) or 1 (true), and defaults to 1. Disable this parameter to isolate problems.
To specify whether the server lets clients use Oplocks on files, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters Registry key and edit the EnableOplocks parameter. This parameter is of type REG_DWORD, takes a value of 0 (false) or 1 (true), and defaults to 1.
To specify the minimum link throughput the server allows before it disables raw I/O and Oplocks for this connection, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters Registry key, and edit the MinLinkThroughput parameter. This parameter is of type REG_DWORD, takes a value of 0 bytes per second (bps) to infinite bps, and defaults to 0.
To specify the maximum time allowed for a link delay, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Par-ameters Registry key, and edit the MaxLinkDelay parameter. If delays exceed the value you specify for this setting, the server disables raw I/O and Oplocks for this connection. This parameter is of type REG_DWORD, takes a value of 0 seconds to 100,000 seconds, and defaults to 60.
To specify the amount of time the server waits for a client to respond to an Oplock break request, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Par-ameters Registry key, and edit the OplockBreakWait parameter. Using a small value for this setting lets the server detect crashed clients quickly but can cause you to lose cached data. This parameter is of type REG_DWORD, takes a value of 0 seconds to 180 seconds, and defaults to 35.
Q: I have three Backup Domain Controllers (BDCs) and one Primary Domain Controller (PDC) in one domain. One of the BDCs (CAINS11) recently crashed. When I brought the system back up, it sent the following message to the PDC (in the Event Viewer): The master browser has received a server announcement from the computer CAINS11 that believes that it is the master browser for the domain on transport NetBT_E100B1. The master browser is stopping or an election is being forced.
I tried demoting and promoting both servers, but I still get the error message. This problem doesn't seem to be affecting the network, but it keeps filling up the Event Viewer on the PDC. Any suggestions?
The error message you see is generally benign and is just informational. On a given subnet, Windows NT holds an election of one or more devices to determine which one will be master browser. The master browser is responsible for collecting browser information about the subnet and communicating with the domain master browser to build a list of all other devices in the domain. When you brought the BDC back up, it wanted to be the master browser for the subnet and forced an election. You can prevent the resulting message from filling the System Log in Event Viewer by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters value to false on the BDC. I don't advise you to make this change unless the problem is excessive and filling up the System Log in Event Viewer.
Q: I'm running two Windows NT Primary Domain Controllers (PDCs) controlling two domains, Domain 1 and Domain 2. Can I kill Domain 2 and set up that PDC as a shared PC running off Domain 1?
Once a domain controller, always a domain controller. You need to reinstall NT and any appropriate applications on the secondary system to reclassify it as a shared PC. I have seen many instances in which moving a domain controller to another domain wreaks havoc.
Q: I recently configured some machines to dual-boot DOS 6.22 and Windows NT 4.0 (both NT Server and NT Workstation). How do I hide the line that says MS-DOS V6.22 in the boot.ini file so users can't select this option when the machines boot up, but I can still access this option?
Hiding MS-DOS from your users is easy, but it requires the use of hidden batch files. You need to set up two batch files and name them appropriately. Start by making two copies of the boot.ini file that controls how the system boots.
Listing 1 shows an example boot.ini file. Notice the line C:\="MS-DOS". If you delete this line, you can no longer boot to DOS. To remove the line, you must remove read-only attributes from the file. Open a command prompt and type
Attrib r c:\boot.ini
Next, type
Copy boot.ini c:\boot1.ini
and
Copy boot.ini c:\boot2.ini
at the command prompt to make two copies of boot.ini. Boot1.ini will be the primary boot file, and boot2.ini will be the secondary boot file without the MS-DOS boot option. Open boot.ini by typing
Edit c:\boot.ini
at the command prompt. Remove the line C:\="MS-DOS". Now when you boot the system, the only boot option you'll see is NT.
To switch from one boot.ini file to another, you need to create two batch files: dos1.bat (I add the number 1 in the filename to keep users from typing DOS) and nt.bat. At the command prompt, type
Copy con dos1.bat
and
Copy c:\boot1.ini c:\boot.ini
Press F6 to finish creating the batch file. When you want to boot to DOS, you simply run dos1.bat. After you run this batch file, the system will ask whether you want to replace the old boot file; say Yes. When you want to remove the MS-DOS option from the boot menu, run the nt.bat file. To create this batch file, type
Copy con nt.bat
and
Copy c:\boot2.ini c:\boot.ini
at the command prompt. Press F6 to finish creating the batch file. After you run this batch file, the system will ask whether you want to replace the old boot file; say Yes. I realize this process is cumbersome, but it is the best solution to your problem. (Be sure to add hidden attributes to both batch files.)
