This article contains background and tips for understanding Windows network browsing and Windows file sharing.

This document is a starting point for administrators wishing to configure and use the new Windows File Sharing service of AppleShare IP 6. The intended audience is all AppleShare IP 6 administrators, regardless of experience with AppleShare or Windows networking.

This document contains two major sections:

• The "Overview" section provides a summary of the issues involved in making Windows networking work properly, and compares it to Macintosh (AppleTalk) networking.
• The "Putting it Together" section is intended to help administrators get AppleShare's new Windows File Sharing service up and running on their networks.

The technical name for the Windows file sharing protocol is Server Message Block, or SMB. This is the protocol that Microsoft uses for file sharing in Microsoft LAN Manager, Windows for Workgroups, Windows 95, and Windows NT.

SMB runs on top of a protocol called NetBIOS, which can run on top of several other protocols such as NetBEUI, Novell IPX, and TCP/IP. Please note that AppleShare IP supports SMB only through TCP/IP.

A Comparison of Windows and Macintosh Network Browsing and Name Resolution Systems

To understand the differences between Windows and Macintosh network browsing and name resolution systems, it is important to know the terms and to know a little bit about the differences in the protocols used.

Network browsing is the act of viewing and exploring a list of currently available resources on a network. The combination of network protocols and software that allows a user to browse a network is known as a network browsing system.

Name resolution is the act of determining the numerical address of a network resource, given its name. Name resolution is a necessary feature of any networking system because computers must use numerical addresses, not names, to connect to other computers on a network. Think of name resolution as the network equivalent of the telephone companies' Directory Assistance services.

How it Works on Macintosh

AppleTalk's Name Binding Protocol (NBP) is both a network browsing protocol and a name resolution protocol. When a Macintosh user opens the Chooser and selects AppleShare, the Macintosh sends out an NBP lookup request to the current zone asking for all AppleShare-compatible servers to identify themselves. This allows the user to get an immediately up-to-date list of all the available servers, but the trade-off is that it causes a flurry of network activity whenever the Chooser is opened. No separate name resolution system is required because the list of available resources generated by NBP also includes their AppleTalk node addresses, even though that information is not displayed in the Chooser. When the user double-clicks on a server in the list, the AppleShare client is able to use the AppleTalk node address of the server to contact it via AppleTalk. If the server supports AppleShare through TCP/IP, it informs the client and the client switches over and connects through TCP/IP.

How it Works on Windows

In the Windows networking world, the network browsing protocol is separate from the name resolution protocol. Because of this, there can be situations when you can connect to resources that you cannot "see" browse to), and you can see resources to which you cannot connect. In order to "see" the AppleShare IP server in the Windows client's Network Neighborhood, Windows network browsing must be configured correctly on the computers on your network. In order to then double-click on the name of a server in the list to connect, name resolution must be configured correctly on the computers on your network.

Windows Network Browsing

The Windows network browsing scheme is very conservative with the amount of network traffic it generates, and the trade-off is that it is very slow to update the list of available servers on your network. To conserve network bandwidth, the Windows clients are completely dependent on one computer in each workgroup or domain, in each IP subnet, to act as a "Browse Master". This computer maintains the list of available servers in that workgroup or domain on that subnet and caches it for a certain period of time so that servers on the network do not have to announce their presence as often.

When a Windows 95 user opens the Network Neighborhood window, Windows asks the Browse Master for its workgroup or domain to give it a list of the servers in the same workgroup or domain. This list, called the browse list, may be significantly out of date because most servers only announce their presence every 15 minutes. In some cases it can take almost an hour for a server to appear in the browse lists of all the Browse Masters on a network. This is a limitation of the protocol and administrators can do very little about it.

Windows Name Resolution

Even if a Windows computer can see the AppleShare IP server in the Network Neighborhood, it still may not be able to connect. In order to connect, the client must have a way to find out the AppleShare server's IP address given its name. In other words, it must have some way to resolve the AppleShare IP server's name. There are several ways for a Windows computer to resolve the name of server:

