Share via

Appendix C – Computer Browser Service

  • Article

Writer: Joe Davies

Abstract

This appendix describes how the Computer Browser service on computers running Microsoft® Windows® XP or Windows Server™ 2003 operating systems works to display the list of workgroups and domains and the servers within them for the contents of the Microsoft Windows Network window and related windows in My Network Places. A network administrator must understand how the Computer Browser service works over an IPv4 network to determine why some domains, workgroups, or the server computers within them are not displayed.

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this appendix that has been updated for Windows Vista and Windows Server 2008, click here.

On This Page

Computer Browsing Overview
Computer Browser Service Operation on an IPv4 Network

Computer Browsing Overview

The Computer Browser service in Windows XP and Windows Server 2003 maintains an updated list of domains, workgroups, and server computers on the network and supplies this list to client computers upon request.

A domain is a grouping of computers that provide a centralized account database and security. The definition of domain for computer browsing is separate from its definition for the Active Directory® directory service. In Active Directory, a domain is a collection of computer, user, and group objects defined by the administrator. These objects share a common directory database, security policies, and security relationships with other domains.

A workgroup is a logical grouping of computers that helps users locate shared resources such as folders and printers. Workgroups do not offer the centralized user accounts and security offered by domains. A LAN group is either a domain or a workgroup.

The Computer Browser service maintains a distributed series of lists of available network resources as viewed from the following locations:

  • Using the new Windows XP-style Start menu, click Start, and then click My Network Places. In the My Network Places window, click Entire Network. In the Entire Network window, double-click Microsoft Windows Network.

  • Using the classic Windows Start menu, double-click My Network Places on your desktop. In the My Network Places window, double-click Entire Network. In the Entire Network window, double-click Microsoft Windows Network.

For either method, the Microsoft Windows Network window displays a list of LAN groups.

The list of LAN groups and the servers within them are distributed to automatically elected browse server computers. Computers elected as browse servers eliminate the need for all computers to maintain a list of all the LAN groups and their servers on the network and lowers the amount of network traffic required to build and maintain a list of all the computers on the network.

The browse list, the list of LAN groups and the servers within them that are accumulated and distributed by the Computer Browser service, is separate from the list of computers maintained in Active Directory. For example, when you click Search Active Directory in the Network Tasks pane of the My Network Places window, the Find Users, Contacts, And Groups dialog box is displayed. Queries using this dialog box are performed against Active Directory, not against the browse list maintained by computers running the Computer Browser service.

The Computer Browser service operates by exchanging a set of NetBIOS over TCP/IP (NetBT) broadcast and unicast messages. There is no support for computer browsing over IPv6. If NetBT is disabled, the Computer Browser service can no longer operate. This means that for a network that has NetBT disabled and is just using the Domain Name System (DNS) and Active Directory, you cannot view any LAN groups or servers using the Entire Network window. You must use find computers using Active Directory.

Computer browsing over remote access connections is aided by the new NetBT proxy in Windows Server 2003, which is enabled by default for Routing and Remote Access on all interfaces that are not connected to the Internet.

For more information about NetBT, see Chapter 11, "NetBIOS over TCP/IP" and Chapter 12 "Windows Internet Name Service Overview."

The Computer Browser service in Windows XP and Windows Server 2003 performs three processes:

  • Collection of browsing information

  • Distribution of browsing information

  • Servicing of browse client requests

Browsing Collection and Distribution

The browsing collection and distribution processes occur between designated browse server computers. The following types of browse servers are defined:

  • Master Browse Server

    A computer that collects and maintains the browse list of available servers within its LAN group and a list of other LAN groups and their Master Browse Servers. It also distributes the browse list to the Backup Browse Servers.

  • Backup Browse Server

    A computer that receives a copy of the browse list from the Master Browse Server, and distributes information in the browse list to browse clients upon request.

  • Domain Master Browse Server

    The first domain controller to register the NetBIOS name of Domain[1B] becomes the Domain Master Browse Server. Besides being a Master Browse Server for its domain, the Domain Master Browse Server synchronizes the browse list for the Master Browse Servers in the domain that are located on remote subnets.

