When Windows NT, Windows 9x, or Windows for Workgroups (WFW) clients use RAS to connect to an NT network, what subset of functionality do they have vs. local LAN-connected clients? To answer this question, I delved under the hood and determined how NT limits RAS client connectivity, and, more important, what you can do to change this behavior.
NetBIOS is the API that many network services and third-party applications running on Microsoft networks use for communication. For a RAS client to access resources on your network, you must select the Entire network option in the configuration dialog box for the protocol you're configuring on the RAS server. You must set this option for each protocol your RAS server supports. (If you're configuring IP or IPX on your RAS server, you must also enable routing for that protocol on the RAS server.) When you select the Entire network option, RAS clients can communicate with other machines on the LAN in addition to the RAS server. When you select the Entire network option in the NetBEUI configuration dialog box, you enable an additional layer of RAS functionality called the RAS NetBIOS gateway. This service lets a NetBEUI-only RAS client access shared resources on systems that aren't running NetBEUI, as long as the RAS server can access those resources.
Acting as a NetBIOS gateway, the RAS server listens on behalf of remote NetBEUI clients for specific NetBIOS request types on the network. The RAS server provides this service by posting each client's name via multiple network control block (NCB) packets. By default, RAS clients support the Messenger service for message notifications and the Server service for access to shared resources on the RAS client. (The Microsoft Windows NT Server 4.0 Resource Kit incorrectly documents that RAS clients support only the Messenger service by default.) To support the Messenger service and the Server service, the RAS server posts three or four NCB name registrations per client for each protocol bound to the RAS server. By posting these names on behalf of the RAS client, the RAS server lets LAN-based clients communicate and share resources with RAS clients. RemoteListen is the special Registry value on the RAS server that controls this configuration. This value is in the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ RemoteAccess\Parameters\NetBiosGateway Registry subkey. RemoteListen (type REG_DWORD) can have a value of 0, 1, or 2. A value of 0 represents the None configuration, which means that LAN clients have no access to resources on the RAS client. RAS server's default configuration has a RemoteListen value of 1, which Microsoft refers to as the Messages configuration.
Although the Messages configuration satisfies the needs of most RAS clients, you might find situations in which you need additional functionality (e.g., if you use the remote control services in Microsoft Systems Management Server—SMS—1.x). In these situations, for the NetBEUI-only client, you need to use an additional protocol, such as TCP/IP, or you must enhance the RemoteListen functionality on the RAS server. A RemoteListen value of 2 represents the All configuration, in which the RAS server can support additional services on behalf of the client, including interprocess communications (IPC), mail slots, remote procedure calls (RPCs), named pipes, and NetBEUI.
However, a RemoteListen value of 2 causes the RAS server to post twice as many NCBs per connected client as the default Messages configuration. This expanded functionality drains the few simultaneous NetBIOS sessions that can exist on a machine to a measly 255 sessions total. If your RAS server handles many remote clients simultaneously, filling up your available NetBIOS sessions won't take long.
In addition, by default NT doesn't impose limits on the number of names that a RAS server can post for each client or the number of simultaneous NetBIOS sessions for each client. To control these values, you can use two Registry values in the NetBiosGateway subkey: MaxNames, which controls the maximum number of client NCB_Listen name postings and defaults to the maximum value of 255, and MaxSessions, which controls the maximum number of sessions per client and also defaults to the maximum value of 255. If you limit the MaxNames value, provide at least seven name postings per client to accommodate the needs of most remote clients.
Next month, I'll continue discussing RAS clients' network access. I'll also teach you how to enable and manage the ability for RAS clients to receive network broadcasts and multicasts over different protocols.