The browser is a network resource enumeration tool. It maintains a list, called the browse list, of all the available servers, workgroups, and domains.
The Microsoft networking browser system consists of a master browser, backup browsers, and client computers. The master browser maintains the browse list and periodically sends copies to the backup browsers. When a browser client needs information, it obtains the current browse list by sending a NetServerEnum2 application programming interface (API) function call to either the master browser or a backup browser.
This service lets you track servers that are active on the network with a minimum of network overhead. It consists of two components on a Windows NT or Windows NT Advanced Server computer:
A network can contain the following types of servers related to browsing:
| Non-Browser Servers | Do not maintain browse lists, but announce themselves periodically to the Master Browser. |
| Potential Browser | Can become a Browser server if needed. |
| Backup Browser | Maintains a browse list of servers and domains that it retrieves from the Master Browser. |
| Master Browser | Receives server and Domain announcements, sends browse lists to Backup
Browsers, responds to clients requesting browse server lists, promotes
Potential Browsers to Backup when needed, and announces the domain to inform
the Master Browsers of other domains of the domain name and Master Browser
for that domain.
For a domain that spans more than one subnetwork, the master browser maintains the browse list for the portion of the domain on its subnetwork. The rest of the domain is known based on domain announcements made by the master domain browser. For example, when a user attempts to connect to any network resource using Network Neighborhood, the list of servers that appears is the browse list, and it is provided by a browser in the local computer's workgroup or domain. |
| Preferred Master Browser | Same as Backup Browser except that it is biased in elections through setting the IsDomainMasterBrowser to TRUE is the registry's browser parameters. |
| Domain Master Browser | The primary domain controller of a domain is given a special bias in browser elections so that it will become the Domain Master Browser. This allows browsing to be effective when a domain spans multiple subnets. It is responsible for replicating the browse lists amongst all Master Browsers within the domain. A directed datagram is used by Master Browsers on each subnet to announce itself to the Domain Master Browser. This is made possible through an entry in the LMHOSTS file on the Master Browsers for the Domain Controller. This makes it necessary to have a Windows NT Advanced Server computer to browse across wide area network (WAN) connections. |
On Microsoft networks using the IPX/SPX-compatible network protocol (NWLink), there is always only one master browser for each domain, because name queries are sent across routers automatically.
On networks using TCP/IP, where a domain spans more than one subnetwork, each subnetwork functions as an independent browsing entity, with its own master browser and backup browsers. Name-query datagrams do not cross routers. To browse across the wide-area network (WAN) to other subnetworks, at least one browser running Windows NT Server is required on the domain for each subnetwork. On the subnetwork where the PDC is placed, this Windows NT Server computer is the PDC, which always functions as the Domain Master Browser.
A Master Browser is elected on each subnet with Microsoft
networking computers present. It is listening for server announcements
from Windows NT-based, Windows for Workgroups-based, and Lan Manager-based
systems. It maintains lists of available resources that can be requested
by client computers.
Individual servers running Windows NT Server, Windows
NT Workstation, Windows 95, Windows for Workgroups, or LAN Manager announce
their presence by sending a directed datagram called a server announcement
to the domain or workgroup's master browser. This announcement includes
the server's NetBIOS name of \0x01\0x02_MSBROWSE_\0x02\0x01, domain\0x1d,
or domain\0x1e as appropriate for the type of server. When the master browser
receives a server announcement from a computer, it adds that computer to
the browse list.
Since each locally-elected Master Browser will only hear local membership announcements, there needs to be a mechanism to consolidate all of the members into a single list. This is the role of the Domain Master Browser. Periodically, all of the locally-elected Master Browsers contact the PDC sending a directed MasterBrowserAnnouncement datagram using the computer's NetBIOS domain\0x1d. The domain master browser then sends a remote NetServerEnum API call to each master browser to collect each subnetwork's membership lists. The PDC merges the list with the "master" list for the whole domain and replicates the master list back down. The replication algorithm is smart in that the local Master Browsers only replicate the members that they have learned about locally to the domain master. This whole mechanism allows members in a domain to span subnets and for all clients (eventually) to be able to get complete membership lists.
The master browser on each subnetwork can also send a remote NetServerEnum API call to the domain master browser to obtain the complete browse list for the domain. This complete browse list is thus available to browser clients on the subnetwork.Backup browsers call the master browser every 15 minutes to get the latest copy of the browse list, as well as a list of domains. Each backup browser caches these lists and returns the list of servers to any clients that send a remote NetServerEnum API call to the backup browser. If the backup browser cannot find the master browser, it forces an election.
The master browser also returns lists of backup browsers to computers running Windows NT Server, Windows NT Workstation, Windows 95, and Windows for Workgroups. When a computer starts that is configured to automatically become a browser if required, the current master browser must tell that computer whether to become a backup browser.
If its browse list is empty when a computer first becomes a master browser, it can force all servers to register with it by broadcasting a RequestAnnouncement datagram. All computers receiving this datagram must respond by sending a server announcement at a random time within the next 30 seconds. The randomized delay ensures that the network and the master browser itself are not overwhelmed with responses.
When a master browser receives a server announcement from another computer that claims to be the master browser, the receiving master browser demotes itself and forces an election. This ensures that there is always only one master browser in each domain or workgroup.
The list of servers that the master browser maintains is limited to 64K of data. So the number of computers that can be in the browse list for a single workgroup or domain is limited to 2,000 – 3,000 computers.
Microsoft networking workgroups cannot span multiple subnetworks. Any workgroup that spans subnetworks actually functions as two separate workgroups with identical names.
When a browse request is made from a client, a "GetBackupListRequest" is sent to the <domain>[1D] name (the Master Browser) that returns a list of browser servers for the local subnet. The "GetBackupListRequest" is also unicast to the Domain Master Browser, which handles the case in which the queried domain has no members on the subnet. The client browser service selects three of the browsers from the list and stores them for future use. Then when further browsing is done, (via the NetServerEnum API) one of the three saved names is contacted by the client.
When a client queries its workgroup or domain browser, it first gets back a list of all of the domains and workgroups that the browser has learned about through the \0x01\0x02__MSBROWSE__\0x02\0x01 name as well as the name of the master browser for each. When the user expands a domain or workgroup into a membership list, the client sends a request to <domain>[1D] to get to the list (this is translated to a local subnet broadcast by wins). If this fails, it contacts the master browser for the particular domain or workgroup and fetches the membership list.
5. Specifying a Browser Computer
Bajo la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters
hay dos entradas que definen el papel de un ordenador como Examinador(Browser)..
| No | This computer will never be a browser |
| Yes | This computer will become a browser. At startup, the server tries to
contact the master browser to get a current browse list. If the master
browser cannot be found, this computer forces a browser election, and can
become the master browser.
This is the default value for Windows NT Server computers |
| Auto | This computer is a potential browser. Whether it becomes a browser
depends on the number of existing browsers. This computer is notified by
the master browser if it should become a backup browser.
This is the default value for Windows NT Workstation computers |
On any computer with a value of Yes or Auto for the
MaintainServerList, Windows NT Setup configures the Browser service to
start automatically when the computer starts.
In a LAN environment using any protocol or combination of protocols, all Microsoft networking browsing activities are maintained using broadcasts and special NetBIOS names that identify the type of resource. All browsing services are provided on a per-protocol basis to prevent, for example, a NetBEUI-only client from enumerating a TCP/IP-only server in the process of querying the browser.
At the NetBIOS name space, all names are unique on the network. Resources are identified by the NetBIOS names, which are registered dynamically when the computer starts, a service starts, or a user logs on.
Tip for NetBIOS Scope ID: Microsoft networking allows
administrators to specify NetBIOS scope IDs to define special groups within
the network that can communicate only with each other. The NetBIOS scope
ID can be used for interoperation with other NetBIOS implementations that
use the NetBIOS scope ID. Before any packets that contain a NetBIOS name
are transmitted, the NetBIOS scope ID is appended to the name. This includes
packets such as name queries, name registrations, and session requests.
On the receiving end, the NetBIOS scope in a packet must match the locally
configured NetBIOS scope; otherwise, the packet is ignored. Therefore,
only computers that have the same scope can communicate with each other.
However, for most cases on most networks, the NetBIOS scope ID is null.
Server and Domain Names in the browse list are aged
and are removed from the browse list if they have not been heard from in
three Announce periods.
The Browser uses Mailslot Transactions to pass these
messages between systems. Two Mailslots are used:
Browser elections are conducted to determine the master browser of a subnet or workgroup. Browser elections are conducted when one of the following events occurs:
When a browser receives an election datagram, the receiving browser examines the datagram and first compares the election version with its own. If the receiving browser has a higher election version than any other browser, it wins the election regardless of the election criteria. If the election versions are identical for both computers, the election criteria are compared.
El criterio de elección se basa en calcular
una versión de elección que depende del sitema operativo
y el actual papel y su estado actual como Examinador en el dominio, según
los siguientes valores:
| Windows for Workgroups | 0x01000000 |
| Windows NT | 0x10000000 |
| Windows NT Advanced Server | 0x20000000 |
| PDC | 0x00000080 |
| WINS Client | 0x00000020 |
| Preferred Master Browser | 0x00000008 |
| Active Master Browser | 0x00000004 |
| MaintainServerList = Yes | 0x00000002 |
| Active Backup Browser | 0x00000001 |
The Browser will OR all of the appropriate election criteria and use this to determine the system's election criteria.
The criteria for determining if a Browser has won an election is the following:
The computer with the highest election criteria wins the browser election and becomes the master browser.
When a browser receives an election datagram indicating that it wins the election, the browser enters the running election state. In the running election state, the browser sends an election request after a delay based on the browser's current browser role:
9. Browsing Across Subnets w/ a Multihomed PDC in Windows NT 4.0
In Windows NT versions prior to 4.0, it was not possible to browse across subnets that were connected by a Windows NT Primary Domain Controller (PDC) server configured with TCP/IP routing and the Windows Internet Name Service (WINS). Windows NT 4.0 provides a new registry parameter that allows the computer browser service to be disabled on one or more network interfaces. When this registry parameter is added, it enables a multihomed domain master browser to provide a comprehensive browse list to computers on all subnets.
NOTE: When enabling this parameter, the assumption is made that all other TCP/IP connectivity (ping, net use, and so forth) are functioning correctly. This parameter only changes browser functionality, and will not fix client problems, such as incorrect default gateway, or server problems, such as incorrect IP addressing or routing problems.
Steps to enable this feature:
If you have more than 2 network adapters in the multihomed Windows NT server, enter each driver instance you wish to disable on a separate line in the String field. For example, if you need to disable the browser binding for an Intel EtherExpress Pro network adapter, the string would be NetBT_EPRO1. To determine the name of your driver for your network adapter, look in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services key for a name that corresponds with your network card.
NOTE: There will be at least two entries for each network adapter--use
the one that ends with a number. For example, when the Intel EtherExpress
Pro network adapter driver is installed, it adds EPRO and EPRO1 entries
in the Services registry key. The EPRO entry corresponds with the binding
and driver information for all EtherExpress Pro cards that are in the computer,
and the EPRO1 entry is for one specific instance of the driver, with specific
settings for one particular card. If a second EtherExpress Pro card were
added to the computer, an EPRO2 entry would be added to the registry and
would contain card-specific information (IRQ, I/O address, and so on).
10. Browsing Domain Master Browsers w/ Multiple NICs and Protocols
When a Domain Master Browser runs on multiple network
transport stacks, or uses multiple network adapters (multihomed), it maintains
a separate list of servers for each of its transport/network adapter pairs
(also known as an endpoints). When a client browses the Domain Master Browser,
it returns a list of only those servers associated with the endpoint the
request was received on.
A client requests a browse list for every transport
that is bound (and running) to the network adapter over which the client
is connected to the server.
Because the Domain Master Browser cannot determine
if the browsing client has access to servers on endpoints other than the
one it received the request on, it sends the client a list of only those
servers associated with that endpoint.
If you browse from the Domain Master Browser computer
(using File Manager or the NET VIEW command), you see a merged list of
all servers from all endpoints. This is because all of the servers in each
endpoint's list are reachable from the Domain Master Browser.
NWLink supports a virtual network and presents a single interface to
it's clients, performing internal routing if necessary. Therefore, there
is no endpoint pairing as there is with other protocols. Thus when an NWLink
client browses the Domain Master Browser over NwLnkIpx/Spx, the returned
list includes the servers from each network adapter that the Domain Master
Browser has NWLink bound to.
For example, assume "ServerOne" is a Domain Controller
acting as the Domain Master Browser. ServerOne has two network adapters
connected to segments A and B. ServerOne has both TCP/IP and NetBEUI bound
to the adapter connected to segment A and only TCP/IP bound to the adapter
connected to segment B.
A client workstation attached to segment A and running
only TCP/IP will receive only the browse list of servers associated with
the server's endpoint for TCP/IP on segment A.
A client workstation attached to segment A and running
both TCP/IP and NetBEUI will receive the list of servers associated with
both of the server's TCP/IP and NetBEUI endpoints on segment A.
Neither of the client workstations receive the list
of servers associated with the TCP/IP endpoint on segment B.
The Primary Domain Controller (PDC) of a WAN domain that spans subnets acts as a domain master browser server. Each subnet in that domain has its own master browser server, which sends master browser announcement requests to the domain master browser.
On receipt of a request from a server, the domain master browser replies with a remote NetServerEnum API, collects the servers from that master, then merges that list with its current list. This guarantees that the domain master browser server maintains a complete list of domain servers. When a client remotely sends a NetServerEnum API to the domain master browser server, the domain master returns to all servers in its browse list.
WAN browsing support is available only in a domain environment among Windows NT and Windows NT Advanced Server machines. If a domain contains at least one Windows NT Advanced Server machine, you can browse that domain. A subnet that has only Windows NT workstations running Browser services can browse the entire contents of that domain.
To guarantee that the master browser for each subnet can access the PDC, a domain's PDC must be listed in each client's LMHOSTS file. To guarantee that the PDC can request the local subnet's list from the subnet master browser, the TCP/IP transport must cache client addresses for some amount of time. In addition, lists of domains retrieved by the master browser have only the domains that are occupied by other master browser servers in that domain.
Windows NT or WFW workgroups cannot span multiple subnets. Workgroups can view only other workgroups on the local subnet.
Here are some conditions under which browsing does not work:
For example: Suppose domain A spans 3 subnets(S1,S2 and S3). PDC for domain A is on S1. S2 has a BDC for domain A. S3 has an NT machine that is a part of domain A. S3 also has a few machines that belong to domain B, the PDC for which is elsewhere.
Now, when the browse master of S3 (NT wksta) sends the list of servers in its local subnet to the PDC of domain A, it also sends a list of domains in its subnet that includes domain B. So PDC of domain A has a list of domains that has domain B listed in it. When browse master of S2 gets the browse list from PDC, it gets the list of domains as well, and that includes domain B. So it knows the existence of domain B. But for a client (on S2) to get the list of servers in domain B, it sends a request to its browse master on S2 and S2 in turn contacts the browse master of domain B on S3. For the browse master of S2 to contact the browse master of S3, its IP address has to be listed in its LMHOSTS file.
Now, if S3 does not have any machines in its subnet that belong to domain A, then S1 and S2 cannot browse domain B.
When a server fails, it stops announcing itself. When the master browser does not receive a server announcement for three of the server's current announcement periods, the master browser removes the non-browser from the browse list. It might take up to an additional 15 minutes for the backup browsers to retrieve the updated browse list from the master browser, so it could take as long as 51 minutes from the time a server fails to when it is removed from all browse lists.
Because a backup browser announces itself in the same way as a server, the procedure when a backup browser fails is the same as that for a server. If the name of this backup browser has been given to any clients, attempts made by those clients to contact this backup browser fail. The client then retries the NetServerEnum API call on another backup browser on the client's list of browsers. If all the backup browsers that a client knows have failed, the client attempts to get a new list of backup browsers from the master browser. If the client is unable to contact the master browser, it forces a browser election.
When a master browser fails, the backup browsers detect the failure within 15 minutes. After a master browser failure is detected, the first backup browser to detect the failure forces an election to select a new master browser. In addition, it is possible that between the time the master browser fails and the election of a new master browser happens, the domain will disappear from the list of domains in the browse list. If a client performs its first NetServerEnum API call after the old master browser has failed but before a backup browser detects the failure, the client forces an election. If a master browser fails and there are no backup browsers, browsing in the workgroup or domain will not function correctly.
When a domain master browser fails, other master browsers see only servers on the same local subnetwork. Eventually, all servers that are not on the local subnetwork are removed from the browse list.
BROWMON.EXE - Select from the Diagnostics Resource Kit menu. The master browser will then be displayed for each domain. Double clicking on a machine will then list the other machines that are browsers and a subsequent double click on these machines will tell their status, e.g. backup browser.
BROWSTAT.EXE - Start a command session. There are a number of commands that can be used: