Browsing and Windows 95 Networking

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This document discusses technical details related to browsing for 32-bit, protected-mode network clients provided with Microsoft® Windows® 95

Published December, 1996

Introduction

The information in this document is provided for network administrators and others responsible for maintaining networks that include Windows 95 workstations. The focus here is the technical implementation of browsing with Microsoft networking, but details are also provided for the Novell® NetWare®-compatible peer server service called File and Printer Sharing for NetWare Networks.

This information supplements details about installing and configuring network services described in Microsoft Windows 95 Resource Kit. This document focuses on internal processes and topology issues. For information about how to use Network Neighborhood and other aspects of the user interface for browsing, see the Windows 95 online Help.

For more information about	See
Browsing with Windows 95 on Microsoft and NetWare networks, plus configuring browsing support for Windows 95 peer servers	Chapter 11, "Logon, Browsing, and Resource Sharing," in Microsoft Windows 95 Resource Kit, Microsoft Press, 1995. ISBN 1-55615-678-2.
Browsing on Windows NT™ networks, including technical details related to Windows Internet Name Service (WINS)	Windows NT Networking Guide (volume 2 in Microsoft Windows NT 3.5 Resource Kit), Microsoft Press, 1995. ISBN 1-55615-656-1.
Technical details about the implementation of Microsoft TCP/IP for Windows 95	Microsoft TCP/IP and Windows 95 Networking, a Microsoft Windows 95 white paper. Part number 098-61902.

Details from the Microsoft Windows 95 Resource Kit can also be searched and read online by using the WIN95RK.HLP file, which is available in the ADMIN\RESKIT\HELPFILE directory on the Windows 95 compact disc or with the Windows 95 Resource Kit utilities.

Note: In this paper, the term server refers to any computer that can provide resources to the rest of the network. A Windows 95 computer running File and Printer Sharing for Microsoft Networks, for example, is a server because it can share file or printer resources with other computers on the network. The computer does not have to be actually sharing resources to be considered a server.

In this document, any reference to Windows NT Server computers is always made explicitly. Any reference to Windows 95 computers in this document refers to computers running Windows 95 plus File and Printer Sharing services.

Microsoft Networking Browser System

The browser is a network resource enumeration tool first created for Microsoft Windows for Workgroups, and then adopted and enhanced for domain browsing on Windows NT networks. The Microsoft networking browser maintains a list, called the browse list, of all the available servers, workgroups, and domains (for Windows NT and LAN Manager networks). For example, when a user attempts to connect to any network resource using Network Neighborhood, the list of servers that appears is the browse list, and it is provided by a browser in the local computer's workgroup or domain.

The Microsoft networking browser system consists of a master browser, backup browsers, and client computers. The master browser maintains the browse list and periodically sends copies to the backup browsers. When a browser client needs information, it obtains the current browse list by sending a NetServerEnum2 application programming interface (API) call to either the master browser or a backup browser.

The NetServerEnum2 API call returns information about SV_TYPE_SERVER entries in a domain or workgroup. It allows client computers to view the set of servers in the workgroup or domain. The API provides a Servertype mask that allows users to query for various types of servers such as workstations, servers, time servers, domain controllers and so on. (A NetServerEnum API call is also supported for compatibility with Microsoft LAN Manager networks.)

Because a computer announces itself on the network based on the type of server services that it is running, a Windows 95 computer appears in a browse list only if it is running File and Printer Sharing services, and if the service is configured to announce itself on the network.

The centralized browser architecture for Windows networking reduces the number of broadcast datagrams on the network. A datagram is a network packet that is sent to a mailslot on a specified computer (a directed datagram) or to a mailslot on any number of computers (a broadcast datagram). The centralized browser architecture also reduces the demands on the client computer's CPU and memory.

Note: For Microsoft networking using the Microsoft TCP/IP protocol, broadcast name resolution is a direct implementation of Request for Comments (RFCs) 1001 and 1002 (NetBIOS Service Protocols). This implementation of NetBIOS over TCP/IP is wholly compliant with the RFCs, and does not involve any method of what has been referred to as "NetBEUI encapsulation."

For more information about NetBIOS over TCP/IP, see the discussion of name resolution for Windows-based networking in Windows NT Networking Guide (volume 2 in Microsoft Windows NT 3.5 Resource Kit).

Browser Components

The Microsoft networking browser system consists of two components:

Browser service, which is the User-mode portion responsible for maintaining the browse list, remotely making API calls, and managing the various roles a browser can have.
Datagram receiver, which is the Kernel-mode portion of the browser, and is simply a datagram and mailslot receiver. It receives directed and broadcast datagrams of interest to the network client and peer sharing services. It provides kernel-level support for the NetServerEnum API, as well as support for remote mailslot reception (second-class datagram-based mailslot messages) and the request announcement services.

All browser datagrams destined for computers running LAN Manager, Windows for Workgroups, Windows 95, Windows NT Workstation, or Windows NT Server computers are sent to the mailslot name \MAILSLOT\LANMAN. Browser datagrams destined only for computers running Windows NT Workstation or Windows NT Server are sent to the mailslot name \MAILSLOT\MSBROWSE.

NetBIOS Special Names

In a LAN environment using any protocol or combination of protocols, all Microsoft networking browsing activities are maintained using broadcasts and special NetBIOS names that identify the type of resource. All browsing services are provided on a per-protocol basis to prevent, for example, a NetBEUI-only client from enumerating a TCP/IP-only server in the process of querying the browser.

The NetBIOS name space is not hierarchical, so all names must be unique on the network. Resources are identified by the NetBIOS names, which are registered dynamically when the computer starts, a service starts, or a user logs on.

The special NetBIOS names used in Microsoft networking are indicated by adding a hexadecimal value as a 16th byte at the end of the 15-character computer name or domain name. If the computer or domain name is less than 15 characters, spaces are used to pad the name to the 16th byte.

The browsing discussion in this paper uses the special NetBIOS names to explain how names are registered and resolved for browsing on Microsoft networks. The following table shows some of these special names.

Samples of NetBIOS Special Names

Special name	Description
Registered unique computer names:
computer\0x00	Used by Microsoft networking workstations to receive second class mailslot requests. All workstations must add this name in order to receive mailslot requests. This is the computer name registered for workstation services by a WINS client.
computer\0x03	Used as the computer name that is registered for the messenger service on a computer that is a WINS client.
computer\0x20	Used as the name that is registered for the peer server service on a Windows 95 computer (or the server service on a Windows NT computer) that is a WINS client.
computer\0xBe	Used as the unique name that is registered when the Network Monitor agent is started on the computer.
computer\0x1f	Used as the unique name that is registered for Network dynamic data exchange (DDE) when the NetDDE service is started on the computer.
Registered group names:
.._MSBROWSE_.	Used by master browser servers to periodically announce their domain on a local subnet. This announcement contains the domain name and the name of the master browser server for the domain. In addition, master browser servers receive these domain announcements to this name and maintain them in their internal browse list along with the announcer's computer name.
domain\0x00	Used by workstations and servers to process server announcements to support Microsoft LAN Manager. Servers running Windows 95, Windows NT, Windows NT Server, and Windows for Workgroups do not broadcast this name unless the LMAnnounce option is enabled in the server's properties.
domain\0x1b	Used to identify the domain master browser name, which is a unique name that only the primary domain controller (PDC) can add. The PDC processes GetBrowserServerList requests on this name. WINS assumes that the computer that registers a domain name with the \0x1b character is the PDC.
domain\0x1c	Used for the internet group name, which the domain controllers register. The internet group name is a dynamic list of up to 25 computers that have registered the name. This is the name used to find a Windows NT computer for pass-through authentication.
domain\0x1d	Used to identify a master browser (not a domain master browser). The master browser adds this name as a unique NetBIOS name when it starts. Workstations announce their presence to this name so that master browsers can build their browse list. For peer servers, this name has the form workgroup\0x1d.
domain\0x1e	Used for all workgroup or domain-wide announcements by browser servers in a Windows network workgroup or Windows NT Server domain. (Notice, however, that workstations use the domain\0x1d form, not \0x1e.) This name is added by all browser servers and potential servers in the workgroup or domain. All browser election packets are sent to this name.
computer\0xBf	Used as the group name that is registered when the Network Monitor agent is started on the computer. If this name is not 15 characters in length, it is padded with plus (+) symbols.
username\0x03	Used to register the name of the currently logged on user in the WINS database, so that users can receive net send commands sent to their user names.

The following example shows a sample NetBIOS name table for a Windows 95 computer running File and Printer Sharing for Microsoft Networks, based on the list that appears if you type nbtstat -n at the command prompt. This example shows the 16th byte for special names, plus the type of NetBIOS name (unique or group).

Node IpAddress: [157.56.60.111] Scope Id: []
            NetBIOS Local Name Table
   Name               Type         Status
---------------------------------------------
ANNIEP_PC      <00>  UNIQUE      Registered
WIN95GRP       <00>  GROUP       Registered
ANNIEP_PC      <03>  UNIQUE      Registered
ANNIEP_PC      <20>  UNIQUE      Registered
WIN95GRP       <1E>  GROUP       Registered
ANNIEP         <03>  UNIQUE      Registered

In this example, several special names are identified for the Windows 95 computer (ANNIEP_PC in the example above), the workgroup (WIN95GRP), and the current user (ANNIEP), including the following:

computer\0x0 (shown as <00> in the example) indicates the computer name associated with Client for Microsoft Networks on this computer.
workgroup\0x0 indicates the workgroup to which this computer belongs.
computer\0x3 indicates the service name for sending messages.
computer\0x20 indicates the server name registered with the WINS server for File and Printer Sharing services on this computer.
workgroup\0x1e indicates that this computer can serve as a backup browser in this workgroup.
username\0x03 indicates the name of the currently logged on user that is registered with WINS for messaging services.

Tip for NetBIOS scope ID Microsoft networking allows administrators to specify NetBIOS scope IDs to define special groups within the network that can communicate only with each other. The NetBIOS scope ID can be used for interoperation with other NetBIOS implementations that use the NetBIOS scope ID. Before any packets that contain a NetBIOS name are transmitted, the NetBIOS scope ID is appended to the name. This includes packets such as name queries, name registrations, and session requests. On the receiving end, the NetBIOS scope in a packet must match the locally configured NetBIOS scope; otherwise, the packet is ignored. Therefore, only computers that have the same scope can communicate with each other.

However, for most cases on most networks, the NetBIOS scope ID is null.

How Servers Manage Browsing for Microsoft Networking

In a Windows NT domain, every Windows NT Server computer is a browser. The primary domain controller (if there is one) is the master browser, and the other computers running Windows NT Server, Windows NT Workstation, or Windows 95 are backup browsers. If there is more than one Windows NT Server computer in the domain, no computer running Windows NT Workstation or Windows 95 will ever be a master browser in the domain.

In a workgroup containing computers running Windows 95 and Windows NT Workstation, there is always one master browser. If there are at least two Windows 95 or Windows NT Workstation computers in the workgroup, there is also one backup browser. For every 32 computers running Windows 95 and Windows NT Workstation in the workgroup, there is another backup browser.

This section describes how computers become browsers and summarizes the roles played by master and backup browsers.

Master Browser Elections

Each computer running Windows 95, Windows for Workgroups, Windows NT Workstation, or Windows NT Server has configuration settings that determine whether that computer can become a browser. For servers running Windows 95, this is determined by the Browse Master value for File and Printer Sharing for Microsoft Networks. For servers running Windows NT, the value for MaintainServerList for the browser service determines its possible role as a browser. By default, servers are configured to have the potential to become browsers.

Unless the server is specifically configured to never be a browser, the Microsoft networking browser service starts automatically when the computer starts, and the server announces itself on the networking using the special NetBIOS name workgroup\0x1e.

Windows 95 Server domain controllers can also be configured to be the domain master browser, which is always the preferred master browser on the domain when there are master browser elections.

A master browser election always occurs in the following circumstances:

When a computer cannot find its master browser at system startup
When a computer determines that a master browser has disappeared
When a computer running Windows NT Server starts (that is, a preferred master browser is started)

When any server needs to force a master browser election, it notifies the other browsers on the system by broadcasting an election datagram that contains the sending browser's election version and election criteria. The election datagram and subsequent traffic takes place over the NetBIOS name of workgroup\0x1e.

The election version is a constant value that identifies the version of the browser election protocol. If the election versions are identical for both computers, the election criteria are compared. The election criteria consists of a 4-byte hexadecimal value. Specific groups of bytes are masked and their values set according to the following list.

Election criterion	Value
Operating system type	0xFF000000
Windows NT Server	0x20000000
Windows NT Workstation	0x10000000
Windows 95	0x01000000
Windows for Workgroups	0x01000000
Election version	0x00FFFF00
Per version criterion	0x000000FF
Primary domain controller	0x00000080
WINS client	0x00000020
Preferred master browser	0x00000008
Running master browser	0x00000004
MaintainServerList or BrowseMaster=yes	0x00000002
Running backup browser	0x00000001

When a browser receives an election datagram, the receiving browser compares the election version in the datagram with its own. If the receiving browser has a higher election version than any other browser, it wins the election regardless of any other election criteria. For example, a computer running any version of Windows NT will always win the election over a computer running Windows 95.

If the election versions are identical, the receiving browser compares the election criteria as follows:

If the receiving browser has a higher election criteria than the sending browser, the receiving browser issues its own election datagram and enters the "election in progress" state.
If the receiving browser does not have a higher election criteria than sending browser, the receiving browser attempts to determine which computer is the new master browser.
If there is still a tie, the browser that has been running longest is the winner. If there is still a tie, the browser that has a lexically lower name is the winner. For example, when all other criteria are equal, a server named A1 wins the master browser election over a server named B1.

When a browser receives an election datagram indicating that it wins the election, the browser enters the running election state. In the running election state, the browser sends an election request after a delay based on the browser's current browser role:

200ms delay for master browsers
400ms delay for backup browsers
800ms delay for all other browsers

The browser broadcasts up to four election datagrams. If, after four election datagrams, no other browser has responded with an election criteria that would win the election, the browser becomes the master browser. If the browser receives an election datagram indicating that another system would win the election, the browser demotes itself to backup browser. To avoid unnecessary network traffic, a browser that has lost an election does not broadcast any unsent election datagrams.

Role of Master Browsers

The master browser maintains the browse list, which is the list of all servers in the master browser's domain or workgroup, plus the list of all domains on the network. For a domain that spans more than one subnetwork, the master browser maintains the browse list for the portion of the domain on its subnetwork. The rest of the domain is known based on domain announcements made by the master domain browser, as described on page 7 in this paper.

Individual servers running Windows NT Server, Windows NT Workstation, Windows 95, Windows for Workgroups, or LAN Manager announce their presence by sending a directed datagram called a server announcement to the domain or workgroup's master browser. This announcement includes the server's NetBIOS name of \0x01\0x02_MSBROWSE_\0x02\0x01, domain\0x1d, or domain\0x1e as appropriate for the type of server. When the master browser receives a server announcement from a computer, it adds that computer to the browse list.

The master browser also returns lists of backup browsers to computers running Windows NT Server, Windows NT Workstation, Windows 95, and Windows for Workgroups. When a computer starts that is configured to automatically become a browser if required, the current master browser must tell that computer whether to become a backup browser.

If its browse list is empty when a computer first becomes a master browser, it can force all servers to register with it by broadcasting a RequestAnnouncement datagram. All computers receiving this datagram must respond by sending a server announcement at a random time within the next 30 seconds. The randomized delay ensures that the network and the master browser itself are not overwhelmed with responses.

When a master browser receives a server announcement from another computer that claims to be the master browser, the receiving master browser demotes itself and forces an election as described in the previous section. This ensures that there is always only one master browser in each domain or workgroup.

The list of servers that the master browser maintains is limited to 64K of data. This limits the number of computers that can be in the browse list for a single workgroup or domain to 2000 – 3000 computers.

Role of Backup Browsers

Backup browsers call the master browser every 15 minutes to get the latest copy of the browse list, as well as a list of domains. Each backup browser caches these lists and returns the list of servers to any clients that send a remote NetServerEnum API call to the backup browser. If the backup browser cannot find the master browser, it forces an election.

By default, File and Printer Sharing for Microsoft Networks is configured to become a master browser if required.

To configure master browser capabilities using the Network option in the Windows 95 Control Panel, select the related option in the File and Printer properties.

Role of Domain Master Browsers

The browser service running on a domain's primary domain controller (PDC) has the special additional role of being the domain master browser. The PDC of a domain has a bias in browser elections to ensure that it becomes the master browser.