Computers are designated the Master Browse Server or a Backup Browse Server through an automatic election process. For a given LAN group, there is only one Master Browse Server and zero or more Backup Browse Servers. The number of Backup Browse Servers depends on the number of servers in the LAN group. For more information, see Windows 2000 Browser Service.

Computers running Windows XP and Windows Server 2003 can perform the Master Browse Server and Backup Browse Server roles. Only a computer running Windows Server 2003 that is acting as a domain controller can perform the Domain Master Browse Server role.

The Collection Process

The Master Browse Server performs the collection process by accumulating the following information in its browse list:

  • A list of servers within its LAN group

    Periodically, every computer running the Server service within the LAN group broadcasts a Host Announcement packet to the NetBIOS name LANGroup[1D]. The Server service corresponds to the File and Printer Sharing for Microsoft Networks component in Network Connections and provides file and print sharing using the Common Internet File System (CIFS), also known as the Server Message Block (SMB) protocol. The Master Browse Server processes the Host Announcement packet and adds or refreshes the sender’s computer name in the list of servers of the LAN group.

  • A list of other LAN groups

    Periodically, every Master Browse Server of a LAN group broadcasts a Domain Announcement or Workgroup Announcement packet to the NetBIOS name [01][02]__MSBROWSE__[01][02]. Contained in the Domain Announcement or Workgroup Announcement packet is the LAN group name and the computer name of the Master Browse Server. Each Master Browse Server stores the announced LAN group name and its associated Master Browse Server in the browse list.

The Distribution Process

The Master Browse Server distributes the browse list to the Backup Browse server computers that will service the requests from browse clients. This occurs through the following:

  • Local Master Announcement packet

    Periodically, the Master Browse Server broadcasts a Local Master Announcement packet to the NetBIOS name LANGroup[1E]. This packet informs the Backup Browse Servers that a Master Browse Server for the LAN group still exists. If the Master Browse Server does not periodically sent a Local Master Announcement packet, a Backup Browse Server starts an election by broadcasting an Election packet to the NetBIOS name LANGroup[1E]. The election process selects a new Master Browse Server. For more details about the election process and election criteria, see Windows 2000 Browser Service.

  • Browse list pull operation from Master Browse Server to Backup Browse Server

    Periodically, each Backup Browse Server contacts the Master Browse Server in its LAN group to download the browse list. The downloaded browse list includes the list of servers within the LAN group and the list of other LAN groups and their associated Master Browse Servers.

Figure C-1 shows the collection and distribution process.

Bb726989.APC_XX01(en-us,TechNet.10).gif

Figure C-1 The Computer Browser service collection and distribution processes

Servicing Browse Client Requests

After the browse list has been built by the Master Browse Server and distributed to the Backup Browse Servers, it can be used to service browse client requests.

Browse clients request the following:

  • The list of servers within its LAN group

  • The list of servers within another LAN group

  • The list of shares on a server

Obtaining the List of Servers Within its LAN Group

On a computer running Windows XP or Windows Server 2003 that is a member of a workgroup, you can view the list of servers in its own workgroup by clicking on View Workgroup Computers in the Network Tasks pane of the My Network Places window. On a computer running Windows XP or Windows Server 2003 that is a member of a domain, you can view the list of servers in its own domain by double-clicking your domain name in the Microsoft Windows Network window.

To get the list of servers within its LAN group, the browse client does the following:

  1. Upon startup, the browse client broadcasts a Get Backup List Request packet to the NetBIOS name LANGroup[1D].

  2. The Master Browse Server responds to the client request with a list of computer names for Backup Browse Servers in the LAN group.

  3. The client randomly selects one of the Backup Browse Servers. When the user wants to view the list of servers in its LAN group, the computer sends the selected Backup Browse Server a request for the servers in its LAN group.

  4. The Backup Browse Server responds with the list of servers in the LAN group.

Figure C-2 shows this process.

Bb726989.APC_XX02(en-us,TechNet.10).gif

Figure C-2 Servicing browse client requests

For subsequent requests for a list of servers within its LAN group, the client continues to use the list of Backup Browse Server names obtained during startup and does not broadcast a new Get Backup List Request packet. The success of the browse client request is dependent on the client getting a response from the Master Browse Server and the client’s ability to resolve the computer name of the randomly selected Backup Browse Server to its IPv4 address.

Obtaining the List of Servers Within Another LAN Group

On a computer running Windows XP or Windows Server 2003 that is a member of a workgroup, you can view the list of servers in another LAN group by clicking on the LAN group name in the Browse For Folder dialog box. On a computer running Windows XP or Windows Server 2003 that is a member of a domain, you can view the list of servers in another LAN group by double-clicking the LAN group name in the Microsoft Windows Network window.

To get the list of servers within another LAN group, the client broadcasts a Get Backup List Request packet to the NetBIOS name LANGroup[1D]. The Master Browse Server for that LAN group responds to the client request with a list of computer names for Backup Browse Servers within the LAN group. The client then randomly selects one of the Backup Browse Servers and sends it a request to download the list of servers in the LAN group. The response from the selected Backup Browse Server contains the list of servers in the LAN group.

The success of this operation depends on the client getting a response from the Master Browse Server for the LAN group and the client’s ability to resolve the computer name of the randomly selected Backup Browse Server of the LAN group to an IPv4 address.

Obtaining the List of Shares on a Server

On a computer running Windows XP or Windows Server 2003, you can view the list of shares on a selected server by double-clicking the computer in the LAN group window. Alternately, you can view the list of shares of a specific computer from the display of the net view \\ servername command.

To get the list of shares on a server, the client computer attempts to resolve the NetBIOS name for the Server service on the desired computer, which corresponds to ComputerName[20]. After the name is resolved, a TCP session, a NetBIOS session, and an SMB session are created between the browse client and the file sharing server. After the SMB session is created, the client requests a list of shares.

Although the request for the list of servers does not involve the Computer Browser service or browse servers, it is part of the browsing operation done through My Network Places.

The success of this client request is dependent on the client’s ability to resolve the computer name of the selected computer to its IPv4 address and to establish an authenticated SMB session with the server.

Computer Browser Service Operation on an IPv4 Network

Because the Computer Browser service relies on a series of broadcast NetBIOS over TCP/IP packets, the placement of IPv4 routers can create problems. IPv4 routers do not forward broadcast packets. To facilitate client browsing of all network resources in an IPv4 network, there must be mechanisms for the collection, distribution, and servicing of client requests for browse lists when servers, browse servers, and browse clients are located on different subnets.

The browsing collection, distribution, and the servicing of client requests across IPv4 routers must now take place using a combination of unicast and broadcast IPv4 traffic, rather than just broadcast IPv4 traffic. To facilitate computer browsing across an IPv4 network, the Computer Browser services uses the following:

  • Windows Internet Name Service (WINS) WINS helps in the collection of browse lists and the servicing of client requests.

  • Entries in the Lmhosts file Special entries in the Lmhosts file help facilitate the distribution of browsing information and the servicing of client requests.

Note  The Computer Browser service relies on media access control (MAC)-level broadcast packets sent using NetBT to and from UDP port 138 (the NetBIOS datagram port). In contrast, B-node NetBIOS name registration and name query requests are sent as MAC-level broadcasts over UDP port 137 (the NetBIOS name service port). Some routers can be configured to forward NetBIOS broadcasts from one IPv4 subnet to another. If the IPv4 router is configured to forward NetBIOS broadcasts, the Computer Browsing service works as if all the LAN groups were located on the same subnet. All Master Browse Servers are aware of all servers in their LAN group and all other LAN groups and all browse client requests can be satisfied.

If NetBIOS broadcast forwarding is enabled on all IPv4 routers in the network, the following sections do not apply. However, this solution is highly discouraged because it increases the amount of broadcast traffic on each subnet, leading to decreased performance by all nodes on the network. Enabling broadcast forwarding can also cause browse server election conflicts.

The following sections examine how the Computer Browser service works across an IPv4 network for these browsing situations:

  • Domain spanning an IPv4 router

  • Multiple domains separated by IPv4 routers

  • Workgroup spanning an IPv4 router

  • Multiple workgroups separated by IPv4 routers

Domain Spanning an IPv4 Router

Figure C-3 shows a domain that spans an IPv4 router. There are domain members on at least two different subnets located across an IPv4 router.

Bb726989.APC_XX03(en-us,TechNet.10).gif

Figure C-3 A domain that spans an IPv4 router

For this configuration, the following sections examine:

  • The collection and distribution process

  • The servicing of browse client requests

Collection and Distribution Process

When using domains that are split across routers, browse server elections occur within each subnet and each subnet functions as an independent browsing entity with its own Master Browse Server and Backup Browse Servers.

Each Master Browse Server collects the following for its own subnet:

  • The list of servers within its domain, by listening for Host Announcement packets sent by computers in its domain.

  • The list of other LAN groups and their corresponding Master Browse Servers, by listening for Domain Announcement or Workgroup Announcement packets sent by the Master Browse Servers of other LAN groups.

If all the servers in the domain existed on one subnet, the Domain Master Browse Server would also be the Master Browse Server for the domain. In the configuration in Figure C-3, the Domain Master Browse Server is attached to only one subnet. To facilitate the flow of information for the browse list across the IPv4 router, the Master Browse Servers on the other subnets must communicate with the Domain Master Browse Server. The communication between the Domain Master Browse Server and Master Browse Servers takes two forms:

  • Master Browse Servers update the Domain Master Browse Server with their collected list of servers in the domain and other LAN groups on its subnet.

  • Master Browse Servers download the Domain Master Browse Server's browse list, which contains all of the server names within the domain and all other LAN group names collected by the Domain Master Browse Server and all other Master Browse Servers on other subnets.

The result is that each Master Browse Server gets the Domain Master Browse Server's browse list. The Backup Browse Servers on each subnet download the browse list from their local Master Browse Server.

The communication between the Master Browse Server and Domain Master Browse Server occurs periodically through unicast IPv4 traffic. The Master Browse Server for each subnet contacts the Domain Master Browse Server to exchange information. The Master Browse Server resolves the IPv4 address of the Domain Master Browse Server using either:

  • WINS If the Master Browse Server is a WINS client, it will query its WINS servers for the NetBIOS name Domain[1B]. Only the Domain Master Browse Server registers this NetBIOS name.

  • Lmhosts file The Master Browse Server can use special entries in the Lmhosts file to locate the Domain Master Browse Server. The details of these entries are discussed in the “Configuring the Lmhosts File for an Domain that Spans IPv4 Routers” section of this chapter.

Servicing Browse Client Requests

When servicing browse client requests, the browse client can request the following:

  • List of servers within its domain or a LAN group on its subnet

    To get the list of servers within its domain or for a LAN group on its subnet, the browse client initially broadcasts a Get Backup List Request packet to the NetBIOS name LANGroup[1D]. The Master Browse Server for the LAN group on the browse client’s subnet responds to the browse client request with a list of computer names for Backup Browse Servers. The browse client then randomly selects one of the Backup Browse Servers and contacts it directly for a list of servers within the LAN group.

  • List of servers within another LAN group on another subnet

    This process is described in the “Multiple Domains Across IPv4 Routers” section of this chapter.

  • List of shares on a server

    To get the list of shares on a server, the browse client attempts to resolve the NetBIOS name for the Server service on the desired computer, which corresponds to ComputerName[20]. Once the name is resolved, a TCP session, a NetBIOS session, and an SMB session are created between the browse client and the desired server. The list of shares on the server computer is sent over the SMB session.

Configuring the Lmhosts File for an Domain that Spans IPv4 Routers

To enable direct communication between Master Browse Servers on remote subnets and the Domain Master Browse Server for computers that are not enabled to use WINS, you must configure the Lmhosts file with the NetBIOS names and IPv4 addresses of the browse server computers.

