Q: After switching from Novell NetWare 3.12 to Windows NT, I have noticed that Novell is faster with network transfers than is Windows NT. How do I configure NT to achieve better network transfer rates?
To improve the rate of network transfers in NT, you have to increase the number of buffers that the redirector reserves for network performance. In some cases, the greater number of buffers can increase your network throughput. Each extra execution thread that you configure will take 1KB of additional nonpaged pool memory, but only if your applications use the memory. To configure buffers, you have to modify the Registry. Warning: Using the Registry editor incorrectly can cause serious, systemwide problems. You may have to uninstall NT to correct them. Use this tool at your own risk.
Use your favorite Registry edit tool to go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters key. Modify or add the value MaxCmds of type REG_DWORD (the range is 0 to 255, and the default is 15). Add the value MaxThreads of type REG_DWORD, and set it to the same value as MaxCmds. You can also increase the value of MaxCollectionCount. This value (type REG_DWORD) is the buffer for character-mode named pipes writes. This value defaults to 16, and ranges from 0 to 65535. Screen 1, page 218, shows these Registry settings. For more performance information, see Carlos Bernal, "NT vs. NetWare: File Services Grand Prix," page 62.
Q: Every time I look at Windows NT's Event Viewer, I see a lot of entries for browsers and elections. Is this normal? What can I do to prevent such messages?
Browser elections are normal occurrences in an NT network. The elections guarantee that only one master browser is present in the NT domain or workgroup. The election process also helps pass network information to systems as they log on to the network. NT elects master browsers according to the following priority:
* NT Server installed as a Primary Domain Controller (PDC)
* NT Server
* NT Workstation
* Other
NT automatically elects the PDC to be the Domain Master Browser even if the value IsDomainMaster is set to Yes in the Registry on another NT server within the domain.
If you are running workgroup servers (no domain controller) and want to force a server to be the preferred master browser, open the Registry and go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters key. Set the value IsDomainMaster to Yes. To prevent an NT workstation or server (non-PDC) from acting as a browser, open the Registry and go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters key. Set the MaintainServerList value to No.
Many times, Windows for Workgroups (WFW) or Windows 95 clients can cause serious browser contention. These systems are notorious for trying to be the Master Browser. To prevent a WFW system from acting as a browser, create and set the following statement in the \[Network\] section of System.ini of the WFW client:
MaintainServerList=No (other valid entries are Yes and Auto)
Win95 machines can participate in a browser election only if you configure them for file or print sharing. To set or check the browser settings, open the Network applet in the Control Panel on the Win95 system. Scroll the Network Configuration for File and printer sharing for Microsoft Networks. Highlight this entry, and click the Properties button. Select Browse Master, and choose from Disabled, Enabled, or Automatic. (For more information on how to increase your network's performance, see George Spalding, "Too Many Servers Spoil Network Performance," August 1997.)
Q: Many of the recent security holes found in Windows NT have to do with TCP/IP ports. What are these ports?
Port numbers fall into three ranges: Well-Known Ports, Registered Ports, and Dynamic and/or Private Ports. Well-Known Ports are those from 0 through 1023, Registered Ports are those from 1024 through 49151, and Dynamic and/or Private Ports are those from 49152 through 65535. Let me focus on the Well-Known Ports because NT is most susceptible to attacks using these ports.
The Internet Assigned Numbers Authority (IANA) assigns Well-Known Ports. On most systems, only system or root processes or programs that privileged users execute can access these ports.
TCP uses ports to name the ends of logical connections for long-term conversations. A service contact port lets you provide services to unknown callers, and the server process uses this port as its contact port. The service contact port is sometimes called the Well-Known port.
The assigned ports use a small portion of the possible port numbers. For many years, the assigned ports ranged from 0 to 255. Recently, the number of assigned ports that IANA oversees has expanded and now ranges from 0 to 1023. Table 1 lists some of these ports and describes their purpose. For a complete list of ports, go to http://www.isi.edu/div7/iana/.
Q: We have developed an application that sets the video resolution on the next startup. If we forget to run this shutdown application and use the Shut Down button on the Start menu, we have to set the video resolution on boot. How can we eliminate the Shut Down button?
Use your favorite Registry editor to go to the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer key. Add the value No Close of type REG_DWORD. Set this value to 1 to remove the Shut Down button from the Start menu. You will still be able to use Ctrl+Alt+Delete to shut down your Windows NT machine.
Q: Windows NT's Disk Administrator was working fine, but then stopped working. Now every time I open Disk Administrator, I get a memory violation message. How can I fix this problem?
The first time I ran across this problem was during the days of NT 3.1. I was using an application that suddenly would not open. No matter what I tried, I couldn't get the application to work. One day, I logged on as Administrator, tried the application, and it worked. It dawned on me that the user profile was corrupt. Unfortunately, I could not fix the profile. The easiest solution was to create a new user profile. I created a new user profile, and it ran the application just fine. I recommend that you create a new user profile or use the Administrator user profile. For the new profile to work in NT 4.0, the application in question must be common (i.e., the program must be accessible by everybody).
Q: Can you explain the term Network Basic Input/Output System (NetBIOS) and how Microsoft uses it?
First, everything I'm about to say regarding NetBIOS will change when Microsoft releases Windows NT 5.0, because you will no longer have to run NetBIOS over TCP/IP. In NT 3.5x and 4.0, NetBIOS is a requirement that defines a software interface and a naming convention, not a protocol.
In 1985, IBM introduced NetBEUI to provide a protocol for programs designed around the NetBIOS interface. Unfortunately, NetBEUI is a small protocol without a networking layer and therefore is not a routable protocol. In fact, NetBEUI is more a peer-to-peer protocol (Windows 95) than a client/server protocol. In contrast, running NetBIOS over TCP/IP (NetBT) provides the NetBIOS programming interface over the TCP/IP protocol. This configuration extends NetBIOS client/server programs to large LANs and WANs with true routing capabilities. Figure 1 shows how you can use NetBIOS with TCP/IP to create NetBT.
The NT Workstation, Server, Browser, Messenger, and Net Logon services are all direct NetBT clients that use the transport driver interface (TDI) to communicate with NetBT. NT also includes a NetBIOS emulator that takes standard NetBIOS requests from NetBIOS programs and translates them to equivalent TDI primitives.
NetBIOS Names
All NetBIOS names must be unique and 16 characters in length. NetBIOS names
identify available resources that NT registers dynamically when
computers and services start or users log on. NT uses a NetBIOS
Name Query to locate a resource by resolving the NetBIOS name to an IP address.
Microsoft networking components, such as NT's Workstation and Server services,
let the user or administrator specify the first 15 characters of a NetBIOS name
but reserve the 16th character to identify a resource type. (You can increase
the length of a single-element NetBIOS name by appending a NetBIOS Scope to the
NetBIOS name; e.g., bobspace.bobsplace.com. You can append a NetBIOS Scope
from the Network applet in Control Panel (open the applet, click the Protocols
tab, select the TCP/IP protocol, click Properties, and select the WINS Address
tab). As a general rule, I don't recommend appending NetBIOS scopes because
trusts can be broken, pass-through authentication can fail, and network setup
can become very complex.
NetBIOS Name Registration and Resolution
To locate NetBIOS resources, NT 3.5x and 4.0 computers use several methods
such as the NetBIOS name cache, NetBIOS name server, IP subnet broadcasts,
static LMHOSTS files, static HOSTS files, and Domain Name System (DNS) servers.
NT 3.1 used LMHOSTS files and standard broadcasts. NT 3.5x and 4.0 implement
Windows Internet Name Service (WINS) to let NetBIOS programs query the DNS
namespace by appending configurable domain suffixes to a NetBIOS name. This
NetBIOS name resolution depends on node type and computer configuration.
NT supports the following node types:
1. B-node (broadcast node)--Client uses standard broadcasts for name registration and resolution.
2. P-node (point-to-point node)--Client does not use broadcasts but instead uses only point-to-point name queries to a NetBIOS name server (in this case, a WINS server) for name registration and resolution.
3. M-node (mixed node)--Client uses broadcasts for name registration. For name resolution, the client tries broadcasts first. If the client does not receive an answer, it switches to p-node.
4. H-node (host node)--Client uses a NetBIOS name server (host) for both name registration and resolution. If the client cannot locate a name server, it switches to b-node. The client continues to poll for a name server and switches back to p-node when one becomes available.
5. Microsoft-enhanced--Client uses local LMHOSTS files or WINS proxies plus Windows Sockets gethostbyname() calls (using standard DNS and local HOSTS files) in addition to standard node types.
By default, most WINS clients are h-nodes. They attempt to use a WINS server to register and resolve names. If that attempt fails, they try local subnet broadcasts. A name server is preferable to broadcasts because broadcasts aren't usually routable and broadcasts add to the network noise because all computers on a subnet receive the broadcasts.
NetBT and DNS
For computers to talk to other computers using NetBT, you need a way to
resolve a NetBIOS name into an IP address. Although Windows-based networks use
NetBT for name resolution over TCP/IP, DNS is widely used to resolve names over
TCP/IP networks on the Internet. NT Server 4.0 provides expanded support for DNS
by implementing a DNS server.
A DNS name is similar to a NetBIOS name because it provides a user-friendly identifier for a computer or other network device. DNS computer names consist of two parts: a host name and a domain name. When combined, they form the fully qualified domain name (FQDN).
NetBIOS computer names are analogous to DNS host names. However, a DNS name can be as long as 255 characters, but the NetBIOS name is limited to 15 user-definable characters. (In NT, the default mode is the NetBIOS name. However, you can form an FQDN by removing the 16th character in the NetBIOS name and replacing it with a period and the DNS domain name. NT 4.0 accepts an IP address, an FQDN, or a NetBIOS name.)
How Does It Work? NetBT Sessions
NetBT sessions consist of an established connection between two names. For
example, when an NT workstation makes a connection to an NT server, a sequence
of events takes place. First, NT resolves the NetBIOS server name to an IP
address. Then, the network services establish a TCP/IP
connection from the workstation to the server, using port 139. Finally, the
workstation sends a NetBIOS session request to the server name over the TCP/IP
connection. Assuming the server is listening on that name, it will respond
affirmatively to establish the session.
After the computers establish the initial NetBIOS connection, the workstation and server negotiate a higher level network protocol for further use. Microsoft networking uses only one NetBT session between two names at any time. NT multiplexes any additional file or print sharing connections made after the initial connection over that same NetBT session. NetBIOS keepalives (network traffic that keeps the NetBT connection signal alive) are constantly maintaining these sessions.
For example, if a user shuts down a workstation abruptly, the server will eventually clean up the connection to that workstation and associated resources. The SessionKeepAlive Registry parameter, as you see in Table 2, page 220, controls the NetBIOS keepalives. The default setting for this Registry parameter is once per hour.
Subtle mistakes can cause serious and confusing NetBIOS errors. For example, did you ever wonder what Error 51 "remote computer not listening" means? If you use LMHOSTS files and misspell an entry, you can attempt to use the correct IP address but an incorrect name to connect to a server. In this case, NT will still establish a TCP/IP connection to the server. However, the server will reject the NetBIOS session request because the session request is using the wrong name and no IP address is connected with that name.
How Does It Work? NetBT Datagram Services
NT sends NetBT datagrams from one NetBIOS name to another over User Datagram
Protocol (UDP) port 138. The datagram service lets you send a message to a
unique name or to a group name. Group names can resolve to a list of IP
addresses or to a broadcast.
For example, the command net send /d:BOBSPLACE hello sends a
datagram containing the text hello to the group name
Destination MAC address: broadcast (255.255.255.255)
Source MAC address: The NIC address of the local computer
Destination IP address: The local subnet broadcast address
Source IP address: The IP address of the local computer
Destination name:
Source name:
All hosts on the subnet pick up the datagram and process it at least to the UDP protocol. On hosts running a NetBIOS datagram service, UDP hands the datagram to NetBT on port 138. NetBT checks the destination name to see whether any program has posted a datagram receive on it. If so, NetBT passes the datagram on. If no receive is posted, NetBT discards the datagram.
Registry Entries
NT stores several entries for NetBT in the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NetBt\Parameters key of the NT Registry. I've included several of these parameters, their settings, and a description of each in Table 2.