On Microsoft networks using the IPX/SPX-compatible network protocol (NWLink), there is always only one master browser for each domain, because name queries are sent across routers automatically.

On networks using TCP/IP where a domain spans more than one subnetwork, each subnetwork functions as an independent browsing entity, with its own master browser and backup browsers. Name-query datagrams do not cross routers. To browse across the wide-area network (WAN) to other subnetworks, at least one browser running Windows NT Server is required on the domain for each subnetwork. On the subnetwork where the PDC is placed, this Windows NT Server computer is usually the PDC, which functions as the domain master browser.

When a domain spans multiple subnetworks, the master browser for each subnetwork announces itself as the master browser to the domain master browser by sending a directed MasterBrowserAnnouncement datagram using the computer's NetBIOS domain\0x1d. The domain master browser then sends a remote NetServerEnum API call to each master browser to collect each subnetwork's list of servers. The domain master browser merges the server list from each subnetwork master browser with its own server list to form the browse list for the domain. This process is repeated every 15 minutes to ensure that the domain master browser has a complete browse list of all the servers in the domain.

The master browser on each subnetwork also sends a remote NetServerEnum API call to the domain master browser to obtain the complete browse list for the domain. This complete browse list is thus available to browser clients on the subnetwork.

Note: Microsoft networking workgroups cannot span multiple subnetworks. Any workgroup that spans subnetworks actually functions as two separate workgroups, with identical names.

Browser Failures with Microsoft Networking

A failed server stops announcing itself. When the master browser does not receive a server announcement for three of the server's current announcement periods, the master browser removes that server from the browse list. It might take up to an additional 15 minutes for the backup browsers to retrieve the updated browse list from the master browser, so it could take as long as 51 minutes from the time a server fails to when it is removed from all browse lists.

Because a backup browser announces itself in the same way as a server, the procedure when a backup browser fails is the same as that for a server. If the name of this backup browser has been given to any clients, attempts made by those clients to contact this backup browser fail. The client then retries the NetServerEnum API call on another backup browser on the client's list of browsers. If all the backup browsers that a client knows have failed, the client attempts to get a new list of backup browsers from the master browser. If the client is unable to contact the master browser, it forces a browser election. The client then returns an error to the application, indicating that the master browser could not be found.

When a master browser fails, the backup browsers detect the failure within 15 minutes. The first backup browser to detect the failure forces an election to select a new master browser. Between the time the master browser fails and a new master browser is elected, the domain could disappear from the list of domains in the browse list. If a client performs its first NetServerEnum API call after the old master browser has failed but before a backup browser detects the failure, the client forces an election. If a master browser fails and there are no backup browsers, browsing in the workgroup or domain will not work correctly.

When a domain master browser fails, other master browsers see only servers on their same local subnetwork. Eventually, all servers that are not on the local subnetwork are removed from the browse list.

How Servers Announce Themselves in Microsoft Networking

When a server is started (including any computer running File and Printer Sharing for Microsoft Networks), it announces itself by sending a server announcement to the master browser every minute. This announcement uses the special NetBIOS name of *workgroup\*0x1d. As the computer continues running, the time between server announcements is increased until it eventually becomes once every 12 minutes.

If the master browser has not received a server announcement from a computer for three announcement periods, the computer is removed from the browse list. Therefore, there might be up to a 36-minute delay between the time a server goes down and the time it is removed from the browse list.

Client computers sometimes need to retrieve lists of domains, as well as lists of servers in those domains. To support this, when a browser becomes a master browser, it broadcasts a DomainAnnouncement datagram every minute for the first five minutes, and then broadcasts once every 15 minutes after that. Master browsers in domains and workgroups announce their presence to the special NetBIOS name of \0x01\0x02_MSBROWSE_\0x02\0x01 and register their names with this group. Master browsers on other domains receive these DomainAnnouncement datagrams and add the specified domain to the browse list.

DomainAnnouncement datagrams contain the name of the domain, the name of the domain master browser, and whether the master browser is running Windows NT Server, Windows NT Workstation, or Windows 95. If the master browser is running Windows NT Server, the datagram also specifies whether that browser is the domain's PDC.

If a domain has not announced itself for three consecutive announcement periods, the domain is removed from the browse list. Therefore, a domain might be down for as long as 45 minutes before it is removed from the browse list.

When a master browser is shut down correctly, it sends a ForceElection broadcast so that a new master browser can be elected. When a backup browser is shut down correctly, it sends an announcement to the master browser that it is shutting down. To do this, it sends a server announcement that does not include the browser service in the list of running services.

How Clients Receive Browser Information

When an application running on a client computer makes a NetServerEnum API call, the client sends the call to a browser. If this is the first time this call has been made by an application on this client, the client must first determine which computers are the browsers in its workgroup or domain by sending a QueryBrowserServers directed datagram. This datagram is in the form of a GetBackupListRequest mailslot request sent to the special NetBIOS domain\0x1d name that the master browser has registered.

This request is processed by the master browser for the client's domain and subnetwork. The master browser then returns a list of browsers active in the workgroup or domain being queried. The client selects the names of three browsers from the list, and then stores these names for future use.

The client computer randomly chooses a browser from one of the three browser names, and sends the NetServerEnum API call, requesting a list of servers or domains. The browser server returns the list to the client, which then can be displayed in Network Neighborhood.

If the user selects a domain name in the browse list, a new set of browser servers must be found for the new domain. In this case, a GetBackupListRequest frame is sent to the new domain name.

After a user selects a server from the browse, the browser is no longer involved in the process of contacting the server for a list of available resources. The transport protocols on the client computer use whatever name resolution methods are available to find and connect to the server.

When the client workstation attempts to connect to a server, a NetBIOS session is established between the two computer names. For example, when a Windows 95 client workstation on an IP network connects to a computer running File and Printer Sharing for Microsoft Networks, the following occurs:

The NetBIOS name for the server is resolved to an IP address.
A TCP connection is established from the client to the server.
The client sends a NetBIOS Session Request to the server name over the TCP connection.
The server responds affirmatively and the session is established.
The client and server negotiate a higher level protocol to use over the NetBIOS session.

Only one NetBIOS session is established between two names at a time. Additional connections for file or printer sharing are multiplexed over the same NetBIOS session.

Microsoft TCP/IP and Name Resolution

All computers are on the same wire in the LAN environment, so a user can browse all workgroups and domains because the network client can communicate directly with all master browsers. Multiple workgroups and domains can coexist on a LAN without incident, because both the unique and group NetBIOS names depend on the name of the workgroup or domain.

Name resolution becomes more complex in the WAN IP environment, however, because the broadcasts and messages used for name resolution are not forwarded across routers automatically on TCP/IP networks.

Tip for browsing on IP networks The single most important key to successful browsing using Microsoft networking, whether or not the network includes WINS, is to segment the network so that all clients and servers involved in browsing are members of domains.

This section summarizes name resolution issues related to WAN browsing, depending on whether Windows NT WINS servers are available in the enterprise.

NetBIOS over TCP/IP

Microsoft TCP/IP uses NetBIOS over TCP/IP as specified in RFC 1001 and 1002, which defines a software interface that supports name resolution for NetBIOS client and server programs in the WAN environment. All Microsoft networking products use NetBIOS over TCP/IP for registering and locating NetBIOS resources on IP networks. The various methods used for name resolution include the following:

NetBIOS name cache
NetBIOS name servers (implemented as WINS for Windows NT networks)
IP subnet broadcasts
Static LMHOSTS files
Static HOSTS files
DNS servers

The order of methods use for NetBIOS name resolution depends on the node type (as defined in RFC 1001/1002) and the particular computer configuration for TCP/IP. These are the node types:

B-node, which uses broadcasts to resolve names
P-node, which uses point-to-point communications with a NetBIOS name server to resolve names
M-node, which uses broadcasts first (b-node), and then name queries (p-node) if broadcasts are not successful
H-node, which uses name queries first (p-node), and then broadcasts (b-node) if the name server is unavailable or if the name is not registered in the WINS database)

If WINS is enabled on a Windows 95 computer, the system uses h-node by default. Without WINS, the system uses b-node by default. To see which node type is configured on a Windows 95 computer, check the value for NodeType in the following Registry key:

Hkey_Local_Machine \System \CurrentControlSet \Services \VxD \MSTCP

Computer name and host name resolution with NetBIOS over TCP/IP. The following diagrams summarize the methods for attempting name resolution with Microsoft TCP/IP.

