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.