• Subnet broadcast. If the AppleShare IP server is on the same IP subnet as the client, the client should be able to find out the server's IP address by sending out a request to its entire subnet. Subnet broadcasts do not get passed across routers, however.
• WINS query. If there is a Windows Internet Name Service (WINS) server on the network, and the Windows client is configured to use it, the client can ask the WINS server to tell it the IP address of the AppleShare IP server. In order for this to work, the AppleShare IP server must be configured to register itself with the WINS server.
• LMHOSTS file. The client can be configured with a text file that contains the name-to-address mappings it needs to know. On Windows 95, this file is usually "C:\WINDOWS\LMHOSTS". Consult the file "C:\WINDOWS\LMHOSTS.SAM" for more information. On Windows NT, any properly-written text file can be imported. This is done from the "WINS" tab in the Properties window for the TCP/IP protocol component in the Network control panel.
• DNS query. If all of the above fail, the conventional Domain Name Server may be queried, if the client is configured to do so.
• HOSTS file. If even the DNS server can't resolve the name, the HOSTS file may be consulted, depending on the client's configuration. The HOSTS file is very similar to the LMHOSTS file.

Putting it Together

These are the basic steps required to get AppleShare IP 6's Windows File Sharing service working:

1. Configure the AppleShare IP Server
2. Configure the Windows Clients
3. Optional: Configure the Network to Support Windows Network Browsing
• Browsing in One Subnet
• Browsing Across Subnets
4. Make Sure a Suitable Name Resolution Scheme Is Operational
• Name Resolution in One Subnet
• Name Resolution Across Subnets
5. Connect!
• Connecting With Network Browsing
• Connecting Without Network Browsing

A: Configure the TCP/IP control panel properly.

B: Use AppleShare IP 6.3.1 Mac OS Server Admin to enable the Windows File Sharing service, giving the server a valid Windows network host name (less than or equal to 13 characters, generally avoiding punctuation and special characters), and a valid workgroup name or Windows NT domain name.

Tip: If practical, make the Windows network host name for your AppleShare IP server match its unqualified DNS host name. For example, if your DNS has an entry for your server as "asip1.mycompany.com", give your AppleShare IP server the Windows network host name of "asip1". This should help solve some name resolution issues described later in this document.

Tip: If any Windows NT domains are available on the subnet, use one as AppleShare IP's workgroup name. This helps with cross-subnet network browsing, because NT domains can cross subnets, but workgroups cannot.

Critical: AppleShare IP supports Windows file sharing via TCP/IP only.

The "Client for Microsoft Networks" and "TCP/IP Protocol" network software components must be properly installed and configured on your client PCs in order for them to connect to AppleShare IP 6 via Windows File Sharing.

Note: On Windows NT, the Client for Microsoft Networks is known as the "Workstation" service.

Tip: If you do not have any use for the NetBEUI and/or IPX (NWLink) network protocol stacks on your PC clients, consider removing those components. It makes network troubleshooting easier if you only have one protocol stack to worry about.

You should also check your network bindings on your PC clients to make sure that the Microsoft networking client is bound to NetBIOS, which is bound to TCP/IP, which is bound to the correct network adapter card. The details for checking bindings differ from release to release of Windows 95 and Windows NT.

In the Windows network browsing scheme, Windows clients do not maintain their own lists of servers available on the network. Instead, they depend on one computer on their subnet and in their workgroup or domain to keep track of this list. The computer that assumes this role is called the Browse Master, and the list it maintains is called the browse list.

Browsing in One Subnet
• Critical: Windows clients are completely dependent on the presence, on their subnet, of a Browse Master for their workgroup or NT domain in order to be able to see any resources on the network. If you want the AppleShare IP server to show up in the Network Neighborhood, you must have Windows network browsing properly configured on your network. However, this is an optional step. Clients anywhere on your network should still be able to connect to AppleShare IP even if they cannot see it in the Network Neighborhood. See the section below entitled, "Connecting Without Network Browsing".