brow3

Host name resolution for Windows Sockets applications. Some TCP/IP utilities, such as ping, can use host names instead of IP addresses by using the Windows Sockets GetHostByName() API. The following is the sequence used for name resolution in such cases:

Check whether the host name matches the local computer name.
Check whether the host name is found in the HOSTS file in the Windows folder.
If the computer is configured to use DNS, check whether the host name can be resolved using DNS. If no DNS server responds, then check the LMHOSTS file in the Windows folder.
If the computer is configured to use WINS, check whether the host name can be resolved using WINS.

If this method is used, the host name is converted to a NetBIOS name by padding the name with spaces up to 16 bytes and making the 16th byte a zero to refer to the other computer's redirector.

If the computer is configured to use WINS, a second DNS search occurs if WINS fails, because the application accesses WINS by way of NetBIOS over TCP/IP, which automatically uses DNS if WINS fails.
Use name-resolution broadcasts.

WAN Browsing without WINS on an IP Network

In a WAN environment that requires TCP/IP name resolution, Microsoft networking relies on NetBIOS over TCP/IP (RFC 1001/1002) packets. Although some environments forward these broadcasts across routers, most do not. As a result, WAN browsing over TCP/IP is different from LAN browsing.

Tip for browsing without WINS After ensuring that all computers are members of a domain, the single most important key to successful browsing without WINS is to ensure that each subnet has a master browser or primary domain controller (PDC) present. This is because only the local master browser on each subnet receives local subnet membership announcements. The local browse master can be a Windows 95 computer on any subnet that does not include the domain's PDC.

In a domain, the election of a master browser happens on each subnet, following the same basic election scheme as in the LAN environment, and the PDC always acts as the domain master browser. For TCP/IP WAN browsing to occur, the local master browser must be made aware of the membership list for the entire domain, and this WAN-wide membership list needs to be consolidated into each local master browser's membership list. The domain master browser is responsible for the consolidation and replication of the WAN wide membership list to each master browser. Periodically, all of the locally elected browsers contact the domain master browser to replicate their membership lists. The domain master browser merges theses lists with the "master" list for the entire domain and replicates the master membership list back down to the local master browsers.

The replication algorithm replicates to the master browsers only those members that the master browser did not learn about locally. This allows members in a domain to span subnets and for all clients to receive complete membership lists.

Because IP subnetworks are not bridged automatically, all browser elections and announcements happen as described earlier for LAN environments. The following summarizes the limitations for name resolution in the WAN environment without WINS:

Workgroups cannot span subnets, because they have no equivalent to the domain master browser. Any workgroup name that includes computers on two subnetworks will function as two separate workgroups.
The process of building workgroup and domain lists depends on servers periodically announcing their presence so that browse masters and domain browse masters can build lists and then, in turn, periodically announce the domain on the network.
The user's ability to expand a workgroup or domain while browsing depends on the computer's ability to resolve the computer name of the master browser for that workgroup or domain.
The user's ability to connect to a resource in a workgroup depends on the computer's ability to resolve the resource's name.

However, it is possible to connect to a resource you cannot browse (for example, connecting to a share name that ends with the $ character), and to browse a resource you cannot connect to (for example, enumerating a share for which you do not have proper access rights).

To guarantee that the master browser for each subnet can access the PDC for the domain, the domain's PDC must be listed in each browser's LMHOSTS file. To guarantee that the PDC can request the local subnet's list from the master browser on that subnet, the client addresses must be cached for some period of time. However, computers will not appear in the browse list if they are members of the domain but are on a subnet that does not have a master browser and does not include the domain's PDC.

The following defines the conditions to be created for ensuring that browsing works in WAN environments that do not include WINS.

If each subnet in the domain includes a Windows NT Server computer. No specific configuration steps need to be taken within a domain, because the domain master browser and backup browsers automatically maintain the domain browse lists. The browsers' LMHOSTS files need to include address mappings for PDCs in other domains.

If some subnets in the domain do not include a Windows NT Server computer. For each subnet that does not include a Windows NT Server computer, the following must be true:

The remote subnet must include at least one computer configured to be the master browser. This can be a Windows 95 computer running File and Printer Sharing for Microsoft Networks with Browse Master enabled, or a computer running Windows NT Workstation configured with Maintain Server List enabled.
The LMHOSTS files for browse masters on other subnets must include entries mapping the computer name and IP address for the remote browse masters that are Windows 95 or Windows NT Workstation computers.

If a subnet includes only Windows 95 but no members of domains that span subnets. Users in such an isolated subnet cannot browse computers in a workgroup or domain on any other subnet, and users on other subnets cannot browse the computers on the isolated subnet. For users on these subnets to browse each other's computer, one computer on the isolated subnet must be a member of a domain on the other subnet and also must be configured as a master browser with appropriate LMHOSTS entries as described in the previous case.

To understand what the user sees when browsing subnets without WINS available, consider this example where all members of workgroup A are located on subnet 1, and all members of workgroup B are located on subnet 2. The subnets are connected using a router. Master browsers are elected for each subnet, but workgroup announcements to the special name of \0x01\0x02__MSBROWSE__\0x02\0x01 do not pass across the router. Therefore, clients on subnet 1 see only workgroup A in their browse list, and cannot see workgroup B and its membership list.

Workgroups on different IP subnets without WINS or domains

In the UNIX environment, the HOSTS file ensures access to other hosts across routers. In LAN Manager 2.1, Microsoft adopted a similar convention with the LMHOSTS file, which maps computer names to IP addresses. However, merely adding an entry for a server to the LMHOSTS file does not ensure a server is displayed in the membership list, because connecting to a network resource does not require knowledge of the workgroup or domain, but is required for the compilation of a membership list. So, domain or workgroup browsing and name resolution are unrelated activities in this scheme.

Using LMHOSTS in the previous example, workgroups A and B cannot see each other, but a domain that spans both subnets can see both workgroups from either subnet, because domains can span routers in a WAN environment.

In the previous example with workgroup A and workgroup B on separate subnets, when you introduce a domain named Domain_C on both subnets, a master browser is elected locally on both subnets for Domain_C. The PDC (named PDC_domC in the following illustration) included on one subnet is the domain master browser, which is also a master browser; the other subnet will have a master browser for Domain_C. These two local browsers learn about workgroups A and B through local broadcasts, and exchange lists using the domain master browser. Therefore, any client of Domain_C will see all servers on subnet 1/workgroup A and subnet 2/workgroup B. As long as both the client and server computer names can be resolved using local broadcasts or LMHOSTS, the clients can connect to the listed servers.

Browsing without WINS using domains

In this configuration, the browse master on subnet 1 can be a Windows 95 computer if no Windows NT computers are present

brow5

In this example, in subnet 1, the browser master's LMHOSTS file must contain an entry similar to the following, specifying the IP address of the PDC:

102.54.94.97  PDC_domc #PRE #DOM:Domain_C

The special flag #PRE ensures that this mapping is loaded in the computer's name cache whenever the system is started. The #DOM flag specifies a domain controller.

Master browsers must be domain controllers for TCP/IP WAN-wide domain browsing, because for replication of the membership list to occur, the master browsers must be able to find and connect to the domain master browser (which is the PDC). To do this, several things must happen. First, the local master browsers need to learn the name of the PDC using the GetDCName() API, which relies on the LMHOSTS file to distribute datagrams to all domain controllers in the domain. One of the domain controllers makes the call, and the name of the PDC is learned.

After the local master browser has the name of the PDC, the LMHOSTS file is used to resolve the name of the PDC into an address so that a connection can be made. The computer name-to-IP address mapping for the PDC must also be located in the LMHOSTS files on all local master browsers and potential master browsers. With this done, all clients of the domain on all subnets can connect to the local master browser (or backup browser) and receive a list of all of the members of the domain, regardless of location on the WAN.

When more domains and workgroups are added to the WAN environment, local master browsers learn of them as domains and workgroups announce themselves by using the name \0x01\0x02__MSBROWSE__\0x02\0x01 broadcast only to the local subnet. Each master browser builds a table of domains and workgroups with a membership list for each, and then replicates the same table up to the domain master browser.

Therefore, WAN browsing for each client in the original domain is possible if these additional workgroups and domains are not isolated on a subnet. The original domain's membership list includes the domain and workgroup name and the master browser name, so the clients of this domain can expand any of the visible domains or workgroups into a membership list if the master browser for the particular domain or workgroup is defined in the LMHOSTS file.