The Lmhosts file on each subnet’s Master Browse Server should contain a series of entries for all the domain controllers of the domain. Each entry must have the following information:

  • The IPv4 address and computer name of the domain controller

  • The domain name preceded by the #PRE #DOM: tags

The following is an example entry:

131.107.7.80 DC100 #PRE #DOM:EXAMPLE

For this Lmhosts entry, a domain controller for the EXAMPLE domain is a computer named DC100 at the IPv4 address of 131.107.7.80. By adding entries for all the domain controllers, regardless of which domain controller becomes the Domain Master Browse Server, the Lmhosts files do not need to be changed on the other Master Browse Server computers.

When multiple Lmhosts entries exist for the same domain name, a computer running Windows XP or Windows Server 2003 acting as a Master Browse Server determines which of the entries corresponds to the Domain Master Browse Server by sending a query to each the IPv4 address. Only the Domain Master Browse Server responds to the query. The computer then contacts the Domain Master Browse Server to exchange browse list information.

At each domain controller, the Lmhosts file must be configured with entries for each of the Master Browse Servers on remote subnets. By default, the Master Browse Server computer is elected using a set of election criteria. To ensure that a specific computer is elected the Master Browse Server, set the registry value HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters\IsDomainMaster to TRUE (REG_SZ). A computer with IsDomainMaster set to TRUE will typically only lose an election to the Domain Master Browse Server or other computers with IsDomainMaster set to TRUE.

After you have configured the IsDomainMaster registry value on a designated server computer on each subnet, add entries to the Lmhosts file on each domain controller for each of the designated Master Browse Servers. These entries allow the Domain Master Browse Server to determine the set of computers to contact to distribute the Domain Master Browse Server's browse list.

Multiple Domains Separated By IPv4 Routers

Figure C-4 shows multiple domains that are separated by an IPv4 router.

Bb726989.APC_XX04(en-us,TechNet.10).gif

Figure C-4 Multiple domains separated by an IPv4 router

For this configuration, the following sections examine:

  • Collection and distribution process

  • Servicing browse client requests

Collection and Distribution Process

Besides collecting the servers in its domain, a Master Browse Server collects the names of other LAN groups on its subnet. All of this information is sent to the Domain Master Browse Server and distributed to the other Master Browse Servers for that domain. Browse clients within that domain see the list of all of the LAN groups that have been collected.

One enhancement WINS adds to the mechanism of collecting LAN group names is that a WINS-enabled Domain Master Browse Server periodically queries the WINS server to obtain a list of all of the domains from the WINS database. The Domain Master Browse Server queries WINS for all the NetBIOS names that end with the 0x1B character. All NetBIOS names of this type are NetBIOS domain names that were registered by Domain Master Browse Servers.

The list of domains obtained through the WINS query only contains the domain names and their corresponding IP addresses. The list does not include the names of the Domain Master Browse Servers that registered those names. To obtain the Domain Master Browse Server for the domain, the Domain Master Browse Server computer sends a NetBIOS Adapter Status message to each IPv4 address corresponding to the NetBIOS computer name Domain[1B] for each domain collected through the WINS query. The response to the NetBIOS Adapter Status message contains the computer name of the computer that registered the domain name. In this way, the Domain Master Browse Server completes its list of domain names and their corresponding Domain Master Browse Servers.

The advantage of this process is that the Domain Master Browse Server for any domain now has a list of all domains (for those Domain Master Browse Servers that are WINS clients or have static WINS entries), including those on remote subnets that are not spanned by its domain.

Servicing WINS-enabled Client Requests for Remote Domains

When a client requests a list of servers from a domain other than its own, the process for resolving the Master Browse Server for the domain depends on the client type. For WINS clients, the client broadcasts a Get Backup List Request packet to the NetBIOS name LANGroup[1D] to get a list of Backup Browse Servers from a local Master Browse Server. Because the browse client is requesting a set of Backup Browse Servers for a remote domain, it will not receive a response to the broadcasted Get Backup List Request packet.

