Microsoft Corporation
July 1996
The specifications for IPX/SPX are defined by Novell, and the implementation provided with Microsoft® 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 article.
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.
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 in Part 1 of this series, except that timing is slightly different than for a LAN or for TCP/IP 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. Peer servers running Windows 95 can optionally use this method, although it is not recommended in most cases.
The browsing issues for peer servers running Windows 95 on NetWare networks depend on the method the peer server uses to advertise its presence. For peer servers running Windows 95 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 peer server running Windows 95 on a NetWare network. If you attempt to disable both of these advertising protocols, Workgroup Advertising will be enabled by default.
SAP Advertising works by sending an 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 to which they are connected. If a peer server running Windows 95 is configured to use SAP as the transport name resolution protocol, it appears in the browse list of servers that any NetWare client 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. Each entry must also be remembered by every router and every server on the network. This system works well for a small number of servers (less than 1,000), 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 1,000 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.
By default, File and Printer Sharing for NetWare uses its own name resolution and service advertising mechanism to avoid SAP Advertising problems, 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.
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 computers running Windows 95.
With Workgroup Advertising, each computer running Windows 95 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–based 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 peer server running Windows 95 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 for Microsoft networking.
With Workgroup Advertising enabled on peer servers running Windows 95, there should be no issues for interacting with Novell-based VLM or NETX clients when Windows 95–based computers run peer services on a large network. The browse masters send SAP broadcasts using SAP type 0x067B and browser backups use 0x067C—either 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 client running Windows 95 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 peer server running Windows 95 on a NetWare network. The configuration options are the following:
Figure 1. 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 computers running Windows 95 on NetWare Networks use Workgroup Advertising, see Chapter 15, "User Profiles and System Policies," in the Microsoft Windows 95 Resource Kit.
For information about how to use Wrkgrp.ini files to control the workgroups defined for computers running Windows 95, see Chapter 5, "Custom, Automated, and Push Installations," in the Microsoft Windows 95 Resource Kit.
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 peer server running Windows 95 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 it required for remote administration of computers running Windows 95 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 peer server running Windows 95 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. Peer servers running Windows 95 and using SAP Advertising will respond to a GetNearestServer broadcast.
This situation would cause an NETX or VLM client to attempt to log on to the peer server, except that Windows 95 makes sure these NETX and VLM clients connect to a real NetWare server. To prevent logon problems, Windows 95 uses 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 an NETX or VLM client attaches to a peer server running Windows 95 to attempt to log on, the peer server uses its Login.exe stub to perform the following actions:
The real-mode client does not detect any of these events—it just receives the logon connection it requested with a NetWare server, even though a peer server running Windows 95 first intercepted its GetNearestServer broadcast.
The stub login program on a peer server running Windows 95 will run only if the default server is a computer running File and Printer Sharing for NetWare. A user who is already logged on to 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 logon:
If you turn on SAP Advertising on a peer server running Windows 95, you should check the following:
In this case, if the client specifies the logon server, the user should be able to log on to the server. A nonspecific logon will continue to fail until the pass-through server is available. In this case, the user will wind up logged on to the pass-through server. For example, the following might continue to fail:
M:\SYS>LOGIN
The following example will always work if a peer server running Windows 95 ended up being the default server:
M:\SYS>LOGIN SERV_311
If the client has a preferred server specified, it will never have a peer server running Windows 95 as its default server.
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 server, you can automatically enforce a policy that either disables SAP Advertising for all Windows 95–based 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 the configuration of computers running Windows 95 on NetWare Networks—including preventing SAP Advertising from being enabled on peer servers, see Chapter 15, "User Profiles and System Policies," in the Microsoft Windows 95 Resource Kit.
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
lanabaselookahead
msextensions
namessessions
piggyback
receivebuffers
retrycountretrydelay
sendbuffers
verifytimeout
Note For the lanabase parameter: 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 the Microsoft Windows 95 Resource Kit (p. 426, U.S. edition).
NetBEUI is a nonroutable 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:
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:
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.
Figure 2. Broadcast of NameQuery using NetBEUI
The initial frame is a NameQuery frame that contains the LSN number related either to the LISTEN NCB or to the 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 whether they have the name in their name space and whether 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 the Windows NT Networking Guide (volume 2 in the 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
t1
t2
usecsa
wanretries
windowerrors
If a user cannot find a particular workgroup, the network administrator can try to resolve the problem on Microsoft networks through these steps:
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:
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:
Step 2: Verify that the correct network client is loaded. To verify that the Microsoft Client for Microsoft Networks is installed on your computer, follow these steps:
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, make sure 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:
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 cannot retrieve a browse list from the master browse server, one of the following problems may exist on the network:
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:
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.
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.
No server-side support is provided for named pipes in Windows 95. Client-side support for named pipes is provided in Windows 95 for each of the following configurations:
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).
Make sure that 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:
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 and then use the net view command to view the print queues on that server.
To list the print queues:
net use drive_letter: \\novell_server\sharename
net view \\novell_server