In the final example for a non-WINS environment, Domain_C spans 3 subnets, and the PDC for Domain_C is on subnet 1, subnet 2 includes a backup domain controller for Domain_C, and subnet 3 includes a Windows 95 computer that is a member of Domain_C and is configured to be a browse master. Subnet 3 also includes computers that belong to a domain named Domain_D, and the PDC for that domain is on yet another subnet.

When the browse master for subnet 3 (a Windows 95 computer) sends the list of servers on its local subnet to the PDC for Domain_C, it also sends a list of domains in its subnet, including Domain_D. So the PDC for Domain_C has a list of domains that includes Domain_D listed in it. When the browse master for subnet 2 gets the browse list from the PDC, the list includes Domain_D on the list of known domains. When a client on subnet 2 requests the list of servers in Domain_D, it sends the request to the subnet 2 browse master, which in turn can contact the browse master for Domain_D on subnet 3 — but only if the IP address for the browse master on subnet 3 is stored in the LMHOSTS file on the browse master for subnet 2.

In this example, the following LMHOSTS entries will ensure that computers in each subnet and domain can see each other:

102.54.94.98 pdc_domC  #PRE #DOM:Domain_C #preload PDC for Domain_C
102.54.86.24 pdc_domD  #PRE #DOM:Domain_D #preload PDC for Domain_D
102.54.94.96 bm_s2domC #PRE            #subnet 2 browse master
102.54.94.94 bm_s3domC #PRE            #subnet 3 browse master, Domain_C
102.54.94.90 bm_s3domD #PRE            #subnet 3 browse master, Domain_D

For more information about	See
LMHOSTS syntax and special keywords for specifying domains, including other LMHOSTS entries	Appendix G, "HOSTS and LMHOSTS Files for Windows 95," in Microsoft Windows 95 Resource Kit, p. 1227, U.S. ed.

WAN Browsing with WINS on an IP Network

WINS solves two problems for browsing in the WAN: the building of a comprehensive domain list, and name resolution for members within a domain or workgroup. The following summarizes issues for browsing in a WAN environment with WINS:

Workgroups still cannot span subnetworks, because they have no equivalent to the domain master browser.
The process of building domain lists uses the WINS database and domain\0x1b names. Workgroup lists are still based on members announcing their presence periodically. For example, an isolated workgroup on an island subnet with no domain members will be invisible to the WAN until a domain member added that shares the presence of the subnet.
The ability to expand a workgroup or domain depends on the ability to resolve the master browser's computer name. If WINS-enabled computers are running in workgroups and domains, this is adequate.
The ability to connect to a resource in a workgroup depends on the ability to resolve the resource's name. Again, WINS-enabled computers support this adequately. Also, it is possible to connect to a resource you cannot browse and to browse a resource you cannot connect to.

Tip for browsing with WINS Because of how PDCs register with WINS, the key to successful browsing is to ensure that all clients and servers are members of a domain. In addition, a few Windows 95 computers or other Window networking computers can be configured as WINS proxies to assist name resolution for non-WINS computers on the network.

The unique NetBIOS name of domain\0x1b that PDCs register is treated specially by WINS and is used to build a table of all domains on a WAN network. The browser on the client periodically connects to WINS and learns of all the systems that registered the domain\0x1b name. The browser then uses a GetDCName() call on each of the domain\0x1b names, followed by an attempt on the domain\0x1c names. The browser then adds the domain master browser's name to its domain and workgroup list. This eliminates the need to strategically place workgroup or domain members on subnets to ensure that comprehensive domain and workgroup lists are built.

With WINS, the domain\0x1e name registration is ignored and basically treated as a normal group name. This forces browser elections to remain on subnetworks rather than extending elections to the WAN. This increases fault tolerance and reduces periodic network-wide traffic. The same is true for the domain\0x1d and \0x01\0x02__MSBROWSE__\0x02\0x01 group names. This also reduces the scope of the announcement broadcasts on the subnetwork. The unique domain\0x1b name and the internet group domain\0x1c name are maintained by WINS and are used during logon and for GetDCName() calls.

Internetwork with WINS servers and WINS proxies

Notice that for networks that use WINS, a Windows 95 computer running Microsoft TCP/IP can be configured to act as a WINS proxy by specifying EnableProxy=1 in the following Registry key:

Hkey_Local_Machine \System \CurrentControlSet \Services \VxD \MSTCP

A WINS proxy is a WINS-enabled computer that passes name query packets from non-WINS computers and verifies that name registrations do not duplicate existing entries in the WINS database. Proxies do not actually register b-node systems in the WINS database. It is recommended that only two computers be configured as WINS proxies in each subnet to help ensure that non-WINS computers can resolve names by using broadcasts.

IPX/SPX-Compatible Protocol and Name Resolution

The specifications for IPX/SPX are defined by Novell, and the implementation provided with Windows 95 is compatible with these specifications.

The NDIS 3.1 implementation in Windows 95 handles all source routing. Name queries are sent across routers automatically, so for Microsoft networking there is always only one master browser running the IPX/SPX-compatible protocol for each workgroup. For networking on NetWare networks, there are additional issues, as described later in this section.

With IPX/SPX, the 6-byte node address that is used by the protocol is the same as the network adapter's MAC address, so client workstations do not have to be specially configured for this protocol. However, this also does not allow for hierarchical network addresses for forwarding messages.

IPX/SPX for Windows 95 with Microsoft Networking

For Microsoft networking, the IPX/SPX-compatible protocol provided with Windows 95 can be used to provide the transport protocol, but name resolution uses named pipes and type 20 broadcasts. A WAN using IPX/SPX is seen as a single LAN from the perspective of the browser, because all type 20 broadcasts are forwarded by the routers. With IPX/SPX, all browser elections and announcements occur across the entire WAN in the manner described earlier in the paper, except that timing is slightly different than for a LAN or TCP/IP networks.

IPX/SPX for Windows 95 on NetWare Networks

For NetWare networks, the IPX/SPX-compatible protocol is the required transport protocol for Windows 95 32-bit clients and peer servers. Novell-supplied servers on a NetWare network always use the service advertising protocol (SAP) to announce and register their presence on the network. Windows 95 peer servers can optionally use this method, although it is not recommended in most cases.

The browsing issues for Windows 95 peer servers on NetWare networks depend on the method the peer server uses to advertise its presence. For Windows 95 peer servers on NetWare networks, Workgroup Advertising is the default and recommended method for browser announcements and name resolution.

This section describes the processes, issues, and recommendations for peer server advertising on NetWare networks.

Note: You must enable either SAP Advertising or Workgroup Advertising for each Windows 95 peer server on a NetWare network. If you attempt to disable both of these advertising protocols, Workgroup Advertising will be enabled by default.

How SAP Advertising Works

by sending a SAP packet to the broadcast address. All other servers and routers listen for these packets and accumulate them in their internal SAP tables, which contain a list of servers on the NetWare network that can participate in SAP browsing.

The SAP broadcasts are restricted to the segment (that is, subnet) on which they are broadcast. To allow the entire network to be aware of all available services, the routers repeat SAP broadcasts seen on one subnet among the other subnets they are connected to. If a Windows 95 peer server is configured to use SAP as the transport name resolution protocol, it appears in the browse list of servers that any NetWare clients can see and connect to.

This scheme ensures that every server that uses SAP advertising causes SAP packets to be broadcast across the entire IPX network. Also, each entry must be remembered by every router and every server on the network. This system works well for a small number of servers (less than 1000), but as the number of servers grows, the bandwidth requirements and resource requirements for servers and routers get very large.

Many problems arise with running more than 1000 NCP servers on a network, some of which are related to problems with the SAP advertising method used by NetWare versions 2.x, 3.x, and 4.x. Future versions of NetWare will replace this mechanism with NLSP, a new protocol that does not suffer from many of the problems associated with SAP.

To avoid SAP advertising problems, by de fault File and Printer Sharing for NetWare uses its own name resolution and service advertising mechanism, as described in "How Workgroup Advertising Works" later in this section. However, File and Printer Sharing for NetWare can be configured to use SAP advertising in order to allow VLM and NETX clients to access the peer server. The issues related to this particular configuration are described in "How SAP Advertising Works for Peer Servers" later in this section.

How Workgroup Advertising Works