• AppleShare IP does not currently have the ability to act as a Browse Master, so some other computer on the same subnet and in the same workgroup or domain must be configured to fulfill this role. Windows NT is configured to do this by default, and Windows 95 should also be able to do this as long as the "File and Printer Sharing for Microsoft Networks" software component is installed. You are not required to actually share files or printers from the Windows 95 computer, just have the software installed.

• AppleShare IP announces itself more often than Windows servers, but can still take a while to appear in the Network Neighborhood window. Limitations of the Windows networking protocols can delay the server's appearance by anywhere from fifteen to fifty-eight minutes. Selecting the "Refresh" command from the Network Neighborhood window's "View" menu can not help; it does not cause servers to re-announce themselves, so the browse list may remain out of date.

• Note: For optimum performance you should plan on having just one computer acting as the Browse Master and just one additional computer acting as the backup Browse Master for each workgroup or domain on each subnet. Any more than that and your network performance can be adversely affected as computers iterate through the process of selecting a Browse Master.

• Experienced Windows network administrators can disable the Browse Master service on all but one or two computers, per workgroup/domain, per subnet. This also aids troubleshooting by making the computer acting as the Browse Master easier to identify.

• To disable the Browse Master service on Windows 95 computers, open the Properties window for the "File and Printer Sharing for Microsoft Networks" software component. You can do this from the Network control panel. Once you have the Properties window open, select the "Browse Master" variable from the list on the left, and set the pop-down menu on the right to "Disabled". For best results, remember to fix this setting whenever you reinstall Windows or add a new Windows computer to your network.

• Tip: Since all of the other Windows clients can rely on the Browse Master systems for their ability to browse the network, make sure the computers acting as your Browse Masters are either always powered on, or are always the first computers to be turned on and the last computers to be turned off.

Browsing Across Subnets
• If all of your PC clients are on the same IP subnet as your AppleShare IP server, configuring Windows Network Browsing is a trivial task, as explained above. However, if you have PC clients on separate subnets from your AppleShare IP server, it takes quite a bit of effort to get browsing working properly.

• The main issue is that workgroups cannot span subnets, but domains can. If you have one workgroup name on two separate IP subnets, it actually functions as two separate workgroups. For example, if you have ten computers in the workgroup "WG1" on one side of a router, and ten computers in the workgroup "WG1" on the other side of the router, you can not see one workgroup named "WG1" with 20 computers. You should not even be able to see both WG1's at the same time. On each side of the router, computers should see one workgroup named "WG1", and it should only contain those computers on the same side of the router.

• In order for browsing to work across subnets, your computers should all be members of domains. In order to create domains, you need special software that can make a computer act as a Domain Controller. Domain Controllers enable browsing across subnets by working with the subnet Browse Masters to collect, consolidate, and redistribute the browse lists for all of the subnets in the domain.

• At installation time, Windows NT Server can be configured to be a Domain Controller. AppleShare IP is not currently capable of acting as a Domain Controller.

• When you have finished creating a domain by setting up a Domain Controller, you must make sure that each subnet has a local Browse Master for that domain. See the instructions for "Browsing in One Subnet" for details. You must also make sure that all of your Browse Masters and Domain Controllers can resolve the names (find the IP addresses) of all the other Browse Masters and Domain Controllers on your network. See the next section for information on ensuring that a suitable name resolution scheme is in place on your network.

Whether you double-click on the name of the AppleShare IP server in the Network Neighborhood or enter its network path by hand in the PC-style \\servername\sharename notation, your client computer needs some way to discover the IP address of the AppleShare IP server in order to connect.

Name Resolution in One Subnet
• If all of your PC clients are on the same IP subnet as the AppleShare IP server, they can find the IP address automatically using subnet broadcasts.

Name Resolution Across Subnets
• If you have PC clients on a different subnet than the AppleShare IP server, you may have to provide some other way for them to find the IP address of the server.

• For small installations of PC clients, the easiest way to provide name resolution across subnets is to create special text file, called an LMHOSTS file, that lists the names and IP addresses of the computers in other subnets to which the PC clients may need to connect.

