Some of the main topics in this chapter are
Windows NT Server is, among other things, a Network Operating System (NOS). To be effective in this role, Windows NT Server must support a variety of network clients that employ a range of different protocols. Fortunately, Windows NT Server does indeed support a broad range of protocols that can be used to service all types of clients--Windows NT Server supports native Microsoft clients (DOS, Windows, Windows for Workgroups, Windows 95, and of course, Windows NT Workstation), Macintosh clients, UNIX workstations, and others.
The price for this flexibility is the complexity it creates at the network level. Under the Windows NT Server network architecture, there are distinct and different relationships between network protocols (for example, NetBEUI, IPX, TCP/IP, and so on) and network services (for example, file sharing, print sharing, name resolution, and so on). For example, Microsoft's Windows Internet Name Service (WINS) can operate over TCP/IP but not NetBEUI or IPX.
Understanding what protocols are supported by Windows NT Server and what specific services can use those protocols is the key to understanding how to effectively deploy, expand, manage, and troubleshoot Windows NT Server in a real-life network environment.
Protocols and services are selected and configured through the Network option in Control Panel. Figure 11.1 shows an example Network tabbed dialog box. The tabs correspond to the five major areas of configuration:
The Network dialog box enables you to select and configure each of the five major areas of configuration.
Windows NT Server supports seven protocol types. Of the seven, only three can be used for mainline Windows NT Server services such as file sharing, print sharing, and native client/server applications. The other protocols are used for functions such as access to IBM SNA networks, virtual private networking, and access to Macintosh networks.
The three core Windows NT networking protocols are:
The additional protocols included in Windows NT Server for special-purpose applications are:
Network protocols are added or modified by using the Protocols tab in the Network option in Control Panel, as shown in Figure 11.2. When you click the Add button on the Protocols tab, you are presented with the Select Network Protocol list, as shown in Figure 11.3, which contains the following entries:
NetBEUI Protocol
NWLink IPX/SPX Compatible Protocol
Point-to-Point Tunneling Protocol
Stream Environment
TCP/IP Protocol
The Protocols tab in Control Panel's Network window enables you to view, add, or change protocols.
The Select Network Protocol list defines the protocols you can add to your Windows NT Server system.
Not all the protocols described in this section can be added through this interface. For example, AppleTalk cannot be loaded as an independent protocol--it is automatically loaded when you add the Services for Macintosh network service.
One additional protocol is automatically loaded when you select the NWLink IPX/SPX Compatible Protocol entry. In this case, Windows NT automatically adds the NWLink NetBIOS Interface to support native Microsoft networking services (more information about NetBIOS is presented in the next section).
As noted, Windows NT Server supports a wide variety of network services--services for file sharing, printer sharing, network management, Web access, and more. Services are added using the Services tab in the Network option in Control Panel, as shown in Figure 11.4. From a general point of view, the services supported by Windows NT Server can be divided into three categories:
The Services tab in Control Panel's Network window enables you to view, add, or change network services.
Services can be added by clicking Add on the Service tab and selecting an entry from the Select Network Service list, as shown in Figure 11.5.
The Select Network Service list defines the network services you can add to your Windows NT Server system.
To understand native Microsoft networking services, we need to look back at the original networking model used by IBM, Microsoft, and others. This model was created in 1984 when IBM and Sytek released a local area network (LAN) message interface system named the Network Basic Input/Output System, better known today as NetBIOS. NetBIOS is a generalized program-to-program communications facility that enables peer-to-peer and client/server communications between PCs operating in a LAN environment.
The NetBIOS Interface. As noted, NetBIOS is the underlying interface for native Microsoft file, print, and program-to-program communications. NetBIOS facilitates these operations through three key services:
In addition to these three core services, NetBIOS provides a limited number of status and control functions. For example, these functions can be used to cancel a NetBIOS request, get the current status of the NetBIOS interface, or start a NetBIOS-level trace.
The SMB Interface. Although NetBIOS provides a generalized interface for program-to-program communications, NetBIOS does not provide specific services to facilitate file, print, and other user-related services in a peer-to-peer or client/server LAN. That task falls on the shoulders of Server Message Blocks (SMB).
Like NetBIOS, SMB is an interface system. But whereas NetBIOS is a generalized interface system, SMB is a specific interface system that enables file sharing, print sharing, and user-based messaging over the NetBIOS interface. Some of the specific services supported by SMB include:
In the Windows NT Server environment, NetBIOS and SMB functions are integrated into various components of the operating system and its supporting utilities. For example, when you open the Network Neighborhood container or you issue a NET USE command from a command-line prompt, you are invoking NetBIOS and SMB functions. Understanding that NetBIOS and SMB are interrelated interfaces is important to understanding Windows NT Server networking. For example, when you connect to a network drive, you rely on NetBIOS services to find the name of the system sponsoring the directory you need, but you actually connect to and access that network drive using SMB services.
NetBEUI and NetBIOS. When NetBIOS was first released, the term NetBIOS encompassed both protocol-level and service-level functions. As the industry moved toward using well-defined computing models that separate protocols from services (among other things), the NetBIOS protocol and service aspects were formally separated, and the term NetBIOS Extended User Interface (NetBEUI) was adopted to define the protocol-level functions.
Microsoft pioneered the usage of the term NetBEUI and included support for the NetBEUI in its DOS-based LAN Manager product, Windows for Workgroups (WFW), Windows 95, and Windows NT products.
As successful as NetBEUI has been, it does have limitations. The most significant limitation of NetBEUI is that it does not use any addresses other than the physical LAN adapter address (the Medium Access Control, or MAC, address). In contrast, protocols like IPX and TCP/IP add a second level of addressing that defines a network address. This second level address enables IPX and TCP/IP to quickly determine whether a transmitted message needs to be routed to another physical network (because it has a different network address) or whether it can be serviced on the local network. Because NetBEUI does not use a second level address, NetBEUI cannot distinguish between local and non-local messages and is therefore considered a non-routable protocol.
The lack of address support within NetBEUI is further aggravated by an inherent problem within the NetBIOS interface. Specifically, NetBIOS uses system names to enable and manage end-to-end connections. Under NetBIOS, names are resolved using broadcast-oriented techniques. For example, when a system joins the LAN, it broadcasts its name, and when a system wants to establish a connection to a system it has not previously heard from, it broadcasts a name discovery message. Unfortunately, broadcasts create overhead in a LAN and can negatively affect overall performance.
When you combine the NetBIOS limitation with the NetBEUI limitation, you end up with network traffic that is difficult to manage over multiple, interconnected LANs or in a complex LAN/WAN environment. Specifically, you have NetBIOS generating many broadcast messages to resolve names, and because NetBEUI does not support network addressing, these broadcasts must be sent to all the attached LANs.
IPX, TCP/IP, and NetBIOS. Microsoft recognized the limitations of the NetBEUI/NetBIOS combination and took steps to formally disconnect the NetBIOS and SMB services from the LAN-level protocol. Under Windows NT, you are not forced to run NetBIOS and SMB over NetBEUI--you can, in fact, run NetBIOS and SMB over IPX or over TCP/IP. The combination of IPX and NetBIOS is referred to as the NWLink NetBIOS Interface (this is the protocol automatically loaded when the NWLink IPX/SPX Compatible Protocol is added). The combination of TCP/IP and NetBIOS is referred to as NetBIOS over TCP/IP, more frequently abbreviated to NBT.
As previously noted, TCP/IP and IPX implement network addresses; therefore, they are both considered fully routable protocols that can easily be integrated into multi-LAN environments and large wide area networks. This makes either protocol a superior choice to NetBEUI for most applications.
Unfortunately, the standard implementations of TCP/IP and IPX do not address the broadcast-intensive nature of NetBIOS. Because NetBIOS operates above the LAN-layer protocol, it is isolated from the technical details of the underlying protocol, and by the same token, the underlying protocol is isolated from the technical details of NetBIOS. That means that NetBIOS name resolution will, by default, be handled by using broadcast techniques regardless of which LAN-layer protocol is in use.
Microsoft did, however, address this problem by creating optional enhancements for the NetBIOS over TCP/IP implementation in Windows NT. Specifically, Microsoft borrowed an idea (or two) from the way TCP/IP is implemented in a UNIX environment and implemented two ways of resolving NetBIOS name requests without generating broadcasts:
Also note that Windows NT Server supports a native TCP/IP service--the Dynamic Host Configuration Protocol (DHCP)--that dynamically assigns IP addresses to workstations in the network. DHCP is a native TCP/IP service that is not directly related to the NetBIOS name resolution issues; however, DHCP works in conjunction with WINS to ensure that the WINS server is kept up-to-date on all address assignments. For further information on DHCP, see Chapter 13, "Implementing DHCP IP Management." Additional information about WINS is presented in this chapter as well as in Chapter 14, "Implementing WINS and DNS Name Resolution."
The issue of translating NetBIOS names into usable addresses will be revisited in the "Name Resolution" section of this chapter. The two significant points to note here are:
NetBIOS/SMB Service Properties. The core functions of native Microsoft networking (for example, the functions offered by NetBIOS/SMB) are delivered over three specific services. These services can be added or viewed in the Services tab of the Network option in Control Panel. The services are:
Note that an additional service--Windows Internet Name Service (WINS)--is available for NetBIOS over TCP/IP. This service should be considered a member of the family of native Microsoft networking services; however, it's not a core service, as in the case of NetBIOS Interface, Server, and Workstation.
Both the NetBIOS Interface and Server services have important settings associated with them. These settings are accessed by selecting one of the services on the Services tab and clicking the Properties button.
The properties for the NetBIOS Service are contained in the NetBIOS Configuration windows, as shown in Figure 11.6. Under the NetBIOS programming model, NetBIOS programs select the protocol and adapter they want to use based on the LANA number assignment. As shown in the figure, NetBIOS over TCP/IP (NetBT) is assigned to LANA 00, NetBIOS over NetBEUI Frames (Nbf) is assigned to LANA 01, and finally, NetBIOS over IPX (NwlnkNb) is assigned to LANA 02.
The NetBIOS Configuration window shows the current LANA assignments for the installed protocols and adapters. The LANA numbers are used by NetBIOS programs to select a transport.
In most cases, the default NetBIOS Configuration settings are fine because most NetBIOS applications don't really care what protocol is used for the transport mechanism. Unfortunately, there are a few third-party server-based applications that make assumptions about the LANA assignment and therefore require changes in this screen. As a general rule, don't change the LANA assignments without good cause.
The properties for the Service networking service are more straightforward. As shown in Figure 11.7, the Server window provides a means of determining how memory will be used in the system. The appropriate setting depends on your usage of the server:
The other option on this window--Make Browser Broadcasts to LAN Manager 2.x Clients--allows Windows NT Server to function in older LAN Manager environments. This option is discussed later in the "Name Resolution" section of this chapter.
The Server property window is used to dictate how Windows NT uses memory in your Windows NT Server system.
NetBIOS/SMB Service Bindings. The formal association between Microsoft network services and network protocols, as well as the association between network protocols and network adapters is termed binding. By default, native Windows NT networking services (such as NetBIOS Interface, Server, and Workstation) are enabled for each native protocol you add (such as NetBEUI, IPX/SPX, and TCP/IP), and each native protocol is bound to each network adapter. In some cases, it might be desirable to alter these default settings. For example, you might want to enable IPX/SPX over an Ethernet card but disable it over a token-ring card. Or you might want to disable the NetBIOS Interface over an Internet link.
You can view and change the current binding information by using the Bindings tab. This tab is located in the Network tabbed dialog box accessed via Control Panel. Figure 11.8 shows a typical Bindings tab. The display area contains a hierarchical list of entries; by default, only the top-level entries are shown. To view additional entries, you can click any entry that has a plus sign on its left-hand side. For example, Figure 11.9 shows the fully expanded version of the same tab shown in Figure 11.8.
The Bindings tab enables you to view and change the associations between network services, network protocols, and network adapters.
You can view binding information from one of three perspectives:
To see all the binding information, you must expand the display information by clicking entries preceded by a plus sign.
The protocols perspective in the Bindings tab shows the association between individual protocols and network adapters or lower-level protocols.
If you're running native Microsoft network services (NetBIOS Interface, Server, and Workstation) over the three major protocol suites (NetBEUI, IPX, and TCP/IP), the bindings shown in the Bindings tab using the services perspective should appear similar to the list shown here:
The adapters perspective in the Bindings tab shows the associations between the network adapters, network protocols, and network services.
NetBIOS Interface
NetBEUI Protocol
Network adapter (for example, Novell NE2000)
NWLink NetBIOS
NWLink IPX/SPX Compatible Transport
WINS Client (TCP/IP)
Network adapter (for example, Novell NE2000)
Server
NetBEUI Protocol
Network adapter (for example, Novell NE2000)
NWLink IPX/SPX Compatible Transport
NWLink NetBIOS
NWLink IPX/SPX Compatible Transport
WINS Client (TCP/IP)
Network adapter (for example, Novell NE2000)
Workstation
NetBEUI Protocol
Network adapter (for example, Novell NE2000)
NWLink NetBIOS
NWLink IPX/SPX Compatible Transport
WINS Client (TCP/IP)
Network adapter (for example, Novell NE2000)
If you have RAS installed, you should also see RAS "wrapper" entries at the same level where you see the network adapter(s). The wrapper entries are used to establish logical links between RAS devices (typically modems) and the protocols and services operating over RAS.
The bindings show the available paths traffic can take in and out of the server. For example, the top-level NetBIOS Interface, Server, and Workstation entries indicate that the system can send and receive native Windows NT network traffic (NetBIOS and SMB) over the three major protocols. WINS Client really refers to NetBIOS over TCP/IP. As you can see, Microsoft is inconsistent in its use of terms to refer to NBT.
If you want to restrict the traffic coming into and out of your server, simply select the binding entry associated with the service you want to control and click Disable. In response, a No indicator will appear to the left of that entry and that binding will no longer be used.
TIP: By disabling specific binds, you can tightly control how protocols are used on your Windows NT workstation. For example, if your server runs IPX and TCP/IP, but you don't want native Windows NT networking services to use TCP/IP, you can disable the WINS Client (TCP/IP) entry underneath the NetBIOS Interface, Server, and Workstation services. That way, you could use a server system as a Web server and a file/print server without exposing the file/print resources to the TCP/IP network.
Whereas Microsoft networking services involve a complex set of protocol considerations and protocol-service bindings, the TCP/IP services are far less complex to implement. In a nutshell, these are standard TCP/IP services found in many UNIX and other non-Microsoft networks. The one important factor to note here is that all the services that fall into this category do, in fact, require the TCP/IP protocol--you cannot use these services in conjunction with NetBEUI or IPX.
As in the case of the native Microsoft networking services, the TCP/IP services are added via the Services tab on the Network option in Control Panel. The services that fall into this category are:
Each service has it own configuration options; however, none of these services has any optional binding parameters--by definition, they are all bound to TCP/IP protocol.
The final category of networking services contains services not bound to the NetBIOS/SMB model or solely to the TCP/IP protocol. As such, these services embrace a variety of protocols. The services included in this category are:
A Windows NT Server system can, in fact, be used as a LAN-to-LAN router for IPX, IP, and AppleTalk traffic. The simple truth is, however, that a Windows NT Server system makes a poor router--it does not offer the flexibility, manageability, or performance of a dedicated router. Any enterprise-class network is better served by dedicated routers. In smaller companies, or in the case of departmental needs, it might occasionally make sense to allow a Windows NT Server system to act as a router. Just remember that most routers provide capabilities above and beyond what Windows NT Server can offer as a router.
To enable IPX routing, you must have two network adapters installed in the Windows NT Server system that will act as a router. You must also install the RIP for NWLink IPX/SPX Compatible Transport network services. If you are routing for native NetWare traffic (as opposed to NetBIOS over IPX traffic), you must also install the SAP Agent network service.
After the hardware and software configuration is in place, you enable IPX routing by accessing the properties window for the NWLink IPX/SPX Compatible Transport protocol. Open Control Panel, select the Network option, select the Protocol tab, highlight the NWLink IPX/SPX Compatible Transport entry, and click Properties. Click the Routing tab to expose the Enable RIP Routing option, as shown in Figure 11.12. Simply check the option box to enable routing.
IPX routing works in conjunction with the RIP for NWLink IPX/SPX network service and optionally the SAP Agent network service.
Routing for IP networks is similar, but has an additional layer of complexity. Like IPX routing, IP routing requires two (or more) network adapters. In the case of IP routing, however, you must assign each network address to a different subnet address--you should never have multiple network adapters in the same Windows NT Server system assigned to the same subnet (although you can have multiple IP addresses in the same subnet assigned to a single card).
You do not need to install the RIP for Internet Protocol or the DHCP Relay Agent network services to perform basic IP routing with Windows NT Server. After you have multiple network adapters configured with different subnet addresses, simply access the Microsoft TCP/IP Properties by selecting the TCP/IP protocol in the Network option of Control Panel and clicking Properties. In the TCP/IP Properties window, click the Routing tab to access the Enable IP Forwarding option, as shown in Figure 11.13.
The Routing tab on the TCP/IP protocol properties box enables you to activate simple routing. Other network services can be used to enhance this capability.
When you enable IP forwarding without the RIP and DHCP Relay services, the Windows NT Server system provides static routes between the subnets defined on its network adapters. If you want a Windows NT Server system to share routing information with other routers (and vice versa), you must install the RIP for Internet Protocol network service--this enables the Windows NT Server system to learn of new routes dynamically.
If you need to forward BOOTP or DHCP address assignment requests between IP subnets, you must install the DHCP Relay Agent. BOOTP/DHCP assignment requests are initiated by broadcast requests, and broadcast requests are not normally routed between subnets. The DHCP Relay agent catches these broadcast requests, inserts subnet information into them, and forwards them on to other subnets so that they can be found by a DHCP or BOOTP server.
Finally, you can use Windows NT Server AppleTalk routing if you have multiple network adapters installed and you are running the Services for Macintosh network service. The routing information for AppleTalk is maintained in the properties window for the Services for Macintosh network service. Open Control Panel, select the Network option, highlight the Services for Macintosh service, and click Properties to activate this window. Then click the Routing tab to see the routing options, as displayed in Figure 11.14.
The Routing tab on the Services for Macintosh network service properties box enables you to configure AppleTalk routing.
To enable routing, you must check the Enable Routing option. You can also configure the Windows NT Server system to seed one or more of the attached AppleTalk subnets. Seeding requires you to specify the network ranges and zone assignments for the subnet attached to a specific network adapter. If you enable seeding, all routers on the network must be configured with the same network and zone assignments.
A Windows NT Server system is capable of routing multiple protocols on a concurrent basis--thus you can deploy a single Windows NT Server system as both an IPX and IP router. Of course, routing takes processor and network resources away from other Windows NT services, such as file and print sharing. The bottom line is Windows NT Server can be used as a router, but it should only be used as the last resort.
Code Named SteelheadMicrosoft is offering a replacement for the current IPX/IP routing capabilities of Windows NT Server. Under the enhanced routing implementation (code named "Steelhead"), a single service named "Routing and Remote Access Service" replaces the following Windows NT Server 4.0 networking services:
DHCP Relay Agent
Remote Access Service
RIP for Internet Protocol
RIP for NWLink IPX/SPX Compatible Transport
SAP Agent
Note that the enhanced routing implementation is focused on TCP/IP and IPX--the current AppleTalk routing capabilities are unchanged.
Microsoft's enhanced routing implementation addresses many of the limitations of Windows NT Server's out-of-the-box routing capabilities. Some of the specific improvements delivered via the new implementation include:
Demand-dial routing over telephone connections
Support for Open Shortest Path First (OSPF) routing protocol.
Improved performance
Increased security through packet-level filtering
SNMP-based management
Command-line management utilities
An improved user interface for configuration and monitoring
In more general terms, the intent of the enhanced routing implementation is to increase Windows NT Server's routing capabilities so that Windows NT Server can compete head-to-head with conventional routers.
NetBIOS names, IP names, and IP addresses add order and structure to a network, but for one system to efficiently deliver a message to another system in a LAN environment, it must know the MAC address (the address on the network adapter) of the target system. Without this piece of information, the only way to get a message to a system is to broadcast it to all systems--an inefficient approach by any standard.
The need for MAC-level addresses transcends all protocols; NetBEUI, IPX, and TCP/IP depend on MAC-level addresses for the final delivery of a message. Although they all share that common need, they do approach the problem differently. A comparison of the native TCP/IP method (as opposed to NBT) and the NetBEUI method for MAC address discovery reveals some interesting insights into Windows NT Server networking.
TCP/IP networks have three levels of addressing: the IP name, the IP address, and MAC address. The IP name and IP address information is maintained either in a DNS server or in a local "hosts" file typically stored on each computer. When a name is resolved on native TCP/IP network, the following steps are performed:
2. The IP address indicates whether the target system is in the same subnet (in other words, it has the same network address as the source system) or whether the message needs to be forwarded through one or more routers or gateways.
3. After the message reaches the LAN where the target system resides, the target system's LAN adapter address is discovered via the Address Resolution Protocol (ARP). This discovery will be performed by the source system if it is on the same LAN as the target system, or by the gateway servicing the target system.
ARP is the key to MAC address discovery in any TCP/IP network. Here's how it works. The first time System A wants to send a message to System B, it sends out a broadcast message using ARP. Because it is a broadcast message, each system in the local LAN sees it. When System B sees the message, it finds its own IP address in it, recognizes that it is an ARP request, and returns a message to System A containing its MAC address. System A then caches the IP address and corresponding MAC address in memory for subsequent use.
The NetBEUI protocol uses a different approach for NetBIOS name resolution. In a NetBEUI network, a NetBIOS name is directly translated into a MAC address--there is no intervening address structure (no IP address). Therefore when a system wants to send a message to another system, it sends a broadcast request out to all the systems containing the NetBIOS name of the system. All the systems see that message, and the system that owns the name responds with its MAC address.
Both approaches ultimately use a broadcast method to find the MAC address, so, in that context, is TCP/IP really any better than NetBEUI? The key advantage is that the TCP/IP methodology uses the intervening IP address that enables the request to be routed to the correct destination network before the ARP broadcast is made. In a NetBEUI network, the broadcast has to be made on all connected networks because there is no concept of subnetting. Needless to say, that approach isn't very efficient.
NOTE: NetBIOS over IPX uses the same broadcast-oriented name resolution technique employed by NetBEUI.
Given that TCP/IP has a more reasonable approach for name resolution, does that mean that Windows NT can use the same methodology for NetBIOS over TCP/IP traffic? Although Windows NT does indeed support resolution via DNS and ARP, Microsoft provided an alternate name resolution method: WINS.
The principal disadvantage of using DNS for NetBIOS name resolution is that DNS does not work with DHCP. Instead, DNS demands the manual configuration of IP names and addresses. WINS, on the other hand, provides name-to-address mapping similar to DNS, but it also enables systems to report their IP addresses when they start up.
Under the WINS approach, each system is configured with the address of one or more WINS server. The WINS server address can be manually configured or downloaded via DHCP. When the system initializes and determines that it has a valid IP address (either a static address or one assigned via DHCP), it then sends a message to the WINS server announcing its name and IP address. The WINS server records that information for future use.
When a WINS server is used, the name resolution process looks very much like the DNS name resolution process:
2. The IP address indicates whether the target system is in the same subnet or whether the message needs to be forwarded through one or more routers or gateways.
3. After the message reaches the LAN where the target system resides, the target system's LAN adapter address is discovered via the Address Resolution Protocol (ARP).
Again, the primary distinction between DNS and WINS is that WINS works in cooperation with DHCP.
A Windows NT system (Workstation or Server) operating in a TCP/IP network can resolve names using any or all of the three methods--DNS, broadcast, or WINS. The order a Windows NT system uses to resolve names is determined by the WINS NetBT Node Type setting. This setting can be downloaded via DHCP. By default, a client configured for WINS support uses type 8, and a client not configured for WINS support uses type 1.
All these types share the same preprocessing and post-processing steps. Specifically, if the name is an IP-style name (for example, xena.warrior.com), the Windows NT system will interrogate a configured DNS server. Alternatively, if the name is not an IP-style name, the Windows NT system will check its local cache of NetBIOS names. If the name is not located in either of those two locations, the system will do the next lookup based on the node type:
If the name is not resolved via WINS or broadcast, the system then checks the LMHOSTS file (if present), queries a DNS server (if configured), and finally checks the local HOSTS file (if present).
Name-to-address resolution is an important issue, but it begs the question: Where do you find NetBIOS names in the first place? In a Microsoft network, you can discover these names using the Network Neighborhood container or File Manager network drive display. In both cases, you receive a list of NetBIOS names. Reporting and detecting these names are handled by a process known as browsing.
In a Microsoft network, each computer sends a broadcast message when it starts up. The broadcast message identifies its NetBIOS name. This is referred to as a name registration message. Although this message lets other systems know that a computer has joined the network, it does not let the joining computer know who is already present in the network.
The task of maintaining an accurate list of who is on the network is handled by the master browser. The master browser is a computer system elected by the other systems to watch for new systems coming on to the network. When a system wants a current list of which systems are on the network, it simply asks the master browser, and the master browser returns the list. Each computer learns which system is the master browser when it sends its initial name registration message.
As noted, a master browser is normally elected. If present, a domain controller (primary or backup) will end up with the assignment. In environments with no domain controller and a mixture of Windows NT and non-Windows NT systems, it is often necessary to force a Windows NT system to be the master browser. You can force a Windows NT system (Workstation or Server) to be the master browser with the following Registry key addition:
Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters
Value:
IsDomainMaster (REG_SZ) True
Each domain (or workgroup) has its own master browser. By default, the master browser is the Primary Domain Controller for each domain. A backup master browser may also be present--in the case of a domain, this is normally the Backup Domain Controller. Master browsers alert one another to each other's presence through special broadcast messages.
The concept of a master browser was introduced to Microsoft networking when Windows for Workgroups was released. Prior to that, individual systems periodically sent out name announcement messages to let other systems know that they were on the network. Each individual system was then responsible for maintaining a list of other systems in the network. You can configure Windows NT Server to issue those periodic broadcasts by checking Make Browser Broadcasts to LAN Manager 2.x Clients in the Server Service properties window, as explained in the "NetBIOS/SMB Service Properties" section earlier in this chapter.
The wide range of protocols and services supported by Windows NT Server allows it to accommodate connections from a variety of clients using a variety of client-side software. Most of these topics are covered in detail elsewhere in this book; however, a brief review of the client environment highlights the protocols and services discussed in this chapter.
Finally, another technique you can use to open the door to new types of clients is to change the way that Windows NT Server appears to the client. In particular:
Finally, all these client types can be serviced in an intranet environment using standard Windows NT-based TCP/IP tools and utilities. You can, for example, use a Windows NT Server system as a Web server to provide information retrieval and file download capabilities. This is a radically different type of solution than standard Microsoft networking, but it's effective in many environments.
© Copyright, Macmillan Computer Publishing. All rights reserved.