On a large network that contains more than 15,000 peer servers (that is, computers running File and Printer Sharing for NetWare Networks), it would not be practical to use SAP Advertising to announce server services. Instead, Microsoft uses a method called Workgroup Advertising to implement browsing for large NetWare networks that include Windows 95 computers.

With Workgroup Advertising, each Windows 95 computer is assigned to a workgroup, which is a collection of casually related computers. Workgroups can be arranged geographically or functionally or however the network administrator prefers. The only important issue is that the computers are grouped in workgroups.

By default, when a Windows 95 peer server running File and Printer Sharing for NetWare starts up, it registers its name and workgroup using this private method, which uses the computer's workgroup name to attempt to find the browse master for the workgroup by searching the default NetWare server's bindery. If no workgroup master is found in the bindery, the peer server elects itself master and advertises itself using SAP. Any Windows 95 peer server that subsequently starts in that workgroup will find this server registered as the browse master. When another peer server finds the browse master, it sends the master a packet describing itself, so that the master can accumulate the list of servers available in the workgroup. This is the list that appears when computers running Microsoft Client for NetWare Networks browse the network. If the master browser is not available, the recovery mechanism is similar to the method described earlier in this paper for Microsoft networking.

With Workgroup Advertising enabled on Windows 95 peer servers, there should be no issues for interacting with Novell-based VLM or NETX clients when Windows 95 computers run peer services on a large network. The browse masters send SAP broadcasts using SAP type 0x067B, and browser backups use 0x067C — neither uses SAP type 0004. Notice, however, that type 20 packets must be propagated through routers in order to allow users who are not in the same workgroup to attach to peer servers across a router.

The Workgroup Advertising scheme reduces the SAP overhead from one SAP entry per server to one SAP entry per workgroup, or two entries for large workgroups because a backup master is also elected. For this scheme to be effective, workgroup names must be meaningful and coordinated. If every peer server has its own workgroup, the SAP overhead is just as bad as if every peer server were using SAP advertising.

When a Windows 95 client asks to attach to a server on a NetWare network—for example, the server named eSERV_311—the Windows 95 private protocol first scans the bindery of the default NetWare server to determine whether it is searching for a server that uses SAP type 0004 (the server SAP type). Such servers appear at the top level of the browse list when browsing the entire network.

If the default server is not using SAP type 0004, then a request is sent to the workgroup's browse master to determine whether the master can resolve the name to an IPX address. If this fails, a broadcast is sent to all workgroup masters using a Type 20 IPX packet to resolve the name. If this query fails, it is assumed that the requested server does not exist.

When Workgroup Advertising is used , a master browser must be available at all times in each workgroup to support browsing. Similar to the browser capabilities on Microsoft networks, Workgroup Advertising can be configured to specify the browser capabilities for a Windows 95 peer server on a NetWare network. The configuration options are the following:

Disabled — this peer server will not be added to the browse list and cannot act as browse master.
May Be Master — this peer server will be added to the browse list and can be promoted to master browser if required.
Preferred Master — this peer server is the master browser for the workgroup.
Will Not Be Master — this peer server will be added to the browse list but cannot be promoted to master browser.

To configure browse master capabilities in the Network option in Control Panel, select an option in the properties for File and Printer Sharing for NetWare Networks.

For information about using system policies to ensure that Windows 95 computers on NetWare Networks use Workgroup Advertising, see Chapter 15, "User Profiles and System Policies," in Microsoft Windows 95 Resource Kit.

For information about how to use WRKGRP.INI files to control the workgroups defined for Windows 95 computers, see Chapter 5, "Custom, Automated, and Push Installations," in Microsoft Windows 95 Resource Kit.

How SAP Advertising Works for Peer Servers

The SAP advertising option is disabled by default for File and Printer Sharing on NetWare Networks. However, other computers running NETX or VLM on a NetWare network can see shared resources on a Windows 95 peer server only if that computer uses SAP advertising. You can enable SAP advertising for a peer server so that this computer advertises itself using SAP type 0004 broadcasts. This causes the peer server to appear in NetWare SLIST listings, and allows VLM and NETX clients to map drives and print to the peer server.

In general, you will want to enable SAP advertising only on computers with resources such as CD-ROM drives that you want to share with NETX and VLM clients. SAP Advertising is not required for sharing resources among computers running Microsoft Client for NetWare Networks, nor is not required for remote administration of Windows 95 computers when using Net Watcher, Registry Editor, or System Policy Editor.

In addition to the SAP issues discussed earlier in this section, there is also an issue related to system startup for Novell-supplied clients when a Windows 95 peer server uses SAP advertising.

When a NetWare-based VLM or NETX client starts, it sends a GetNearestServer request. Routers and servers will respond to this request by sending directed SAP packets to the client that is starting. The first response received is accepted by the client, and the client connects to this server, which becomes the default server. If a preferred server is specified in the client's configuration, the client reads the address of the preferred server in the bindery of the default server, and then attempts to attach to that server in order to use it as the starting point for running LOGIN.EXE. Any server that advertises as SAP type 0004 can become the default server. Windows 95 peer servers that use SAP advertising will respond to a GetNearestServer broadcast.

This situation would cause a NETX or VLM client to attempt to log in to the peer server, except that Windows 95 makes sure these NETX and VLM clients connect to a real NetWare server. To prevent logon problem, Windows 95 use a stub file named LOGIN.EXE in the Windows NWSYSVOL\LOGIN directory on the peer server. This directory is created automatically when File and Printer Sharing for NetWare Networks is installed, and it is automatically shared with read-only privileges whenever SAP advertising is enabled on the peer server, so any user can have read access regardless of whether the user is logged in.

When a NETX or VLM client attaches to a Windows 95 peer server to attempt to log in, the peer server uses its LOGIN.EXE stub to perform the following actions:

First, the peer server makes an implicit connection to the NETX or VLM client and maps the first drive letter on that client to SYS:\LOGIN.

Then the peer server attaches to a real NetWare server and sets this server as the real primary and preferred server for the NETX or VLM client. The NetWare server used is one of the following (in order of preference):
- The Preferred Server specified for the network client
- The server specified in AUTOEXEC.BAT (or in a batch file called from AUTOEXEC.BAT) for this Windows 95 computer
- The pass-through server specified for validating connections for File and Printer Sharing on this Windows 95 computer
Finally, the LOGIN.EXE stub performs a global logout, remaps, and starts the login process with the real NetWare server. To finish the connection for the NETX or VLM client, there is a chain execution of the real LOGIN.EXE from the real NetWare server, using identical parameters.

The real-mode client does not detect any of these events — it just receives the login connection it wanted with a NetWare server, even though a Windows 95 peer server first intercepted its GetNearestServer broadcast.

The stub LOGIN program on a Windows 95 peer server will run only if the default server is a computer running File and Printer Sharing for NetWare. A user who is already logged into a NetWare server cannot run the LOGIN program on a peer server. Any attempt to do so will fail.

To ensure administrative control during client login, you should make sure of the following:

Never specify a computer running File and Printer Sharing for NetWare Networks as a preferred server for a NetWare client of any type.
Always specify a preferred server in the configuration for each VLM or NETX client.
Always specify a preferred server in the configuration for each client running Microsoft Client for NetWare Networks.

If you turn on SAP advertising on a Windows 95 peer server, you should make sure of the following:

Make sure every Windows 95 peer server has a unique name on the network.
Make sure that the Windows 95 peer server uses a reliable server for pass-through security validation. Otherwise, if a client with no preferred server starts up when the pass-through server is not available for a peer server that uses SAP advertising, then the client might connect to the peer server, and consequently the LOGIN command that does not specify a server will fail.

In this case, if the client specifies the login server, the user should be able to log in to the server. A non-specific login will continue to fail until the pass-through server is available. In this case, the user will wind up logged into the pass-through server. For example, the following might continue to fail:

M:\SYS>LOGIN

The following example will always work if a Windows 95 peer server ended up being the default server:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

M:\SYS>LOGIN SERV_311

If the client has a preferred server specified, it will never have a Windows 95 peer server as its default server.

Make sure that SAP broadcasts are being propagated onto the network segments that include Windows 95 peer servers. Some network configurations separate clients and servers on different subnets, and then configure the routers not to pass SAP information onto the client-only subnet.