The client then requests the IPv4 address of the domain’s Domain Master Browse Server from WINS by querying for the NetBIOS name Domain[1B]. The WINS name query will only be successful for domains for which the Domain Master Browse Server is a WINS client or has a static WINS entry.

If the client receives a positive name response from the WINS server, the following process occurs:

  1. The client sends a unicast Get Backup List Request packet to the IPv4 address of the Domain Master Browse Server (corresponding to the NetBIOS name Domain[1B]).

  2. The Domain Master Browse Server responds with a list of Backup Browse Servers. The client randomly selects one of the Backup Browse Servers and uses a WINS query (for the NetBIOS name BackupBrowseServerName[20]) to get the IPv4 address of the selected Backup Browse Server for the domain.

  3. The browse client then connects to the Backup Browse Server and requests a list of servers in its domain.

  4. The Backup Browse Server returns the list of servers to the browse client.

Figure C-5 shows this process.

Bb726989.APC_XX05(en-us,TechNet.10).gif

Figure C-5 Servicing a WINS-enabled client requests for a positive WINS server response

The browse client may receive a negative name response for the NetBIOS name query LANGroup[1B] if the LAN group is a workgroup, the domain controller for the domain is not a WINS client or has a static WINS entry, or if the domain controller for the domain is a WINS client and the domain controller and the browse client are not sharing a common WINS database (via replication). If the browse client receives a negative name response from the WINS server, the following process occurs:

  1. The browse client makes a connection with its local Master Browse Server and requests the name of the Master Browse Server of the desired LAN group.

  2. The local Master Browse Server returns the name of the Master Browse Server that advertised the LAN group.

  3. The client resolves the NetBIOS name of the Master Browse Server that advertised the LAN group (MasterBrowseServerName[20]) and makes a connection with that Master Browse Server to request a list of servers in the LAN group.

  4. The Master Browse Server returns the list of servers in the LAN group to the browse client.

Figure C-6 shows this process.

Bb726989.APC_XX06(en-us,TechNet.10).gif

Figure C-6 Servicing WINS-enabled client requests with a negative WINS server response

Servicing non-WINS Client Requests for Remote Domains

For browse clients that are not using WINS, the process for obtaining a list of servers in a remote domain is the following:

  1. The client broadcasts a Get Backup List Request packet to the NetBIOS name Domain[1D] to get a list of Backup Browse Servers from a local Master Browse Server. The client also broadcasts a NetBIOS name query for the NetBIOS name Domain[1B]. Since the client is attempting to obtain a list of servers in a remote domain, there is no response to this broadcasted query.

  2. The client makes a connection with its local Master Browse Server and requests the name of the Master Browse Server of the desired domain.

  3. The local Master Browse Server returns the name of the Master Browse Server that advertised the domain.

  4. The client resolves the NetBIOS name of the Master Browse Server that advertised the LAN group (MasterBrowseServerName[20]) and makes a connection with that Master Browse Server to request a list of servers in the LAN group.

  5. The Master Browse Server returns the list of servers in the LAN group to the browse client.

Figure C-7 shows this process.

Bb726989.APC_XX07(en-us,TechNet.10).gif

Figure C-7 Servicing a browse client request for a remote domain when WINS is not enabled

This process works for both domains and workgroups.

The success of this process depends on the following:

  • The local Master Browse Server has the name of the Master Browse Server that advertised its LAN group in its browse list. This information is available for those LAN groups that were collected through Domain Announcement or Workgroup Announcement packets and for those domain names collected through the WINS query for all names ending with 0x1B.

  • The client is able to resolve the NetBIOS name of the Master Browse Server (MasterBrowseServerName[20]) of the remote LAN group. For a browse client that is not using WINS, entries must be added to the Lmhosts file for the Master Browse Servers of remote LAN groups.