• For large installations of PC clients, the easiest way to provide name resolution across subnets is to set up a Windows Internet Name Service (WINS) environment.

• Note: Internet-style Domain Name Service (DNS) can also be used for Windows network name resolution, but support for DNS name resolution is significantly different between Windows 95 and Windows NT, making it unsuitable for use in conjunction with network browsing. WINS is preferable in most cases. If you want to try DNS name resolution on your network, note two things:

a. Your AppleShare IP server's unqualified DNS host name should be the same as the Windows network host name you gave it.
b. From Windows 95/98, you should be able to connect manually by using a path in the form:
\\UnqualifiedDNSHostName\ShareName
c. From Windows NT, you should be able to connect manually by using a path in the form:
\\FullyQualifiedDNSHostName\ShareName or
\\UnqualifiedDNSHostName\ShareName

Name Resolution Using LMHOSTS Files
• In Windows 95, the LMHOSTS file is usually "C:\WINDOWS\LMHOSTS". You can look at the file "C:\WINDOWS\LMHOSTS.SAM" to see examples and further explanation.

• In Windows NT, any text file can be imported for use as the LMHOSTS file. Click Start -> Settings -> Control Panel -> Network -> Protocols -> TCP/IP Properties -> WINS to set this up.

• Note: For network browsing to work properly on your network, all Browse Masters and Domain Controllers must be able to resolve the names of all other Browse Masters and Domain Controllers. Remember this as you set computers to be Browse Masters and configure their LMHOSTS files.

Name Resolution Using WINS
• WINS is a dynamic, DNS-like, server-based name service that Windows clients natively support. WINS is appropriate for large PC client installations, because it saves the administrators from having to manually install and update LMHOSTS files on all clients.

• AppleShare IP cannot currently act as a WINS server, so you would need Windows NT Server or Samba -- a free "Windows networking" software package for Unix -- in order to provide a WINS server. Once you have a WINS server running, set all of your PC clients to use WINS. This is done on the WINS tab of the TCP/IP protocol properties window, which is accessible through the Network control panel. Also be sure to configure your AppleShare IP server to use WINS by way of the server administration software.

You are now ready to connect to AppleShare IP from a Windows client.

Follow these steps to connect:

1. Log into a Windows client using an account name and password as you configured in step 1c.
2. If network browsing is working on your network, follow the instructions in "Connecting With Network Browsing".
3. If network browsing is not working on your network, follow the instructions in "Connecting Without Network Browsing".

Connecting With Network Browsing
• If network browsing is working on your network, you can connect to the AppleShare IP server from a windows client by finding the server inside the Network Neighborhood.
• Critical: If the AppleShare IP server does not show up immediately, wait. If you set up network browsing correctly in step 3, all you have to do now is wait for the AppleShare IP server to show up in the browse lists. In the Windows networking world, servers conserve network bandwidth by announcing their presence only rarely. Also, Browse Masters share their browse lists with each other only rarely, which can compound the problem when there are multiple workgroups, domains, and subnets.

• If the AppleShare IP server is in the same workgroup/domain as the client, it should appear in the immediate Network Neighborhood window. Double-click on it to connect.

• If the AppleShare IP server is in a different workgroup or domain, go into Network Neighborhood -> Entire Network -> Microsoft Network, open the appropriate workgroup/domain, and double-click on the server.

Connecting Without Network Browsing

You can connect to AppleShare IP's Windows File Sharing service without being able to browse to it. One way is by using the Windows "Find Computer" utility. Note, this still requires some sort of name resolution.


1. Make sure your Windows username and password matches your AppleShare IP username and password. Re-login to Windows if you need to.
2. Click Start -> Find -> Computer
3. Enter the name of your AppleShare IP server.
4. Your AppleShare IP server should appear in the list of "found" items. Double-click on it to connect.

If you still cannot connect, test your IP configurations and network functionality by pinging the server from the client.

1. On the client, click Start -> Run.
2. Enter...

ping ServerIPAddress

...into the window that comes up. Substitute the actual IP address of your server for ServerIPAddress.