If you use this configuration, any NetWare server advertising type 0004 (including true NetWare servers) will become a black hole on the network. It will be closer than any server on the server subnet and thus the router will respond on the servers' behalf to GetNearestServer requests from clients that are starting on the client-only subnet. After the client connects to the server on the client-only subnet, it cannot connect to any server on the server subnet, because the server it is attached to will not have the names and addresses of servers on the server net. However, this should be an extremely rare configuration and should not be a problem.

Tip for University Networks and Other Large NetWaRe Networks

On any large campus network, Microsoft strongly recommends that you use system profiles. With a policy file installed on every NetWare logon servers, you can automatically enforce a policy that either disables SAP advertising for all Windows 95 computers running File and Printer Sharing for NetWare, or that disables the File and Printer Sharing service completely.

SAP advertising is disabled by default on Windows 95 and should not be enabled on larger networks.

For information about specific system policies for controlling configuration of Windows 95 computers on NetWare Networks — including preventing SAP advertising form being enable on peer servers, see Chapter 15, "User Profiles and System Policies," in Microsoft Windows 95 Resource Kit.

NetBIOS over IPX in Windows 95

Type 20 packets and NetBIOS over IPX. Type 20 IPX packets used for name resolution on IPX networks are NetBIOS packets. When using NetBIOS over IPX, the IPX packet type is set to 14h (decimal 20). Manufacturers of routers may consider all NetBIOS traffic as nonroutable LAN traffic even though it is carried over the routable IPX protocol. So, by default, some routers will not pass type 20 IPX packets. To support NetBIOS over IPX connectivity on the network and name resolution across routers for Microsoft networking, type 20 packet passing must be enabled on the router.

Tuning for NetBIOS over IPX. All tuning for NetBIOS over IPX is automatic under Windows 95. The following tuning parameters — which could be set in the [Nwnblink] section in SYSTEM.INI for NetBIOS over IPX under Windows for Workgroups — are not valid for the protected-mode protocol in Windows 95:

broadcastcount broadcastdelay internet lanabase1	lookahead msextensions namessessions	piggyback receivebuffers retrycount	retrydelay sendbuffers verifytimeout
1 To set LAN adapter numbers when NetBIOS over IPX is required by an application, set the default protocol as the IPX/SPX-compatible protocol with NetBIOS support enabled. For information, see Chapter 12, "Network Technical Discussion," in Microsoft Windows 95 Resource Kit (p. 426, U.S. edition).

NetBEUI and Messaging

NetBEUI is a non-routable protocol, so its configuration for name resolution is not an issue in the WAN environment. NetBEUI relies on broadcasts for name resolution and location of services.

The NetBEUI protocol provides for both connectionless or connection-oriented traffic. Connectionless communications can be either unreliable or reliable. NetBEUI provides only unreliable connectionless, not reliable connectionless communications:

Unreliable communication is similar to sending a letter in the mail. No response is generated by the receiver of the letter to ensure the sender that the letter made it to its destination. In comparison, reliable connectionless communications is like a registered letter whose sender is notified that the letter arrived.
Connection-oriented communications provide reliable communications between two computers in a way that is analogous to a phone call, where two callers connect, a conversation occurs, and then the connection is dropped when the conversation ends. A reliable connection requires more overhead than connectionless communications do.

NetBEUI communicates using the NDIS interface at the Logical Link Control (LLC) sublayer. A connection at the LLC sublayer is called a link, which is uniquely defined by the adapter's address and the destination service access point (DSAP). A service access point can be thought of as the address of a port to a layer as defined by the OSI model. Because NetBEUI is a NetBIOS implementation, it uses the NetBIOS service access point (0xF0). Although the 802.2 protocol governs the overall flow of data, the primitives are responsible for passing the data from one layer to the next. The primitives are passed through the service access points between layers.

NetBEUI and connectionless traffic. Three types of NetBIOS commands — sent as Unnumbered Information (UI) frames at the LLC layer — generate connectionless traffic:

Name claim and resolution
Datagrams
Miscellaneous commands

Windows 95 registers computer names over NetBEUI by using the NetBIOS Add.Name command. When NetBEUI receives the Add.Name command, it broadcasts ADD_NAME_QUERY frames a sufficient number of times to allow computers on the network enough time to inform the sending computer whether the name is already registered as a unique name on another computer or as a group name on the network.

NetBEUI and connection-oriented traffic. The net use command is an example of connection-oriented communication. When a user types net use at the command prompt to connect to a shared resource, NetBEUI must first locate the server by sending UI-frames, and then initialize the link. This is handled by the network client when it makes a connection to the NetBEUI drivers. NetBEUI begins the sequence by generating a NetBIOS Find Name frame. Once the server is found, a session is set up with UC Class-II frames, following the standard 802.2 protocol that governs the overall flow of data.

The client computer sends a Set Asynchronous Balance Mode Extended frame, and the server returns an Unnumbered Acknowledgment frame. Then the client sends a Receive Ready frame, notifying the server that it is ready to receive UI-frames whose sequence number is currently 0. The server acknowledges this frame.

After the LLC-level session is established, additional NetBEUI-level information is exchanged. The client sends a Session Initialize frame, and then the server responds with a Session Confirm frame. At this point, the NetBEUI-level session is ready to handle application-level frames which are in the form of server message blocks (SMBs).

Reliable transfer is achieved with link-oriented frames by numbering the UI-frames. This allows the receiving computer to determine whether the frames were lost and in what order they were received.

NetBEUI and sessions. Each process within Windows 95 that uses NetBIOS can communicate with up to 254 different computers. The 254-session limit is based on a key variable in the NetBIOS architecture called the Local Session Number (LSN). This is a one-byte number (0 to 255) with several numbers reserved for system use. When two computers establish a session over NetBEUI, there is an exchange of LSNs.

The LSNs on the two computers might be different. They do not have to match, but a computer always uses the same LSN for a given session. This number is assigned when a program issues a CALL NCB (Network Control Block). The number is actually shared between the two computers in the initial frame sent from the calling computer to the listening computer. The following illustration shows this session-creation frame exchange.

Broadcast of NameQuery using NetBEUI

The initial frame is a NameQuery frame that contains the LSN number related to either the LISTEN NCB or CALL NCB. For a CALL, the NameQuery frame is addressed directly to the recipient. For a LISTEN, the frame was broadcast onto the network. All computers read the frame and check to see if they have the name in their name space and if there is a LISTEN NCB pending on the name. If there is a LISTEN NCB pending, the computer assigns a new LSN for itself, and then adds it to the response frame and satisfies the LISTEN NCB, which now contains just the LSN used on that computer.

As the frames are exchanged, each partner picks up the address of the other in the source address component of the frame received. The NetBEUI protocol keeps the network address of the remote partner so that subsequent frames can be addressed directly.

Windows 95 has to use the same NameQuery frame to establish connections with remote computers using NetBEUI; otherwise, it would not be able to talk to existing workstations and servers. The NameQuery frame transmitted must contain the LSN to be used.

For more technical details about the implementation of NetBEUI in Microsoft networking, see Windows NT Networking Guide (volume 2 in Microsoft Windows NT 3.5 Resource Kit).

NetBEUI tuning parameters. Protected-mode NetBEUI is entirely self-tuning in Windows 95. Settings for Maximum Sessions and NCBS (network control blocks) can be defined only for the real-mode protocol in the NetBEUI properties.

The following tuning parameters were provided in the [NetBEUI] section of PROTOCOL.INI for LAN Manager networks. These parameters are no longer configuration options for Windows 95:

adaptrate
bindings
datagrampackets
dlcretries
lanabase
looppackets

maxin
maxout
maxtransmits
mintransmits
namecache
names

netbiosretries
netbiostimeout
packets
piggybacks
pipeline
sessions

t1
t2
usecsa
wanretries
windowerrors

More Tips for Troubleshooting Browsing

This section provides some troubleshooting tips.

If a user cannot find a particular workgroup, these are activities the network administrator can do to try to resolve the problem on Microsoft networks:

Make sure the workgroup name is spelled correctly.
If the workgroup is on a remote subnet, make sure the workgroup is in a domain.
Wait 15 minutes and try again, so that browse lists can be updated.
Make sure that the workgroup includes at least one Windows networking computer that is configured to be a master browser.
If WINS is not used on the WAN, make sure that the LMHOSTS files for the master browsers include mappings for the names and IP addresses of master browsers on the other subnets.
If WINS is used on the WAN, make sure that the TCP/IP properties include correct settings for the WINS server.

