Bit by bit, I'm leaving my preWindows 2000 network behind. I took a big step forward recently after I realized that my Win2K network was still supporting NetBIOS over TCP/IP (NetBT). Because NetBT is a fairly chatty protocol, I figured that using only DNS would speed up my network. (And it did, quite a bit.) So, I disabled NetBT on my servers and most of my workstations. Here's what I learned.
Disabling NetBT
To disable NetBT manually, right-click My Network Places and choose Properties to display the computer's TCP/IP properties. (You can use DHCP to disable NetBT on a system, but that process requires a fairly lengthy explanation, so I'll leave it for another day.) In the Network and Dial-up Connections window, you'll see an object for each network card on your system. Right-click the network card for which you want to disable NetBT, then choose Properties. On the Properties page, double-click the Internet Protocol (TCP/IP) object, then click Advanced on the Internet Protocol (TCP/IP) Properties page. Click the WINS tab, then click the Disable NetBIOS over TCP/IP radio button. Clear the Enable LMHOSTS lookup check box, then click OK until you've closed the pages. To verify that you've killed NetBT, you can type
ipconfig /all
on a command line. You'll see a line confirming that NetBT is disabled.
You can disable NetBT on a few systems without affecting your other computers, except of course that those other computers won't be able to use NetBIOS to communicate with the systems on which you've disabled NetBT. After you disable NetBT, you can shut down the Computer Browser service to recover some memory and simplify your system's software. If you don't do so, the Computer Browser service will eventually get tired of not being able to retrieve browse lists and will shut itself down.
Working Without Browsing
Shutting off NetBT greatly reduces the network's browsing functionality because the Computer Browser—the service manifested in Network Neighborhood, My Network Places, and the Net View command—sits atop NetBIOS. A machine on which you've disabled NetBT can't retrieve the workgroup browse list for a Windows NT 4.0 domain, nor can the machine retrieve the list of shares from a pre-Win2K server. And under no circumstances can that system use the Net Use command to access a share on a pre-Win2K server.
But browsing doesn't disappear altogether. You can still browse shares on another Win2K or later system. For example, suppose your workstation is part of an Active Directory (AD) domain named acme.com. If you type any of the following commands:
net view net view /domain:acme.com net view /domain:acme
you'll get the message There are no entries in the list. In other words, the Net View command can't list the servers in the domain. Similarly, if you open My Network Places and navigate to Entire Network, then go to the icon that represents your domain's workgroup, you'll find the list of servers empty. But if you happen to know the name of the Win2K server (the server must be a Win2K server; you can't attach to any shares on a pre-Win2K OS after you turn NetBT off), you can use the Net View command to list its shares without NetBT's help. For example, if you know that acme.com has a server named Bigserver, you can type
net view bigserver.acme.com
to list its shares. Notice that you don't need to type two backslashes (\\) before the server name—the server's DNS name is sufficient.
You can use the Net Use command similarly. For example, a command such as
net use x: \\bigserver.acme .com\share1
accesses the specified share. (Note that Net Use still requires those pesky backslashes.) You can also get to a share by opening Microsoft Internet Explorer (IE) and typing the share's Uniform Naming Convention (UNC) name in the Address bar—for example, typing \\bigserver.acme.com\share1 in the Address bar opens that share. Alternatively, you can click Start, Run and type the UNC name, or you can simply add \\bigserver.acme.com\share1 to your My Network Places folder. In short, connecting to a share doesn't change when you eliminate NetBT, but finding the share does change.
Browsing the AD Way
Life without a browser doesn't sound very appetizing. Can you bid NetBT adieu and still find network resources? Sure—simply publish them in AD.
You can use AD as a place to list and describe (i.e., publish) all the shares on a domain (and in other domains, for that matter). Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, right-click the icon for the domain or any organizational unit (OU) in the domain, choose New, then select Shared Folder. Type the folder's UNC name and a descriptive name for the shared folder, then click OK. You'll see that the domain now contains a shared-folder icon for the new share. You can open the share's Properties, click Keywords, and type keywords that users can use to search for folders that include those keywords.
When you use the Computer Browser, you poke around in the network's servers to look for a share. But with the AD approach, you don't care which server contains the share you want—rather, you're interested in the share's contents, or at least its name. Suppose you're looking for the share that contains the human resources (HR) forms. You can simply go to My Network Places, but instead of looking into each server to browse its shares, double-click Entire Network, then double-click the Directory icon. You'll see a list of shares, one of which is called HR Forms. You double-click the icon to open the share without knowing—or caring—which server it's on.
Furthermore, you can put a shortcut to that share on your desktop. When you publish shares in AD, shortcuts to those shares have a neat feature: If the shortcut's definition changes in AD—for example, if you move the HR Forms share to a different server—you don't need to change the shortcut. Whenever you click the shortcut, the shortcut goes to AD to determine the actual UNC, then uses it to open the share.
I want to mention one annoying thing about AD-published shares: Before you publish a share in AD, you must create the share in a separate step. Why Win2K servers don't automatically let you publish the share when you create it eludes me, particularly because every shared printer is published by default.
File Sharing Without NetBIOS Ports
What are the implications for firewalls and ports when you do file sharing without using NetBIOS? You can share files over any TCP/IP-based network—including the Internet—without using NetBIOS's infamous ports (i.e., UDP ports 137 and 138, TCP ports 137 and 139). Because Win2K on a NetBT-less network uses DNS to find computers and your network presumably is already using DNS without incident, no port changes are required. But according to the network traces that I saw while connecting to file shares, file sharing without NetBT uses both UDP port 445 and TCP port 445 as its source port.
Logons and Trust Relationships to NT 4.0 Domains
Keep in mind that NetBIOS does more than support browsing. When pre-Win2K systems try to log on a user, they use NetBIOS to find domain controllers (DCs). Thus, if you turn off NetBT on a Win2K system that's a member of an NT 4.0 domain, the Win2K system can't log on to that domain.
However, a Win2K system that tries to log you on to an NT 4.0 domain and fails because of a lack of NetBT support won't tell you that you didn't successfully log on. You can perform a simple exercise to verify that fact. Log on from a Win2K workstation or server that's a member of either an NT or an AD domain. Then, open a command line and type the Set command. You'll see the values of the environment variables on your system. One of the variables is logonserver=some-machine-name, where some-machine-name is the name of the DC that logged you on.
I've found that when I log on to an NT 4.0 domain from a Win2K system and examine the logonserver value, the value names some DC in the NT 4.0 domain, as you'd expect. But if I then disable NetBT, reboot the Win2K system, and log on with my NT 4.0 domain account, the logonserver value names the Win2K system, not a DC. Clearly, the Win2K system used cached credentials to log me on in that situation. In contrast, if I try to log on to the Win2K system with an NT 4.0 domain account that has never before logged on to the NT 4.0 system, I can't log on, and I get a message explaining that the Netlogon service isn't running.
Failed logons affect more than the user who wants to log on to a particular server. Connections between DCs support trust relationships: To facilitate users from the trusted domain logging on to the trusting domain's machines, every NT 4.0 DC from the trusting domain finds and logs on to a DC from the trusted domain. Therefore, if your Win2K AD DCs no longer respond to NetBT requests, those machines can't find and connect to DCs for trusted NT 4.0 domains. The trusts will fail, and both the NT 4.0 and AD DCs' event logs will contain messages stating that the machines couldn't find any DCs to correspond with.
Going NetBT-less is worth considering. At first, the lack of the Computer Browser service was disorienting, but after I published my shares in AD, I didn't miss the browser. And the NetBT-less logons seem considerably faster, although I haven't benchmarked them. If you don't need to communicate with pre-Win2K systems and you don't rely on NetBIOS-based server applications (a big if), disabling NetBT is an interesting way to streamline your network.