If the Domain Master Browse Servers for different domains are not WINS-enabled and the domains do not span a common subnet, the domains become stranded. They never appear in each other's browse lists. It is possible to browse a stranded domain by name by using the net view /d: domain command. However, this command is only successful if the browse client can resolve the NetBIOS name Domain[1B]. For browse clients on which WINS is not enabled, you can add an entry to the local Lmhosts file for the NetBIOS name Domain[1B] with the IPv4 address of the Domain Master Browse Server for that domain.

Workgroup Spanning an IPv4 Router

A workgroup that spans an IPv4 router creates two separate workgroups. With workgroups, there is no mechanism to propagate the list of servers collected by the Master Browse Server on one subnet to the Master Browse Server on another subnet. Master Browse Servers for workgroups do not register a special NetBIOS name with WINS that may be used by workgroup Master Browse Servers or by browse clients. There are no special Lmhosts entries that are used to forward unicast workgroup browse list information between Master Browse Servers.

Figure C-8 shows an example of a workgroup spanning an IPv4 router.

Bb726989.APC_XX08(en-us,TechNet.10).gif

Figure C-8 A workgroup spanning an IPv4 router

The only way to have the browse clients see all the servers in the workgroup on both sides of the router is to enable the forwarding of NetBIOS over TCP/IP broadcasts or to upgrade the workgroup to a domain. However, this solution is highly discouraged.

Multiple Workgroups Separated By IPv4 Routers

There is no support for a workgroup Master Browse Server to advertise itself beyond its own subnet. Domains can advertise themselves beyond their subnet with the special Domain[1B] NetBIOS name registered by the Domain Master Browse Server with WINS. There is no such mechanism for workgroups. The combination of the spanning and advertisement behavior of domains and the lack of these mechanisms in workgroups can produce some confusing results.

Figure C-9 shows an example configuration.

Bb726989.APC_XX09(en-us,TechNet.10).gif

Figure C-9 Multiple workgroups separated by an IPv4 router

CORP is a domain that spans Subnets 1 and 2. R&D_WG and MKTG_WG are both workgroups that exist on Subnets 1 and 2, respectively. Due to the collection and distribution processes between MB1 (the Master Browse Server for CORP on Subnet 1) and DC1 (the Domain Master Browse Server for CORP on Subnet 2), the browse list for browse clients in the CORP domain consists of:

  • The CORP domain and all the servers in the CORP domain (for simplification, only MB1 and DC1 are shown)

  • The R&D_WG workgroup with its Master Browse Server (RD1)

  • The MKTG_WG workgroup with its Master Browse Server (MK1)

However, for browse clients in the R&D_WG workgroup, the only items seen in the browse list are:

  • The R&D_WG workgroup and all the servers in the R&D_WG Workgroup (only the Master Browse Server RD1 is shown for simplification)

  • The CORP domain

The MKTG_WG workgroup does not and will not appear in the browse list for R&D_WG. This is due to the following:

  • Workgroup Announcements packets for the MKTG_WG workgroup are not forwarded across the IPv4 router.

  • There are no special NetBIOS names for the MKTG_WG workgroup that can be queried via WINS by the Master Browse Server for the R&D_WG workgroup.

  • There are no mechanisms for the Master Browse Server for the CORP domain (MB1) on Subnet 1 to forward its knowledge of the MKTG_WG workgroup to the Master Browse Server for R&D_WG.

  • When a browse client in the R&D_WG or MKTG_WG workgroups opens the CORP domain in the Microsoft Windows Network window, it only receives a list of servers in the CORP domain from MB1. MB1 does not send the browse client a list of other LAN groups known to MB1.

The result is known as the stranded workgroup problem. The existence of a workgroup is stranded to its subnet and to domains that span its subnet. Only workgroups on the subnet and domains that span the subnet will see the workgroup in its browse list. LAN groups on other subnets will never have the stranded workgroup in their browse lists. The only solution to the stranded workgroup problem is to enable the forwarding of NetBIOS over TCP/IP broadcasts on IP routers (highly discouraged) or to upgrade the workgroups to domains.

The problems associated with stranded workgroups across IPv4 routers are typically not an issue for large organizations that use domains to provide both the logical grouping of computers and the security and accounts infrastructure for authentication and access control.