The following provides a step-by-step method for solving browsing problems on a workstation on any type of network.

Step 1: Verify the problem. Verify that you are having a browsing problem, not a problem with network connectivity. To do so, follow these steps:

Click the Start button, point to Find, and then click Computer.
In the Named box, type the computer name for the network server you want to browse.
Click Find Now.

If the server is found, its name appears in the Name column and its workgroup or Windows NT domain appears in the Location column. If the computer is not found, verify that it is turned on and correctly connected to the network.

If the server is found and its location is a different workgroup than your computer's, the server will not appear in Network Neighborhood.

To determine your computer's workgroup, follow these steps:

Right-click Network Neighborhood, then click Properties on the context menu.
Click the Identification tab.
Note the name of the workgroup displayed in the Workgroup box.

Step 2: Verify that the correct network client is loaded. Verify that the Microsoft Client for Microsoft Networks is installed on your computer. To do so, follow these steps:

Right-click Network Neighborhood, then click Properties on the context menu.
On the Configuration tab, examine the list of installed network components and verify that Client for Microsoft Networks is installed

If this client is not installed, you can install it using the Network option in Control Panel. Then shut down and restart the computer.

Alternately, on a NetWare network, ensure that Microsoft Client for NetWare Networks is installed.

Step 3: Verify that File and Printer Sharing is installed. Verify that the peer resource sharing component is installed. To do so, follow these steps:

Right-click Network Neighborhood, then click Properties on the context menu.
On the Configuration tab, examine the list of installed network components and verify that File And Printer Sharing For Microsoft Networks is installed.

Alternately, on a NetWare network, ensure that File And Printer Sharing For NetWare Networks is installed.

If this service is not installed, you can install it using the Network option in Control Panel. Then shut down and restart the computer.

After you install the peer resource sharing service, allow up to 15 minutes for the server to appear in the browse list. To refresh the current browse list, click Refresh on the View menu.

Step 4: Verify that a common NetBIOS protocol is installed. If the server still does not appear in the browse list, verify that a common NetBIOS protocol is installed on your computer and the server. The NetBEUI, Microsoft TCP/IP, and IPX/SPX-compatible protocols are NetBIOS compliant.

Step 5: Check the master browse server. Verify that the master browse server is functioning correctly by typing the following command at an MS-DOS Prompt:

net view /workgroup: wkgrp_name

where wkgrp_name is the name of your workgroup. If your workgroup name contains spaces, enclose the workgroup name in quotation marks. For example, if your workgroup name is My Workgroup, type the following line:

net view /workgroup:"My Workgroup"

This command retrieves a browse list from the master browse server. If you can retrieve a browse list from the master browse server, one of the following problems may exist on the network:

A backup browse server is not functioning correctly.
A backup browse server does not have an updated browse list. Retrieving an updated browse list can take up to 15 minutes.

Note: If a computer is removed from the network before the computer is logged off the network, it may take up to 45 minutes for that computer to be removed from the browse list.

Step 6: Verify that the browse server is available. If your network includes computers that are frequently powered off or removed from the network (such as mobile computers), it is a good idea to disable master and backup browse server duties on these computers. To disable browse server duties on a Windows 95-based computer, follow these steps:

Right-click Network Neighborhood, and then click Properties on the context menu.
On the Configuration tab, double-click the File And Printer Sharing component.
In the Property box for File and Printer Sharing for Microsoft Networks, click Browse Master, and then click Disabled in the Value box.

Alternatively, for File and Printer Sharing for NetWare Networks, click the Advanced properties tab, click Workgroup Advertising, and then click Disabled in the Value box.
Click OK, and then shut down and restart the computer.

Note: At least one computer in each workgroup must have the ability to become the master browse server. If browse server capability is disabled on all the computers in a network, browse functionality is disabled.

This following is a collection of tips and other information that was not included in the Microsoft Windows 95 Resource Kit.

Using named pipes with Windows 95.

No server-side support is provided for named pipes in Windows 95. Client-side support for named pipes is provided in Windows 95 in each of the following configurations:

Client for Microsoft Networks.
Microsoft Client for NetWare Networks. With this configuration you must load DOSNP.EXE in WINSTART.BAT, since it needs the IPX/SPX-compatible protocol to be loaded first.
ODI, using IPXODI, DOSNP, and either the NETX or VLM clients from Novell.

Notice, however, that named-pipes client/server application must work either using DOSNP on both ends or using Client for Microsoft Networks. This is because the DOSNP implementation works over IPX/SPX, while the Client for Microsoft Networks implementation works over NetBIOS.

Brequest can be loaded in WINSTART.BAT, since it needs the IPX/SPX-compatible protocol to be loaded first. Otherwise, Btrieve Manager (the ISAM engine) can be loaded globally in AUTOEXEC.BAT. Notice that if your site uses BREQUEST.EXE version 6.15 (the version provided in the Btrieve for Windows NT product), you can load BREQUEST.EXE from AUTOEXEC.BAT using brequest /w ( the /w switch indicates Brequest for Windows).

Connecting to Novell NetWare servers.

Make sure the frame type specified for the IPX/SPX-compatible protocol is set to AUTO. If you still have problems connecting to a NetWare server, change the frame type from AUTO to the specific frame type that your server is using:

Novell NetWare version 3.11 servers default to a frame type of Ethernet 802.3
NetWare version 3.12 and 4.0 servers default to a frame type of Ethernet 802.2

Browsing NetWare print servers.

On a computer running Windows 95 with the Microsoft Client for Novell Networks installed, performing a **net view \\**novell_server command from an MS-DOS® Prompt will not list the print queues if you are not logged on to the Novell server. The Microsoft Client for Novell Networks must have read access to the PRINT_QUEUES information in the Novell server's bindery in order to display the print queues.

Notice, first, that the ability to use the net view command is a benefit of using Client for NetWare Networks; you cannot use the net view command from an MS-DOS Prompt on computers running the Novell-supplied NETX or VLM clients. To correct this problem on a computer running Client for NetWare Networks, log on to the Novell server first, then use the net view command to view the print queues on that server.

To list the print queues

From an MS-DOS Prompt, type the following command:

net use drive_letter: \\novell_server\sharename
Type your logon name when prompted.
Type your logon password when prompted.
Type the following command:

net view \\novell_server

Microsoft Information Access

Online or support service	Access procedures
The Microsoft Network	From the Microsoft menu, select Windows 95, and click WinNews. Or access the Microsoft Knowledge Base.
FTP on the Internet	Type ftp://ftp.microsoft.com/PerOpSys/Win_News
World Wide Web (Internet)	Type https://www.windows.microsoft.com
Microsoft FastTips for Windows 95	Call (800) 936-4200, available seven days a week, 24 hours a day, including holidays.
Microsoft Solution Provider for installation and support	Call Microsoft at (800) SOLPROV (or (800) 765-7768) for a referral.
Microsoft Text Telephone (TT/TDD) services	Call (206) 635-4948, between 6:00 A.M. and 6:00 P.M. Pacific time, Monday through Friday.
Microsoft Product Support Services	Standard support for non-networking issues: Call (206) 637-7098 between 6:00 A.M. and 6:00 P.M. Pacific time, Monday through Friday. After 90-day free period, call (900) 555-2000 or (800) 936-5700. For support outside the U.S., contact your local Microsoft subsidiary. Priority support, including networking issues: Priority telephone access to Windows 95 support engineers 24 hours a day, 7 days a week, excluding holidays, in the U.S. In Canada, the hours are from 6:00 A.M. to midnight, 7 days a week, excluding holidays. Priority support phone numbers and availability can be found in the Windows 95 User Guide or Readme file. Networking issues are defined as setup, configuration, or usage of Windows 95 in a networked environment. This includes, but is not restricted to the following: Setting up a computer to be used in a networked environment, network administration, dialing in to a computer, connecting to the Internet using a service provider, and using e-mail or fax from within Windows 95.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, MS-DOS, Visual Basic, Windows, Win32, and the Windows logo are registered trademarks and Windows NT is a trademark of Microsoft Corporation.

NetWare and Novell are registered trademarks of Novell, Inc.

Acknowledgments: Diagrams describing name resolution with NetBIOS over TCP/IP were created by Prakash Narasimhamurthy, Microsoft Consulting Services. Some material originally appeared in Windows NT Networking Guide (volume 2 in Microsoft Windows NT 3.5 Resource Kit).

0995

Part No. 098-61903