Windows NT Browser v.4.0€¦ · Web viewWindows NT® Server. Server Operating System. Microsoft...

Windows NT® ServerServer Operating System

Microsoft Windows NT Browser

White PaperBy R. Dan Thompson IV and Randy McLaughlin

Abstract

This white paper provides information and procedures for implementing the Microsoft Windows NT Browser on Microsoft Windows NT® 4.0 operating system–based client workstations and servers.

®

© 1999 Microsoft Corporation. All rights reserved.The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.The BackOffice logo, Microsoft, Windows, and Windows NT are registered trademarks of Microsoft Corporation.Other product or company names mentioned herein may be the trademarks of their respective owners.Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA0599

INTRODUCTION....................................................................................1

MS BROWSING OVERVIEW...................................................................2Microsoft Network Browser System...................................................................2How Servers Manage Browsing for Microsoft Networking.................................2

Multiprotocol Considerations.........................................................................3Master Browser Elections..............................................................................3Role of Master Browsers...............................................................................5Role of Backup Browsers..............................................................................5Role of Domain Master Browsers..................................................................5Browser Failures with Microsoft Networking..................................................6

How Servers Announce Themselves in Microsoft Networks..............................7NetBIOS Special Names....................................................................................7Samples of NetBIOS Special Names.................................................................8How Clients Receive Browser Information.......................................................10

MICROSOFT TCP/IP AND NAME RESOLUTION.....................................12NetBIOS over TCP/IP.......................................................................................12

Computer Name and Host Name Resolution with NetBIOS over TCP/IP. .13WAN Browsing with WINS on an IP Network...................................................15

TROUBLESHOOTING BROWSING........................................................17

FOR MORE INFORMATION..................................................................21

APPENDIX A: BROWSING IN A SWITCHED ENVIRONMENT.................22

APPENDIX B: THE MULTIHOMED WINDOWS NT BROWSER...............23

APPENDIX C: WINDOWS NT PRINTER BROWSING..............................24

APPENDIX D: WINDOWS NT BROWSER COMPONENTS.......................26

APPENDIX E: WINDOWS NT BROWSER REGISTRY OPTIONS...............28

APPENDIX F: WINDOWS NT BROWSER ERROR CODES......................31

APPENDIX G: NETWORK LAYERS INVOLVED IN BROWSING...............36MAC Layer.......................................................................................................36Network Layer..................................................................................................36NetBIOS Layer.................................................................................................36SMB Layer.......................................................................................................36

APPENDIX H: WINDOWS NT BROWSER PROTOCOL FRAMES..............38Server Type Field.............................................................................................38

CONTENTS

Host Announcement Frame.............................................................................38Local Master Announcement Frame................................................................40Domain / Work Group Announcement Frame..................................................41Announcement Request Frame.......................................................................42Election Frame.................................................................................................42Become Backup Frame....................................................................................43Get Backup List Request Frame......................................................................43Get Backup List Response Frame...................................................................44Master Announcement Frame..........................................................................44Reset Browser State Frame.............................................................................44

Maintaining an accurate and efficient browse list on the network is important topic for Microsoft customers. This technical paper provides up-to-date information on Microsoft network browser architecture and reference material for advanced troubleshooting of browsing issues.

The browse list can be accurately maintained in any environment if the browser architecture, capabilities, and the way in which the network topology affects the browser’s ability to gather information on the network are taken into consideration.

Understanding the operation of the browser services available on Microsoft operating systems is critical in effective troubleshooting. For example, the browser service relies on broadcasts when gathering information locally and needs the services of WINS or other name-resolution methods to pass a browse list to remote networks. The details of this process and the methods used are presented in this paper.

This paper should dispel some common misunderstandings about the browse list. The presence or lack of a computer name in the browse list does not give a clear indication of the computer’s status on the network. A delay in gathering a browse list may occur due to various circumstances; however, a system can typically be contacted directly even though it cannot be found in Network Neighborhood. A system missing from the browse list should not be a cause for immediate concern, unless the system is consistently missing.

Although the primary focus of this paper is to give network administrators an understanding of browser architecture, it also deals with troubleshooting situations where the browse list is inaccurate or unavailable.

Microsoft Network Browser SystemThe browser is a network resource enumeration tool first created for LAN Manager 1.0. Windows for Workgroups enhanced the browser to make it truly client/server, and finally it was enhanced for domain browsing on a Windows NT® operating system–based network. The Microsoft networking browser maintains a list called the browse list. The browse list is an enumeration of all the available servers, workgroups, and domains (for Windows NT and LAN Manager networks). 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. The browse list is provided by a browser in the local computer’s workgroup or domain.

The Microsoft networking browser system consists of a domain master browser, master browsers, backup browsers, and client computers. The domain master browser maintains the complete domain browse list. The master browsers periodically query the domain master browser to obtain a complete list of domain resources. 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 call to either the master

Microsoft Windows NT Server White Paper

1

INTRODUCTIONMS BROWSING OVERVIEW

browser or a backup browser.

NetServerEnum2 returns information about the server type (SV_TYPE_SERVER) entries in a domain or workgroup. It allows client computers to view a specific set of servers in the workgroup or domain. NetServerEnum2 provides a server type mask that allows users to query for various types of servers, such as workstations, servers, time servers, domain controllers, and so on. Printer browsing and Windows Terminal Server clients rely on this type of browsing to enumerate their respective resources

This centralized browser architecture for Windows networking resources reduces the number of broadcast datagrams on the network. A datagram is a network packet that is sent to a mailslot on a specified computer (a directed datagram) or to a mailslot on any number of computers (a broadcast datagram). The centralized browser architecture also reduces the demands on the client computer’s CPU and memory.

Note: For Microsoft networking using the Microsoft TCP/IP protocol, broadcast name resolution is a direct implementation of Request for Comments (RFCs) 1001 and 1002 (NetBIOS Service Protocols). This implementation of NetBIOS over TCP/IP is wholly compliant with the RFCs, and does not involve any method of what has been referred to as NetBEUI encapsulation. For more information about NetBIOS over TCP/IP (NetBT), see the discussion of name resolution for Windows-based networking in Windows NT Server Networking Guide.

How Servers Manage Browsing for Microsoft NetworkingIn a Windows NT domain, every Windows NT Server–based computer is a browser. The primary domain controller (PDC), if there is one, is the domain master browser, and the other computers running Windows NT Server, Windows NT Workstation, or the Windows® 95 operating system are backup browsers. If there is more than one Windows NT Server–based computer in the domain, no computer running Windows NT Workstation or Windows 95 should ever be a master browser in the domain. In a workgroup containing computers running Windows 95 and Windows NT Workstation, there is always one master browser. If there are at least two Windows 95- or Windows NT Workstation–based computers in the workgroup, there is also one backup browser. For every 32 computers running Windows 95 and Windows NT Workstation in the workgroup, there is another backup browser. The following section describes how computers become browsers and summarizes the roles played by master and backup browsers.

Multiprotocol ConsiderationsThe browser maintains all of its server information on a per-transport basis. A transport is the physical network card bound to a protocol. When a client application issues a NetServerEnum call, the code running on the workstation enumerates all the serviced networks and forwards the NetServerEnum call to a browser server for that particular transport. When a browser server receives the request, it returns only those servers on the same network from which it received the transaction

Microsoft Windows NT Server White Paper 2

originally. Therefore, browsing occurs on each transport independently, regardless of other available transports.

Master Browser ElectionsEach computer running Windows 95, Windows for Workgroups, Windows NT Workstation, or Windows NT Server has configuration settings that determine whether that computer can become a browser. For servers running Windows NT, the value for MaintainServerList for the browser service determines its possible role as a browser. By default, servers are configured to have the potential to become browsers. Unless the server is specifically configured to never be a browser, the Microsoft networking browser service starts automatically when the computer starts, and the server announces itself on the networking using the special NetBIOS name <DOMAIN><1e>.

A master browser election always occurs in the following circumstances:

When a computer cannot find its master browser at system startup When a computer determines that a master browser has disappeared When a computer running Windows NT Server starts (that is, a preferred

master browser is started)

When any server needs to force a master browser election, it notifies the other browsers on the system by broadcasting an election datagram that contains the sending browser’s election version and election criteria. The election datagram and subsequent communications are sent to the NetBIOS name <DOMAIN><1e>.

The election version is a constant value that identifies the version of the browser election protocol. If the election versions are identical for both computers, the election criteria are compared. The election criteria consist of a 4-byte hexadecimal value. Specific groups of bytes are masked and their values set according to the following table:

Election Criterion ValueOperating system type 0xFF000000

Windows NT Server 0x20000000

Windows NT Workstation 0x10000000

Windows 95 0x01000000

Windows for Workgroups 0x01000000

Election version 0x00FFFF00

Per-version criterion 0x000000FF

Primary domain controller 0x00000080

WINS client 0x00000020

Preferred master browser 0x00000008

Running master browser 0x00000004

MaintainServerList or BrowseMaster = yes 0x00000002

Running backup browser 0x00000001

When a browser receives an election datagram, the receiving browser compares the election version in the datagram with its own. If the receiving browser has a


3

higher election version than any other browser, it is elected, regardless of any other election criteria. For example, a computer running any version of Windows NT is always elected over a computer running Windows 95. If the election versions are identical, the receiving browser compares the election criteria as follows:

If the receiving browser has a higher election criterion than the sending browser, the receiving browser issues its own election datagram and enters the election in progress state.

If the receiving browser does not have a higher election criterion than the sending browser, the receiving browser attempts to determine which computer is the new master browser.

If there is still a tie, the browser that has been running longest is elected. If there is still a tie, the browser that has a lexically lower name is elected. For example, when all other criteria are equal, a server named A1 is elected over a server named B1.

When a browser receives an election datagram indicating that it is elected, 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:

200 ms delay for master browsers 400 ms delay for backup browsers 800 ms delay for all other browsers

The browser broadcasts up to four election datagrams. If, after four election datagrams, no other browser with an election criterion that would win the election has responded, the browser becomes the master browser. If the browser receives an election datagram indicating that another system would be elected, the browser demotes itself to backup browser. To avoid unnecessary network traffic, a browser that has lost an election does not broadcast any unsent election datagrams.

Role of Master BrowsersThe master browser maintains the browse list, which is the list of all servers in the master browser’s domain or workgroup, plus the list of all domains on the network. For a domain that spans more than one subnetwork or broadcast collision zone (Like a V-LAN), the master browser maintains the browse list for the portion of the domain on its subnetwork or broadcast collision zone. The rest of the domain is known based on domain announcements made by the domain master browser. 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 (HostAnnouncement) datagram to the domain or workgroup’s master browser. This announcement includes the server’s NetBIOS name of <01><02>MSBROWSE<02><01>, <DOMAIN><1d>, or <DOMAIN><1e>, 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. The master browser then 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 an announce request (AnnouncementRequest) 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 as described in the previous section. This ensures that there is always only one master browser in each domain or workgroup.

Role of Backup BrowsersBackup 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 call to the backup browser. If the backup browser cannot find the master browser, it forces an election.

Role of Domain Master BrowsersThe browser service running on a domain’s primary domain controller (PDC) has the special additional role of being the domain master browser. The PDC of a domain has a bias in browser elections to ensure that it becomes the master browser. 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 should not cross routers. When routers or switches are misconfigured and propagate UDP port 137 and 138 broadcasts, large numbers of event 8003 appear in the event log. For more information, see the following Knowledge Base articles: Q135464 - 8003 Browsing Errors with UDP Forwarding and

Q190930 - UDP Broadcast Forwarding by Cisco's IP Helper.

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 located, this Windows NT Server–based computer is usually the PDC, which functions as the domain master browser. When a domain spans multiple subnetworks, the master browser for each subnetwork announces itself as the master browser to the domain master browser by sending a directed MasterAnnouncement datagram, using the computer’s NetBIOS <DOMAIN><1d>. The domain master browser then sends a remote NetServerEnum call to each master browser to collect each subnetwork’s list of servers. The domain master browser merges the server list from each subnetwork master browser with its own server list to form the browse list for the domain. This process is repeated every 15 minutes to ensure that the domain master browser


5

http://support.microsoft.com/support/kb/articles/q190/9/30.asp

http://support.microsoft.com/support/kb/articles/Q135/4/64.asp

has a complete browse list of all the servers in the domain.

The master browser on each subnetwork also sends a remote NetServerEnum 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.

Note: Microsoft networking workgroups cannot span multiple subnetworks. Any workgroup that spans subnetworks actually functions as two separate workgroups with identical names. To span multiple collision zones, a Windows NT domain must exist.

Browser Failures with Microsoft NetworkingA failed server 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 that server 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 the time 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 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. The client then returns an error to the application, indicating that the master browser could not be found.

When a master browser fails, the backup browsers detect the failure within 15 minutes. The first backup browser to detect the failure forces an election to select a new master browser. Between the time that the master browser fails and the time that a new master browser is elected, the domain could disappear from the list of domains in the browse list. If a client performs its first NetServerEnum 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 does not work correctly.

When a domain master browser fails, other master browsers see only servers on their own local subnetwork. Eventually, all servers that are not on the local subnetwork are removed from the browse list.

How Servers Announce Themselves in Microsoft NetworksWhen a server is started, it announces itself by sending a host announcement to the master browser every minute. This announcement uses the special NetBIOS name of <DOMAIN><1d>. As the computer continues running, the time between server announcements is increased until it eventually becomes once every 12 minutes. If the master browser has not received a server announcement from a computer for


three announcement periods, the computer is removed from the browse list. Therefore, there might be up to a 36-minute delay between the time that a server goes down and the time that it is removed from the browse list. Client computers sometimes need to retrieve lists of domains, as well as lists of servers in those domains. To support this, when a browser becomes a master browser, it broadcasts a DomainAnnouncement datagram every minute for the first five minutes, and then broadcasts once every 15 minutes after that. Master browsers in domains and workgroups announce their presence to the special NetBIOS name of <01><02>MSBROWSE<02><01> and register their names with this group. Master browsers on other domains receive these DomainAnnouncement datagrams and add the specified domain to the browse list.

DomainAnnouncement datagrams contain the name of the domain, the name of the domain master browser, and whether the master browser is running Windows NT Server, Windows NT Workstation, or Windows 95. If the master browser is running Windows NT Server, the datagram also specifies whether that browser is the domain’s PDC. If a domain has not announced itself for three consecutive announcement periods, the domain is removed from the browse list. Therefore, a domain might be down for as long as 45 minutes before it is removed from the browse list. When a master browser is shut down correctly, it sends a ForceElection broadcast so that a new master browser can be elected. When a backup browser is shut down correctly, it sends an announcement to the master browser that it is shutting down. To do this, it sends a server announcement that does not include the browser service in the list of running services.

NetBIOS Special NamesIn a LAN environment using any protocol or combination of protocols, all Microsoft network 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. The NetBIOS name space is not hierarchical, so all names must be unique on the network. Resources are identified by NetBIOS names, which are registered dynamically when the computer starts, a service starts, or a user logs on. The special NetBIOS names used in Microsoft networking are indicated by adding a hexadecimal value as a sixteenth byte at the end of the 15-character computer name or domain name. If the computer or domain name is less than 15 characters, spaces are used to pad the name to the sixteenth byte. The discussion of browsing in this paper uses the special NetBIOS names to explain how names are registered and resolved for browsing on Microsoft networks. The following table shows some of these special names:

Samples of NetBIOS Special NamesSpecial Name Description


7

Registered unique user name:

<USERNAME><03> Used to register the name of the user currently

logged on in the WINS database so that users can

receive net send commands sent to their user

names

Registered unique computer names:

<COMPUTER><00> Used by Microsoft networking workstations to

receive second-class mailslot requests. All

workstations must add this name to receive mailslot

requests. This is the computer name registered for

workstation services by a WINS client.

<COMPUTER><03> Used as the computer name that is registered for

the messenger service on a computer that is a

WINS client.

<COMPUTER><20> Used as the name that is registered for the server

service on a Windows NT–based computer that is a

WINS client.

<COMPUTER><Be> Used as the unique name that is registered when

the Network Monitor agent is started on the

computer.

<COMPUTER><Bf> Used as the group name that is registered when the

Network Monitor agent is started on the computer. If

this name is not 15 characters in length, it is padded

with plus (+) symbols

<COMPUTER><1f> Used as the unique name that is registered for

network dynamic data exchange (DDE) when the

NetDDE service is started on the computer.

Registered group names:

<01><02>MSBROWSE<02><01> Used by master browser servers to periodically

announce their domain on a local subnet. This

announcement contains the domain name and the

name of the master browser server for the domain.

In addition, master browser servers receive the

domain announcements sent to this name and

maintain them in their internal browse list along with

the announcer’s computer name.

<DOMAIN><00> Used by workstations and servers to process server

announcements to support Microsoft LAN Manager.

Servers running Windows 95, Windows NT,

Windows NT Server, and Windows for Workgroups


do not broadcast this name unless the LMAnnounce

option is enabled in the server’s properties.

<DOMAIN><1b> Used to identify the domain master browser name,

which is a unique name that only the primary

domain controller (PDC) can add. The PDC

processes GetBrowserServerList requests on this

name. WINS assumes that the computer that

registers a domain name with the <1b>character is

the PDC. The 1B entry is resolved to when

NetGetDcName is called.

<DOMAIN><1c> Used for the internet group name, which the domain

controllers register. The internet group name is a

dynamic list of up to 25 computers that have

registered the name. This is the name used to find a

Windows NT domain controller for pass-through

authentication. The 1C entry is resolved to when

NetGetAnyDcName is called.

<DOMAIN><1d> Used to identify a segment master browser (not a

domain master browser). The master browser adds

this name as a unique NetBIOS name when it

starts. Workstations announce their presence to this

name so that master browsers can build their

browse list.

<DOMAIN><1e> Used for all domain-wide announcements by

browser servers in a Windows NT–based server

domain. This name is added by all browser servers

and potential servers in the workgroup or domain. All

browser election packets are sent to this name.

The following example shows a sample NetBIOS name table for a Windows NT 4.0 primary domain controller (PDC), based on the list that appears if you type nbtstat -n at the command prompt. This example shows the sixteenth byte for special names, plus the type of NetBIOS name (unique or group).

Node IpAddress: [157.56.60.111] Scope Id: [] NetBIOS Remote Cache Name Table Name Type Status---------------------------------------------DOMAINPDC <00> UNIQUE RegisteredDOMAINPDC <20> UNIQUE RegisteredDOMAINNAME <00> GROUP RegisteredDOMAINNAME <1C> GROUP RegisteredDOMAINNAME <1E> GROUP RegisteredDOMAINPDC <03> UNIQUE RegisteredDOMAINPDC <1B> UNIQUE RegisteredDOMAINPDC <1D> UNIQUE Registered..__MSBROWSE__.<01> GROUP Registered

In this example, several special names are identified for the Windows NT Primary


9

Domain Controller (DOMAINPDC in the previous example) and the domain (DOMAINNAME), including the following:

computer\0x00 (shown as <00> in the example) indicates the computer name associated with the Workstation service.

computer\0x20 (shown as <20> in the example) indicates the computer name associated with the Server service.

domain\0x00 indicates the domain to which this computer belongs. domain\0x1c indicates that the computer is a domain controller. domain\0x1e indicates that this computer can serve as a backup browser in this

domain. computer\0x03 indicates the computer name associated with the Messenger

service. computer\0x1b indicates that this computer is the domain master browser. computer\0x1d indicates that this computer is the segment master browser. ..__MSBROWSE__.\0x01 indicates that this computer is the segment master

browser.

How Clients Receive Browser InformationWhen an application running on a client computer makes a NetServerEnum call, the client sends the call to a browser. If this is the first time this call has been made by an application on this client, the client must first determine which computers are the browsers in its workgroup or domain. This datagram is in the form of a Get Backup List Request datagram sent to the special NetBIOS <DOMAIN><1d> name that the master browser has registered. This request is processed by the master browser for the client’s domain and subnetwork. The master browser then returns a list of browsers active in the workgroup or domain being queried, via the Get Backup List Response datagram. The client selects the names of three browsers from the list, and then stores these names for future use. The client computer randomly chooses a browser from one of the three browser names and calls NetServerEnum, requesting a list of servers or domains. The browser server returns the list to the client, which then can be displayed in Network Neighborhood.

If the user selects a domain name in the browse list, a new set of browser servers must be found for the new domain. In this case, a Get Backup List Request frame is sent to the new domain name. After a user selects a server, the browser is no longer involved in the process of contacting the server for a list of available resources. The transport protocols on the client computer use whatever name resolution methods are available to find and connect to the server. When the client workstation attempts to connect to a server, a NetBIOS session is established between the two computer names. For example, when a Windows NT–based client workstation on an IP network connects to a Windows NT Server, the following occurs:

The NetBIOS name for the server is resolved to an IP address. A TCP connection is established from the client to the server. The client sends a NetBIOS session request to the server name over the TCP


connection. The server responds affirmatively, and the session is established. The client and server negotiate a higher-level protocol to use over the NetBIOS

session.

Only one NetBIOS session at a time is established between two computers. Additional connections for file or printer sharing are multiplexed over the same NetBIOS session.

All computers are on the same wire in the LAN environment, so a user can browse all workgroups and domains because the network client can communicate directly with all master browsers. Multiple workgroups and domains can coexist on a LAN without incident because both the unique and group NetBIOS names depend on the name of the workgroup or domain. Name resolution becomes more complex in the WAN IP environment, however, because the broadcasts and messages used for name resolution are not forwarded across routers automatically on TCP/IP networks. This section summarizes name resolution issues related to WAN browsing, depending on whether Windows NT–based WINS servers are available in the enterprise.

NetBIOS over TCP/IPMicrosoft TCP/IP uses NetBIOS over TCP/IP, as specified in RFC 1001 and RFC 1002, which define a software interface that supports name resolution for NetBIOS client and server programs in the WAN environment. All Microsoft networking products use NetBIOS over TCP/IP for registering and locating NetBIOS resources on IP networks. The various methods used for name resolution include the following:

NetBIOS name cache NetBIOS name servers (implemented as WINS for Windows NT networks) IP subnet broadcasts Static LMHOSTS files Static HOSTS files DNS servers

The order of methods use for NetBIOS name resolution depends on the node type (as defined in RFC 1001/1002) and the particular computer configuration for TCP/IP. The following are the node types:

B-node, which uses broadcasts to resolve names P-node, which uses point-to-point communications with a NetBIOS name

server to resolve names M-node, which uses broadcasts first (b-node), and then name queries (p-node)

if broadcasts are not successful H-node, which uses name queries first (p-node), and then broadcasts (b-node)


11

MICROSOFT TCP/IP AND NAME RESOLUTION

http://www.faqs.org/rfcs/rfc1002.html



ftp://ftp.microsoft.com/bussys/winnt/winnt-docs/papers/TCPIPIMP2.doc

ftp://ftp.microsoft.com/bussys/winnt/winnt-docs/papers/TCPIPIMP2.doc

if the name server is unavailable or if the name is not registered in the WINS database

If WINS is enabled on a Windows 95 computer, the system uses h-node by default. Without WINS, the system uses b-node by default. To see which node type is configured on a Windows NT–based computer, check the value for NodeType in the following registry key:

Hkey_Local_Machine\System\CurrentControlSet\Services\NetBT\Parameters\NodeTypeValue Type: REG_DWORD - NumberValid Range: 1,2,4,8 (b-node, p-node, m-node, h-node)Default: 1 or 8 based on the WINS server configuration

For more information, see the following Knowledge Base article:Q160177: Default Node Type For Microsoft Clients ID.

Computer Name and Host Name Resolution with NetBIOS over TCP/IPThe following diagrams summarize the methods for attempting name resolution with TCP/IP.



H -node

F ind node type ST ART

P-nodeN o M -nodeN o B-nodeN o

N etBIO S nam e cache N etBIO S nam e cache N etB IO S na m e cache N etBIO S na m e cache

Ye s Ye s Ye s Yes

Success Su ccess Success Su ccess

IP A ddress R eturned

YesYe s Ye s Ye s

IP Address R eturned

Q uery a W IN S serve r Q uery a W IN S server Local broadcast fo rreso lu tion

Loca l b roadcast fo rreso lutio n

N o N o N o N o

Success Success Su ccess

Loca l b roadcast fo rreso lution Q uery a W IN S server

N o

Success

N o

Su ccess

N o

Success

N o

N o

N o


Ye s Ye s


Yes

IP A ddress R eturned

Ye s Yes

Ye s

C heck LM H O S TS file

SuccessIP Address R eturned Ye s N o 1


13

WAN Browsing with WINS on an IP NetworkWINS solves two problems for browsing in the WAN: the building of a comprehensive domain list and name resolution for members within a domain or workgroup. The following list summarizes issues for browsing in a WAN environment with WINS:

Workgroups still cannot span subnetworks because they have no equivalent to the domain master browser.

The process of building domain lists uses the WINS database and domain\0x1b names to locate the domain master browser. Workgroup lists are still based on members’ announcing their presence periodically. For example, an isolated workgroup on an island subnet with no domain members is invisible to the WAN until a domain member is added that shares the presence of the subnet.

The ability to expand a workgroup or domain depends on the ability to resolve the master browser’s computer name. If WINS-enabled computers are running in workgroups and domains, this is adequate.

The ability to connect to a resource in a workgroup depends on the ability to resolve the resource’s name. Again, WINS-enabled computers support this adequately. It is possible to connect to a resource that you cannot browse and to browse a resource that you cannot connect to.

Tip for browsing with WINS Because of how PDCs register the domain\0x1b entry with WINS, ensure that all clients and servers are members of a domain.

The unique NetBIOS name of domain\0x1b that the PDCs register is treated


specially by WINS and is used to build a table of all domains on a WAN network. The browser on the client periodically connects to WINS and learns of all the systems that registered the domain\0x1b name. The browser then uses a NetGetDCName call on each of the domain\0x1b names, followed by an attempt on the domain\0x1c names. The browser then adds the domain master browser’s name to its domain and workgroup list. This eliminates the need to strategically place workgroup or domain members on subnets to ensure that comprehensive domain and workgroup lists are built. With WINS, the domain\0x1e name registration is ignored and treated as a normal group name. This forces browser elections to remain on subnetworks, rather than extending elections to the WAN. This increases fault tolerance and reduces periodic network-wide traffic. The same is true for the domain\0x1d and <01><02>MSBROWSE<02><01> group names. This also reduces the scope of the announcement broadcasts on the subnetwork. The unique domain\0x1b name and the internet group domain\0x1c name are maintained by WINS and are used during logon and for NetGetAnyDCName calls.

While there is no centralized method to determine if the browse lists across the WAN are complete, there are techniques to determine if the servers on a particular segment are represented in the browse list on a remote segment. These techniques can be applied on all segments throughout the WAN, but the results of these tests can vary due to the roles of the servers changing when browser elections occur. Only if all the servers in a domain throughout the WAN are completely static and no servers come on or off-line, do the results of these tests have meaning over time. The tests described in this section rely on the Windows NT Resource Kit utility Browstat.exe. Example output is for the TCP/IP protocol only. Also, as with most network problem diagnosis, to troubleshoot the browser service the administrator must have full knowledge of the network segment boundaries, switches, and router configurations on the network. For example, if a client on a remote segment does not have a server in its browse list that is located on another segment, it is not advisable start troubleshooting until after the 48-minute cycle described above has passed. Remember that name resolution between all browsers is critical, and it is most important to establish a robust name resolution infrastructure with WINS. For browsing to work, name resolution must be functional.

The following are the steps to take in troubleshooting on the network.

1) Find the master browser on the segment where the server resides.

The following command must be executed on the segment where the missing server resides:


15

TROUBLESHOOTING BROWSING

BROWSTAT STATUSStatus for domain <DomainName> on transport \Device\NetBT_IEEPRO1 Browsing is active on domain. Master browser name is: <MasterBrowser> Master browser is running build 1381 1 backup servers retrieved from master <BackupBrowser> \\SmallerServer There are 100 servers in domain DomainName on transport \Device\NetBT_IEEPRO1 There are 1500 domains in domain DomainName on transport \Device\NetBT_IEEPRO1

This should tell you which server is acting as the master browser on the segment. If the local master browser is slow to respond, you may have received this information from another master browser.

The results of this command gives you the “\Device\Protocol_NIC” string and can be used with other Browstat commands.

To find the local master browser on the client’s segment, execute the following:

BROWSTAT GETMASTER \Device\NetBT_El59x1 <DomainName>

Using the Status or Getmaster switch issues a DomainName<1d> query and returns the current master browser for that segment.

Now you must determine which master browser is on the segment that contains the missing server’s name. If a master browser cannot be found, you can force an election by stopping and starting the browser service on a domain controller that is on the server’s segment. In a few minutes, re-run this test. Alternatively, on the console of a server on the server’s segment you can force an election by executing the following command:

BROWSTAT ELECT \Device\NetBT_IEEPRO1 <DomainName>.

2) Does the master browser have the server’s name in its list?

The master browser is the first server in the chain of communication that must contain the missing server’s name. This test determines if the master browser has received the server’s Host Announcement frame. Note that the “\device…” string is obtained from the output above. Execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\<MasterBrowser> | FINDSTR /i <MissingServer>

If the master browser has the server in its list, the command returns something similar to the following:

\\<MissingServer> NT 04.00 (W,S,NT,PBR,DFS)

If the local master browser does not have the server’s name, the following can be executed from any computer on the missing server’s segment:

BROWSTAT FORCEANNOUNCE \Device\NetBT_El59x1 <DomainName>

Or the following can be executed from the missing server’s console:

BROWSTAT ANNOUNCE \Device\NetBT_El59x1 <DomainName>

It may be useful to verify that the missing server can map a network drive to the


master browser to verify network connectivity. Also, the server can be rebooted to force a Host Announcement frame.

3) Does the PDC receive the server’s name from the master browser?

Execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\<PDC> | FINDSTR /i <MissingServer>

The output should be similar to the following:


If the server’s name is missing, this is probably due to name resolution problems. For the PDC to obtain the list of servers from the master browser, the server’s master browser must be able to resolve the DomainName<1b> name so that it can send the directed Master Announcement frame, using UDP port 138. For the PDC to respond to this announcement to obtain the server’s name, it must be able to resolve the master browser’s computer name. (For the server’s master browser to obtain the domain-wide list from the PDC, it too must be able to resolve the PDC’s computer name.) Name resolution in both directions is critical. To verify that the server’s master browser can resolve the DomainName<1b> entry, execute the following:

BROWSTAT GETPDC \Device\NetBT_El59x1 <DomainName>

To verify that both the PDC and the master browser can resolve each other’s computer names, map a network drive from the master browser to the PDC and from the PDC to the master browser. If any of these steps fail, resolve the name resolution problem.

4) Which is the master browser on the client’s segment?

This is done using the same steps as in number 1 above, but is executed on the client’s segment.

5) Does the master browser have the missing server’s name?

Execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\<MBClientSeg> | FINDSTR /i <MissingServer>

If the server has the entry, the output should be similar to the following:


If the master browser does not have the missing server’s name, it is probably due to a name resolution problem. Verify that the master browser on the client’s segment is able to resolve the DomainName<1b> name by executing the following:

BROWSTAT GETPDC \Device\NetBT_El59x1 <DomainName>

The master browser must be able to resolve the computer name of the PDC. To verify this, map a network drive to the PDC. If either of these tests fail, resolve the name resolution problem.


17

6) Which are the backup browsers on the client’s segment?

To reduce demands on the segment master browser, when a client requests a browse list, it chooses a backup browser, if one is available. Therefore, it is more likely that all clients will use backup browsers. There are two ways to determine the local backup browsers for this segment. From the master browser’s console, execute the following:

BROWSTAT LOCALLIST \Device\NetBT_IEEPRO1 | FINDSTR /i BBR

This returns a list of entries similar to the following:

\\<BackupBrowser> NT 04.00 (W,S,BDC,NT,BBR,DFS)

To have the master browser perform this command remotely, execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\<MasterBrowser> 0X40000000 | FINDSTR /I BBR

Note: These flags are defined in Appendix H.

7) Do the backup browsers have the missing server’s name?

For all clients on this segment to retrieve a reliable browse list, every backup browser must be checked for the missing server’s name. For each backup browser, execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\<BackupBrowser> | FINDSTR /i <MissingServer>

If a backup browser does not contain the missing server’s name, verify that the backup browser can map a network drive to the master browser. The backup browser role is the most dynamic browser role. Master browsers instruct potential browsers to become backup browsers, depending on the browser load.

8) Other considerations:

To avoid experiencing intermittent browser functioning and having to perform these tests, you may need to dedicate computers on each segment to maintain a consistent domain-wide list. If servers are frequently shut down and restarted, consider placing a BDC if the number of segments is not large, or at minimum a Windows NT Member Server on each segment with the IsDomainMaster registry setting set to true. This gives the server an edge during elections in becoming the master browser for the segment.

For all the previous steps, if none of the suggestions allow you to proceed to the next step, verify that none of the browser servers that you have identified have a “name in conflict” error. This can be seen by executing the following:

NBTSTAT –n

This command can be performed remotely by using either the –A or –a switch.

The browser is very sensitive to the configuration of the routers throughout the WAN. Since the browser roles are determined by broadcast elections, UDP broadcasts must not be forwarded. Unpredictable behavior can occur if UDP


broadcast traffic is forwarded in one direction but not the other. This may generate 8003 Browser events, causing a continuous cycle of elections.

Additionally you can resolve problems with a protocol analyzer such as the Microsoft Network Monitor. To view the browser exchanges directly, the browser service can be stopped, and then restarted. Unfortunately, there is no guarantee that a browser will assume the same role that it had before stopping and starting the browser service. However, this method can be especially useful to verify the communication when the master browser requests the domain-wide list from the PDC, and immediately following when the PDC requests the local list from the master browser. After the browser service has started on the master browser, the full exchange should take place within one or two minutes. Configure the protocol analyzer’s capture buffer and frame size settings to allow for this quantity of traffic. The list of servers returned by the browse service prior to Windows NT 4.0 was limited to 64 KB in size. When this size is exceeded, the user sees a truncated alphabetical list of servers. To avoid this behavior, all browsers must be running Windows NT version 4.0 or later.

For the latest information on Windows NT Server, visit our World Wide Web site at http://www.microsoft.com/ntserver and the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).

Throughout this discussion of the Windows NT Browser, browsing has been discussed in terms of a routed LAN environment. This section covers how LAN switching affects the browser service.

LAN switching is a technology that replaces hubs and shared media with a switch. A switch is a device that operates at layer 2 and/or layer 3 of the OSI model, building dedicated segments between two computers, thus eliminating the congestion associated with shared media. The net effect of switches is increased bandwidth to the desktop. LAN switching builds upon the concept of microsegmentation, or the ability to provide a dedicated segment to the desktop. Each port on the switch provides that dedicated segment. Switches working at layer 2 of the OSI model have the ability to build tables that associate a specific port with MAC addresses, which then allows packets to be forwarded directly to the appropriate port.

A connection can be dynamically generated between two ports on the same switch or directly from a specific port to the default gateway. Switches can have multiple data streams passing through them simultaneously. However, when a switch receives a broadcast or multicast packet, the switch must flood all of the ports except the originating port. This is a technique known as broadcast flooding. Under this circumstance the switch is operating like a simple bridge, and a network that is built only on switch technology appears flat. A flat network is a network that is comprised of only one broadcast collision domain. A network that is reduced to one


19

FOR MORE INFORMATIONAPPENDIX A:BROWSING IN A SWITCHED ENVIRONMENT

collision domain is susceptible to broadcast storms and does not scale well.

Modern switches support VLANs as a mechanism to administer and scale switched networks. The VLAN in its simplest form is a grouping or collection of specified ports that form a single collision domain. Advanced VLAN configurations can be defined on a per-protocol basis or even by a user-defined specification. VLANs provide a great amount of flexibility in designing collision domains.

Browsing in a switched environment follows the same principles that were established in the previous sections of this paper. Additionally, you should consider the impact of VLAN design on the collision domains. Do the VLANs map to the IP subnets or not? The same steps that were discussed in the troubleshooting browsing section still apply, but they must be extended to include the VLANs as collision domains. You can no longer just consider physical segments as collision domains; a VLAN may be the new broadcast boundary.

For the PDC to build a single domain-wide list, it cannot be a multihomed server. Each master browser on remote segments establishes a connection to the PDC. Since there is no guarantee that every master browser will choose the same interface on the PDC, the PDC must be single-homed so that a single domain-wide list can be built. Also, all master browsers must also be single-homed. Every 12 minutes, the master browser connects to the PDC and requests the domain-wide list. The master browser then issues a Master Announcement Browser frame to the PDC, telling it to connect to the master browser and obtain its local lists. Since the PDC does not maintain separate IP addresses for each interface on the master browser, when the PDC connects to the master browser, it obtains only the list of computers and servers collected on that particular interface.

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 the UnboundBindings registry parameter is added, it enables a multihomed domain master browser to provide a comprehensive browse list to computers on all subnets.

For more information, see the following Knowledge Base articles:

Q158487: Browsing Across Subnets w/ a Multihomed PDC in Windows NT 4.0 Q133241: Browsing Domain Master Browsers w/ Multiple NICs and Protocols Q135404: Multihomed Master Browser May Cause Event ID 8021 and 8032

Windows NT allows the familiar browsing mechanism found in File Manager to enumerate printers for remote printing. This appendix describes the mechanism used for print browsing in a Windows NT–based environment and the registry keys that affect its behavior.


APPENDIX B:THE MULTIHOMED WINDOWS NT BROWSER

APPENDIX C:WINDOWS NT PRINTER BROWSING





Shared printers are found when a user browses for a printer in a domain. A remote procedure call (RPC) (EnumPrinters) is made to the browse master. The RPC returns only the computers in the browse list that have set the printer flag (SV_TYPE_PRINT) in their host announcements.

The following is a network trace fragment that illustrates a client browsing a Windows NT Print Server:

Client request:

SMB: C transact TransactNmPipe, FID = 0x80aMSRPC: c/o RPC Request: call 0x1 opnum 0x0 context 0x0 hint 0x364R_WINSPOOL: RPC Client call winspool:RpcEnumPrinters(..)R_WINSPOOL: DWORD Flags = 64 (0x40)R_WINSPOOL: STRING_HANDLE Name = \\NTSERVERR_WINSPOOL: DWORD Level = 1 (0x1)R_WINSPOOL: LPBYTE pPrinterEnum [..] = 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00...R_WINSPOOL: DWORD cbBuf = 804 (0x324)

Server response:

SMB: R transact TransactNmPipe (response to frame 89)MSRPC: c/o RPC Response: call 0x1 context 0x0 hint 0x338 cancels 0x0R_WINSPOOL: RPC Server response winspool:RpcEnumPrinters(..)R_WINSPOOL: LPBYTE pPrinterEnum [..] = 08 00 00 00 DA 02 00 00 B4 02 00 00B2 02 00 00 08 00 00 00 58 02 00...R_WINSPOOL: LPDWORD pcbNeeded = 460 (0x1CC)R_WINSPOOL: LPDWORD pcReturned = 3 (0x3)R_WINSPOOL: Return Value = 0 (0x0)

The network trace above shows the network client receiving back a response from the server containing information from the RPC call EnumPrinters.(Additional information on this function is available in the Win32 SDK.)

Windows NT Server- and Workstation–based computers update the browse master by default every 10 minutes with print share information. This is done by the AddPrinter function.

The following is a network trace fragment that demonstrates a client enumerating shared resources to the print browse master:


21

SMB: C transact TransactNmPipe, FID = 0x200cMSRPC: c/o RPC Request: call 0x1 opnum 0x5 context 0x0 hint 0x11CR_WINSPOOL: RPC Client call winspool:RpcAddPrinter(..)R_WINSPOOL: STRING_HANDLE pName = \\NTSERVERR_WINSPOOL: PPRINTER_CONTAINER pPrinterContainer {..}R_WINSPOOL: DWORD Level = 1 (0x1)R_WINSPOOL: (Untyped 1) PrinterInfo {..}R_WINSPOOL: Switch Value = 1 (0x1)R_WINSPOOL: LPPRINTER_INFO_1W pPrinterInfo1 {..}R_WINSPOOL: DWORD Flags = 24 (0x18)R_WINSPOOL: LPWSTR pDescription = 35780264 (0x221F6A8)R_WINSPOOL: LPWSTR pName = 35781864 (0x221FCE8)R_WINSPOOL: LPWSTR pComment = 12163832 (0xB99AF8)R_WINSPOOL: LPWSTR pDescription = \\NTCLIENT\Lexmark Optra PS,Lexmark Optra PS,R_WINSPOOL: LPWSTR pName = \\NTCLIENT\Lexmark Optra PSR_WINSPOOL: LPWSTR pComment =R_WINSPOOL: PDEVMODE_CONTAINER pDevModeContainer {..}R_WINSPOOL: DWORD cbBuf = 0 (0x0)R_WINSPOOL: LPBYTE pDevMode = 0 (0x0)R_WINSPOOL: PSECURITY_CONTAINER pSecurityContainer {..}R_WINSPOOL: DWORD cbBuf = 0 (0x0)R_WINSPOOL: LPBYTE pSecurity = 0 (0x0)

The following is a list of registry entries that manipulate client and server behavior in regard to print browsing:

HLM\SYSTEM\CurrentControlSet\Control\PrintDisableServerThread – REG_DWORD

Range: 0 or 1Default: 0 (false)Set this to 1 (true) to disable the browse thread on the current computer. This thread is used to call other print servers to notify them that this printer exists.

ServerThreadTimeout – REG_DWORDRange: MillisecondsDefault: 36,000 (36 seconds)Specifies the amount of time that the ServerThread sleeps before it calls all the other print servers to notify them of the printers on this computer.

NetPrinterDecayPeriod – REG_DWORDRange: MillisecondsDefault: 3,600,000 (1 hour)Specifies how long to cache a network printer. The cache is used to present the list of printers when the browse dialog is used.

RefreshTimesPerDecayPeriod – REG_DWORDRange: 1–5Default: 2Specifies how many times to inform the browse masters and backup servers per decay period. The default value is two times per hour. Do not set a 0 value if you specify both RefreshTimesPerDecayPeriod and ServerThreadTimeout; the system waits for the maximum of either the ServerThreadTimeout or the RefreshTimesPerDecayPeriod.


U ser applica tions, network utilities &serv ices, and so on

Se rver W orkstationBrow ser

Serv ices.exe

W N et AP I N T LM AP I

N etap i32 .d ll

Brow ser.d ll

U ser m ode

K erne l m ode

R dr.sys

T D I

At system startup, the Windows NT Service Controller starts Services.exe (formerly Lmsvcs.exe, the LanmanServer service). For each service under its control, Services.exe creates a thread that begins execution at the service’s service routine entry point. The browser service’s service routine, in Browser.dll, proceeds as follows:

1. Registers a service control routine for the browser service stop, pause, and continue

2. Initializes the service from any hard-coded, registry, or command-line parameters

3. Sends initialization information to the kernel mode datagram receiver (Browser.sys/Rdr.sys) code

4. Starts the thread that does the actual work of the service

Browser.dll is a user mode component responsible for maintaining the browse list, forwarding APIs, and managing the various roles of the browser. When using Wnet functions to browse Windows NT network resources, the functions resolve, by the NTLM API (NETAPI32.DLL), to the NTLM service DLL Browser.dll. Browser.dll uses an internal API to work with the kernel mode NTLM datagram receiver to carry out the requested resource browsing functions. Both Lmsvcs.exe and Services.exe can be found under \<Winnt root>\System32 for their respective operating system versions.

The kernel mode portion of the browser functions as a datagram and remote mailslot receiver (second-class datagram-based mailslot messages). Datagrams of interest to browser services include NetServerEnum. In Windows NT 3.1, the


23

APPENDIX D:WINDOWS NT BROWSER COMPONENTS

kernel mode functions resided in Browser.sys, but for Windows NT 3.5x and Windows NT 4.0 these functions are incorporated into Rdr.sys.

All browser datagrams destined for computers running LAN Manager, Windows for Workgroups–, Windows 95–, Windows NT Workstation–, or Windows NT Server–based computers are sent to the mailslot name \Mailslot\Lanman. Browser datagrams destined only for computers running Windows NT Workstation or Windows NT Server are sent to the mailslot name \Mailslot\Msbrowse. Both Browser.sys and Rdr.sys are located in \<Winnt root>\System32\Drivers.

HLM\SYSTEM\CurrentControlSet\Services\Browser\Parameters MaintainServerList – REG_SZ

Range: Yes, No, and AutoDefault: AutoIf this value is No, this server is not a browser. If this value is Yes, this server becomes a browser. It attempts to contact the master browser to get a current browse list. If it cannot find the master browser, it forces an election and is, of course, a candidate to become the master. In addition, setting MaintainServerList to Yes causes an election to be generated when the browser startsIf the value is Auto, this server becomes a browser if the master browser for the domain considers it appropriate for the server to be a browser.

IsDomainMaster – REG_SZRange: True and FalseDefault: FalseThis parameter gives the server an advantage during the election of a master browser in the domain. The PDC has this value set to True. For WAN environments, this specifies a workstation within a workgroup, which, as a potential browser, should be included in the global Lmhosts file. This helps with WAN browsing. It has two values:Setting this parameter to True forces the elevation of a workstation’s priority for the browser.Setting this parameter to False has no effect.

UnboundBindings – REG_MULTI_SZString: NetBT_<name of network adapter driver to be disabled>If you have more than two network adapters in the multihomed Windows NT–based server, enter each driver instance that you wish to disable on a separate line in the String field.

BackupBrowserRecoveryTime - REG_DWORDDefault: 180000 milliseconds (30 minutes)When a backup browser fails in three attempts to contact the master browser, the backup browser shuts down for this length of time.

CacheHitLimit – REG_DWORD


APPENDIX E:WINDOWS NT BROWSER REGISTRY OPTIONS


Range: 0 to 0xFFFFFFFFDefault: 1A browser maintains a cache of responses to NetServerEnum requests, and this parameter helps to control that cache. To guarantee that it is worth keeping a response to a client in the cache, the browser waits until it sees CacheHitLimit browse requests of a given type before it adds the request to the cache. Every 15 minutes (or QueryDriverFrequency on a master browser), the browser ages the cache. Any entries in the cache that have had less than CacheHitLimit hits since the previous flush are discarded.

CacheResponseSize – REG_DWORDRange: 10 to 0xFFFFFFFFDefault: 10This specifies the maximum number of cached browse responses for each transport that the browser keeps.

QueryDriverFrequency – REG_DWORDRange: 0 to 900 secondsDefault: 30This parameter is only valid on the master browser TCP/IP. When the browser is a master browser, it queries the browser driver every QueryDriverFrequency seconds. This parameter is also used to control how often the response cache is flushed on a master browser. Decreasing this value increases the accuracy of browse responses; however, it increases the CPU load on the server. Increasing this value decrease the load on the server, but also decrease the accuracy of the browse responses.

HLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\ParametersOtherDomains – REG_SZ

Default: <none>Each workstation can be configured with up to four OtherDomains. The Domains are LAN Manager–only domains that the workstation is interested in browsing. If any OtherDomains are configured on a domain master browser, the OtherDomains are provided to all members of the domain

HLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters Hidden – REG_BINARY

Range: 0 or 1Default: 0This determines whether the server's computer name and comment can be viewed by other computers in the domain. If the value is configured to 0, the server's name and comment can be viewed by other computers in the domain. If the value is configured to 1, the server's name and comment cannot be viewed by other computers in the domain.

LMAnnounce – REG_DWORDRange: 0 or 1Default: 0This option causes the browser to announce itself with a LAN Manager 2.x–compatible server announcement. By default, this option is configured not to


25

send announcements to LAN Manager 2.x servers. Setting this parameter to 1, True, causes the server to announce itself to LAN Manager workstations. Set this parameter to 0, False, to not generate any LAN Manager broadcasts.

SizReqBuf - REG_DWORDRange: 512 - 65536 bytesDefault: 4096This specifies the size of request buffers that the server uses. Small buffers use less memory; large buffers may improve performance. The exact value that works best in a specific environment depends on the configuration of that environment, but 14596 is a value that has been shown to work well in a fairly standard Ethernet environment. For more information, see the following Knowledge Base article: Q177266: Remote Directory Lists Are Slower Than Local Directory Listings

HLM\System\CurrentControlSet\Services\RDR\ParametersWindows NT 3.1 Advanced Server uses the following key:HLM\System\CurrentControlSet\Services\DGRcvr\Parameters

BrowserServerDeletionThreshold – REG_DWORDRange: 0 to 0xFFFFFFFFDefault: 0xFFFFFFFFThis parameter is only valid on master browsers. If the browser driver ages out more than BrowserServerDeletionThreshold servers in a single 30-second interval, the browser generates an event indicating a possible network problem. Its value is the number of servers. The default for this parameter is 0xffffffff, indicating that the event should never be generated.

BrowserDomainDeletionThreshold – REG_DWORDRange: 0 to 0xFFFFFFFFDefault: 0xFFFFFFFFThis is only valid on master browsers. It controls the number of domains permitted for the browser driver to age out in a 30-second interval, before generating an event indicating a possible network problem. Its value is the number of domains. The default for this parameter is 0xffffffff, indicating that the event should never be generated.

FindMasterTimeout – REG_DWORDRange: 0 to 0xFFFFFFFFDefault: 0xFFFFFFFFThis specifies the time out for FindMaster requests in seconds. On a slow network, it may be necessary to increase this value.

BrowserMinimumConfiguredBrowsers – REG_DWORDDefault: 1This parameter indicates the number of configured browsers that are considered the minimum before the browser promotes other browsers to be backup browsers.

GetBrowserListThreshold – REG_DWORDRange: 0 to 0xFFFFFFFF



Default: 0xFFFFFFFFThis represents the threshold that the browser uses before logging an error indicating that too many of these requests have been missed. If more requests than the value of GetBrowserServerList are missed in an hour, the browser logs an event indicating that this has happened.

MailslotDatagramThreshold – REG_DWORDRange: 0 to 0xFFFFFFFFDefault: 0xFFFFFFFFThis represents the threshold that the browser uses before logging an error indicating that too many of these requests have been missed. If more mailslots than the value of MailslotDatagramThreshold are missed in an hour, the browser logs an event indicating that this has happened.

Event ID: 8003Severity: ErrorSymbolicName: EVENT_BOWSER_OTHER_MASTER_ON_NETThe master browser has received a server announcement from the computer %2 that believes that it is the master browser for the domain on transport %3. The master browser is stopping, or an election is being forced.

Event ID: 8004Severity: WarningSymbolicName: EVENT_BOWSER_PROMOTED_WHILE_ALREADY_MASTERA request has been submitted to promote the computer to backup when it is already a master browser.

Event ID: 8005Severity: WarningSymbolicName: EVENT_BOWSER_NON_MASTER_MASTER_ANNOUNCEThe browser has received a server announcement indicating that the computer %2 is a master browser, but this computer is not a master browser.

Event ID: 8006Severity: WarningSymbolicName: EVENT_BOWSER_ILLEGAL_DATAGRAMThe browser has received an illegal datagram from the remote computer %2 to name %3 on transport %4. The data is the datagram.

Event ID: 8007 Severity: Error SymbolicName: EVENT_BROWSER_STATUS_BITS_UPDATE_FAILEDThe browser was unable to update the service status bits. The data is the error.


27

APPENDIX F:WINDOWS NT BROWSER ERROR CODES

Event ID: 8008Severity: ErrorSymbolicName: EVENT_BROWSER_ROLE_CHANGE_FAILEDThe browser was unable to update its role. The data is the error.

Event ID: 8009Severity: ErrorSymbolicName: EVENT_BROWSER_MASTER_PROMOTION_FAILEDThe browser was unable to promote itself to master browser. The computer that currently believes it is the master browser is %1.

Event ID: 8010Severity: ErrorSymbolicName: EVENT_BOWSER_NAME_CONVERSION_FAILEDThe browser driver was unable to convert a character string to a Unicode string.


Event ID: 8011Severity: ErrorSymbolicName: EVENT_BROWSER_OTHERDOMAIN_ADD_FAILEDThe browser was unable to add the configuration parameter %1.

Event ID: 8012Severity: SuccessSymbolicName: EVENT_BOWSER_ELECTION_RECEIVEDThe browser driver has received an election packet from computer %2 on network %3. The data is the packet received.

Event ID: 8013Severity: Informational SymbolicName: EVENT_BOWSER_ELECTION_SENT_GETBLIST_FAILEDThe browser driver has forced an election on network %2 because it was unable to find a master browser to retrieve a backup list on that network.

Event ID: 8014Severity: Informational SymbolicName: EVENT_BOWSER_ELECTION_SENT_FIND_MASTER_FAILEDThe browser driver has forced an election on network %2 because it was unable to find a master browser for that network.

Event ID: 8015Severity: InformationalSymbolicName: EVENT_BROWSER_ELECTION_SENT_LANMAN_NT_STARTEDThe browser has forced an election on network %1 because a Windows NT Server (or domain master) browser is started.

Event ID: 8016Severity: ErrorSymbolicName: EVENT_BOWSER_ILLEGAL_DATAGRAM_THRESHOLDThe browser driver has received too many illegal datagrams from the remote computer %2 to name %3 on transport %4. The data is the datagram. No more events will be generated until the reset frequency has expired.

Event ID: 8017Severity: ErrorSymbolicName: EVENT_BROWSER_DEPENDANT_SERVICE_FAILEDThe browser has failed to start because the dependent service %1 had invalid service status %2.

Status Meaning1 Service Stopped%n2 Start Pending%n3 Stop Pending%n4 Running%n5 Continue Pending%n6 Pause Pending%n


29

7 Paused%n

Event ID: 8019Severity: ErrorSymbolicName: EVENT_BROWSER_MASTER_PROMOTION_FAILED_STOPPINGThe browser was unable to promote itself to master browser. The browser will continue to attempt to promote itself to the master browser but will no longer log any events in the event log in Event Viewer.

Event ID: 8020Severity: ErrorSymbolicName: EVENT_BROWSER_MASTER_PROMOTION_FAILED_NO_MASTERThe browser was unable to promote itself to master browser. The computer that currently believes it is the master browser is unknown.

Event ID: 8021 Severity: Warning SymbolicName: EVENT_BROWSER_SERVER_LIST_FAILEDThe browser was unable to retrieve a list of servers from the browser master %1 on the network %2. The data is the error code.

Event ID: 8022Severity: WarningSymbolicName: EVENT_BROWSER_DOMAIN_LIST_FAILEDThe browser was unable to retrieve a list of domains from the browser master %1 on the network %2. The data is the error code.

Event ID: 8023Severity: WarningSymbolicName: EVENT_BROWSER_ILLEGAL_CONFIGThe value for the parameter %1 to the browser service was illegal.

Event ID: 8024Severity: InformationalSymbolicName: EVENT_BOWSER_OLD_BACKUP_FOUNDThe backup browser server %2 is out of date. Consider upgrading this computer.

Event ID: 8025Severity: SuccessSymbolicName: EVENT_BROWSER_SERVER_LIST_RETRIEVEDThe browser has retrieved a list of servers from remote computer %1 on transport %2.%n There were %3 entries read and %4 total entries.

Event ID: 8026Severity: SuccessSymbolicName: EVENT_BROWSER_DOMAIN_LIST_RETRIEVEDThe browser has retrieved a list of domains from remote computer %1 on transport %2.%n There were %3 entries read and %4 total entries.

Event ID: 8027


Severity: InformationalSymbolicName: EVENT_BOWSER_PDC_LOST_ELECTIONThe browser running on the domain controller has lost an election. The computer that won the election is %2 on the transport %3.%n The data contains the election version, election criteria, remote computer time up, and the same information for the current computer.

Event ID: 8028Severity: InformationalSymbolicName: EVENT_BOWSER_NON_PDC_WON_ELECTIONThe browser running on this computer has won a browser election on network %2. This computer is a member of a domain, so the domain controller should become the master browser.

Event ID: 8029SymbolicName: EVENT_BOWSER_CANT_READ_REGISTRYThe browser driver was unable to initialize variables from the registry.

Event ID: 8030SymbolicName: EVENT_BOWSER_MAILSLOT_DATAGRAM_THRESHOLD_EXCEEDEDThe browser driver has discarded too many mailslot messages.

Event ID: 8031SymbolicName: EVENT_BOWSER_GETBROWSERLIST_THRESHOLD_EXCEEDEDThe browser driver has discarded too many GetBrowserServerList requests.

Event ID: 8032Severity: ErrorSymbolicName: EVENT_BROWSER_BACKUP_STOPPEDThe browser service has failed to retrieve the backup list too many times on transport %1. The backup browser is stopping.

Event ID: 8033Severity: InformationalSymbolicName: EVENT_BROWSER_ELECTION_SENT_LANMAN_NT_STOPPEDThe browser has forced an election on network %1 because a master browser was stopped.

Event ID: 8034Severity: ErrorSymbolicName: EVENT_BROWSER_GETBLIST_RECEIVED_NOT_MASTERThe browser has received a GetBrowserServerList request when it is not the master browser.

Event ID: 8035Severity: InformationalSymbolicName: EVENT_BROWSER_ELECTION_SENT_ROLE_CHANGEDThe browser has forced an election on network %1 because the Domain


31

controller (or server) has changed its role Event ID: 8036

Severity: ErrorSymbolicName: EVENT_BROWSER_NOT_STARTED_IPX_CONFIG_MISMATCHThe browser has failed to start because of an error in the DirectHostBinding parameter to the browser.

MAC LayerMost browser frames are sent as broadcast or multicast at the MAC layer. The advantage of using broadcast is that everyone receives the frame. Additionally, the overhead of a sessions is not needed. However, broadcast traffic must be processed by all systems, including ones not interested in browsing. One potential ramification of using broadcast datagrams is that browsing is limited to a broadcast collision zone. This side effect occurs because most routers and switches are configured to not forward NetBIOS broadcast traffic.

Network LayerAll browser frames are sent to the broadcast network address. For example, if a station has an IP address of 130.20.1.1 and a subnet mask of 255.255.0.0, all browser frames are addressed to 130.20.255.255. Obviously this does not apply for transport protocols that lack a network layer, such as NetBEUI.

NetBIOS LayerMost Microsoft protocols contain a NetBIOS protocol layer. Examples include NBFP in NetBEUI or NetBT in the TCP/IP stack. The browser uses an elaborate NetBIOS naming scheme to direct traffic. The names are controlled by adding a special code in the sixteenth character of the domain name. Even though a frame is broadcast at the MAC and network layer, only stations that have the special NetBIOS name registered accept the frames. The following is an example of an Windows NT 3.1 NBT [NetBIOS over TCP\IP] browser frame. Notice the destination NetBIOS name.


APPENDIX G:NETWORK LAYERS INVOLVED IN BROWSING

NBT: DS: Type = 17 (DIRECT GROUP) NBT: Datagram Packet Type = DIRECT GROUP NBT: Datagram Flags = 2 (0x2) NBT: 0000.... = Reserved NBT: ....00.. = B Node NBT: ......1. = Not First Packet NBT: .......0 = More Fragments Follow NBT: Datagram ID = 164 (0xA4) NBT: Source IP Address = 130.22.1.99 NBT: Source Port = 138 (0x8A) NBT: Datagram Length = 189 (0xBD) NBT: Packet Offset = 0 (0x0) NBT: Source Name = BATCOMPUTER3<00> NBT: Destination Name = DOMA<1D> NBT: DS Data: Number of data bytes remaining = 119 (0x0077)

SMB LayerAll Browser frames ride on top of SMB Transact frames. Because the frame contains an SMB, it must also contain a NetBIOS layer, which contains one of the NetBIOS names discussed previously. The SMB Transact carries the command “Mailslot Write.” Since the browser service is a mailslot receiver, the browser accepts mailslots addressed to \Mailslot\Browse. The mailslot data following the mailslot address is the Browser frame. The first byte is the browser command code. The following is an example of the SMB layer of a browser frame:


33

SMB: C transact, File = \MAILSLOT\BROWSE SMB: SMB Status = Error Success SMB: Error class = No Error SMB: Error code = No Error SMB: Header: PID = 0x0000 TID = 0x0000 MID = 0x0000 UID = 0x0000 SMB: Tree ID (TID) = 0 (0x0) SMB: Process ID (PID) = 0 (0x0) SMB: User ID (UID) = 0 (0x0) SMB: Multiplex ID (MID) = 0 (0x0) SMB: Flags Summary = 0 (0x0) SMB: .......0 = Lock & Read and Write & Unlock not supported SMB: ......0. = Send No Ack not supported SMB: ....0... = Using case sensitive pathnames SMB: ...0.... = No canonicalized pathnames SMB: ..0..... = No Opportunistic lock SMB: .0...... = No Change Notify SMB: 0....... = Client command SMB: flags2 Summary = 0 (0x0) SMB: ...............0 = Understands only DOS 8.3 filenames SMB: ..............0. = Does not understand extended

Attributes SMB: ..0............. = No paging of IO SMB: .0.............. = Using SMB status codes SMB: 0............... = Using ASCII strings SMB: Command = C transact SMB: Word count = 17 SMB: Word parameters SMB: Total parm bytes = 0 SMB: Total data bytes = 33 SMB: Max parm bytes = 0 SMB: Max data bytes = 0 SMB: Max setup words = 0 SMB: Transact Flags Summary = 0 (0x0) SMB: ...............0 = Leave session intact SMB: ..............0. = Response required SMB: Transact timeout = 0 (0x0) SMB: Parameter bytes = 0 (0x0) SMB: Parameter offset = 0 (0x0) SMB: Data bytes = 33 (0x21) SMB: Data offset = 86 (0x56) SMB: Setup word count = 3 SMB: Setup words SMB: Mailslot opcode = Write mailslot SMB: Transaction priority = 1 SMB: Mailslot class = Unreliable (broadcast) SMB: Byte count = 50 SMB: Byte parameters SMB: Path name = \MAILSLOT\BROWSE SMB: Transaction data SMB: Data: Number of data bytes remaining = 33 (0x0021)

The Browser service consists of 10 special peer protocol frames. In addition, the Browser relies heavily on two LAN Manager APIs and RPC in Windows NT. The Browser uses these frames in conjunction with standard NetBIOS frames to operate.

The following are Windows NT browser frames and their command codes:


APPENDIX H:WINDOWS NT BROWSER PROTOCOL FRAMES

#define HostAnnouncement 1 0x01#define AnnouncementRequest 2 0x02#define Election 8 0x08#define GetBackupListReq 9 0x09#define GetBackupListResp 10 0x0a#define BecomeBackup 11 0x0b#define WkGroupAnnouncement 12 0x0c#define MasterAnnouncement 13 0x0d#define ResetBrowserState 14 0x0e#define LocalMasterAnnouncement15 0x0f

Server Type FieldThe Server Type field appears in many of the browser frames. This field contains flag bits that indicate the current status of the server.

The following is an enumeration of Server Types:

SV_TYPE_WORKSTATION 0x00000001 All LAN Manager workstationSV_TYPE_SERVER 0x00000002 All LAN Manager serverSV_TYPE_SQLSERVER 0x00000004 Any server running with SQL

serverSV_TYPE_DOMAIN_CTRL 0x00000008 Primary domain controllerSV_TYPE_DOMAIN_BAKCTRL 0x00000010 Backup domain controllerSV_TYPE_TIMESOURCE 0x00000020 Server running the

Timesource ServiceSV_TYPE_AFP 0x00000040 Apple File Protocol serversSV_TYPE_NOVELL 0x00000080 Novell serversSV_TYPE_DOMAIN_MEMBER 0x00000100 Domain MemberSV_TYPE_PRINT 0x00000200 Server sharing print queueSV_TYPE_DIALIN 0x00000400 Server running RAS serviceSV_TYPE_XENIX_SERVER 0x00000800 Xenix serverSV_TYPE_NT 0x00001000 NT serverSV_TYPE_WFW 0x00002000 Server running Windows for

WorkgroupsSV_TYPE_SERVER_NT 0x00008000 Windows NT Non-DC serverSV_TYPE_POTENTIAL_BROWSER 0x00010000 Server that can run the

browser serviceSV_TYPE_BACKUP_BROWSER 0x00020000 Server running a browser

service as backupSV_TYPE_MASTER_BROWSER 0x00040000 Server running the master

browser serviceSV_TYPE_DOMAIN_MASTER 0x00080000 Server running the domain

master browserSV_TYPE_TERMINALSERVER 0X02000000 Server running Windows NT

Terminal ServicesSV_TYPE_APPSERVER 0x10000000 Server running Citrix

WinframeSV_TYPE_ALTERNATE_XPORT 0X20000000 Return List for Alternate

TransportSV_TYPE_LOCAL_LIST_ONLY 0x40000000 Return local list onlySV_TYPE_DOMAIN_ENUM 0x80000000 Return domain membersSV_TYPE_ALL 0xffffffff All servers

Host Announcement FrameThe Announce Packet is used to announce servers in the domain. When a Windows NT (or Windows For Workgroups) server announces itself, it sends a directed Announce to the unique master name for that workgroup <DOMAIN><1d>. When a Windows NT (or Windows for Workgroups) master browser announces itself, it sends a broadcast to the group election name <DOMAIN><1e>.

This announcement packet serves the following purposes:

1. It indicates to backup browsers that the master has changed. Backup browsers


35

notice this packet and update their saved version of the master browser name.

2. The master browser places its information in its local browse list.

3. If a master browser receives an announcement packet from another computer that believes that it is the master browser, the master shuts down, discards its local browser list, and forces an election. This allows the correct master to be determined.

UpdateCount: The UpdateCount field is used to indicate that information has been updated in the servers' announcement list. If contents of the master browser’s server or domain list has modified, it increments UpdateCount and announces. This allows backup browsers to pick up these updates.

Periodicity: Below this is referred to as the Update Interval, and it is converted to minutes. The announcement frequency of the server. The server is removed from the browse list if it has not been heard from in three times its announcement frequency.

ServerName: Null-terminated OEM ASCII server name. VersionMajor: The major version of the server. VersionMinor: The minor version of the server. Server Type: See above.


Example:

BROWSER: Host Announcement [0x01] BROWSER: Command = Host Announcement [0x01] BROWSER: Update Count = 7 (0x7) BROWSER: Annoucement Interval [minutes] = 5 BROWSER: Name = BATCOMPUTER3 BROWSER: Major Version = 1 (0x1) BROWSER: Minor Version = 51 (0x33) BROWSER: Server Type Summary = 204803 (0x32003) BROWSER: ...............................1 = Workstation BROWSER: ..............................1. = Server BROWSER: .............................0.. = Not SQL Server BROWSER: ............................0... = Not Domain Controller BROWSER: ...........................0.... = Not Backup Controller BROWSER: ..........................0..... = Not Time Source BROWSER: .........................0...... = Not Apple Server BROWSER: ........................0....... = Not Novell BROWSER: .......................0........ = Not Domain Member Server BROWSER: ......................0......... = Not Print Queue Server BROWSER: .....................0.......... = Not Dialin Server BROWSER: ....................0........... = Not Xenix Server BROWSER: ...................0............ = Not NT System BROWSER: ..................1............. = Windows for Workgroups BROWSER: ...............1................ = Potential Browser Server BROWSER: ..............1................. = Backup Browser Server BROWSER: .............0.................. = Not Master Browser BROWSER: ............0................... = Not Domain Master Browser BROWSER: ...........0.................... = Not OSF BROWSER: ..........0..................... = Not VMS BROWSER: .0.............................. = Not Local List Only BROWSER: 0............................... = Not Domain Enum BROWSER: Browser Election Version = 779 (0x30B) BROWSER: Browser Constant = 43605 (0xAA55)

Local Master Announcement FrameThis frame is basically the same as the Host Annoucement frame. It is used by the master browser to announce itself. These frames are usually sent to the special NetBIOS name <DOMAIN><1e>, which is used by all browsers.


37

Example:

BROWSER: Local Master Announcement [0x0f] BROWSER: Command = Local Master Announcement [0x0f] BROWSER: Update Count = 0 (0x0) BROWSER: Annoucement Interval [minutes] = 12 BROWSER: Name = COOLBLADE BROWSER: Major Version = 3 (0x3) BROWSER: Minor Version = 50 (0x32) BROWSER: Server Type Summary = 266251 (0x4100B) BROWSER: ...............................1 = Workstation BROWSER: ..............................1. = Server BROWSER: .............................0.. = Not SQL Server BROWSER: ............................1... = Domain Controller BROWSER: ...........................0.... = Not Backup Controller BROWSER: ..........................0..... = Not Time Source BROWSER: .........................0...... = Not Apple Server BROWSER: ........................0....... = Not Novell BROWSER: .......................0........ = Not Domain Member Server BROWSER: ......................0......... = Not Print Queue Server BROWSER: .....................0.......... = Not Dialin Server BROWSER: ....................0........... = Not Xenix Server BROWSER: ...................1............ = Windows NT System BROWSER: ..................0............. = Not WFW System BROWSER: ...............0................ = Not Potential Browser BROWSER: ..............0................. = Not Backup Browser BROWSER: .............1.................. = Master Browser Server BROWSER: ............0................... = Not Domain Master Browser BROWSER: ...........0.................... = Not OSF BROWSER: ..........0..................... = Not VMS BROWSER: .0.............................. = Not Local List Only BROWSER: 0............................... = Not Domain Enum BROWSER: Browser Election Version = 271 (0x10F) BROWSER: Browser Constant = 43605 (0xAA55)

Domain / Work Group Announcement FrameThis frame is sent by the master browser to announce the existence of the domain. Other master browsers in different domains store these announcements along with the server’s name. This is one way that they build their domain list. These frames are sent to the special NetBIOS name <01><02>MSBROWSE<02><01>.

Name: For this frame, Name is set to the Domain name, not the server name. Comment Pointer: Unused value. Server Name: The master browser that is announcing the domain. This name is

stored by master browsers in other domains. This is used to double hop.


Example:

BROWSER: Workgroup Announcement [0x0c] BROWSER: Command = Workgroup Announcement [0x0c] BROWSER: Update Count = 0 (0x0) BROWSER: Annoucement Interval [minutes] = 15 BROWSER: Name = DOMA BROWSER: Major Version = 3 (0x3) BROWSER: Minor Version = 10 (0xA) BROWSER: Server Type Summary = 2147487744 (0x80001000) BROWSER: ...............................0 = Not Workstation BROWSER: ..............................0. = Not Server BROWSER: .............................0.. = Not SQL Server BROWSER: ............................0... = Not Domain Controller BROWSER: ...........................0.... = Not Backup Controller BROWSER: ..........................0..... = Not Time Source BROWSER: .........................0...... = Not Apple Server BROWSER: ........................0....... = Not Novell BROWSER: .......................0........ = Not Domain Member Server BROWSER: ......................0......... = Not Print Queue Server BROWSER: .....................0.......... = Not Dialin Server BROWSER: ....................0........... = Not Xenix Server BROWSER: ...................1............ = Windows NT System BROWSER: ..................0............. = Not WFW System BROWSER: ...............0................ = Not Potential Browser BROWSER: ..............0................. = Not Backup Browser BROWSER: .............0.................. = Not Master Browser BROWSER: ............0................... = Not Domain Master Browser BROWSER: ...........0.................... = Not OSF BROWSER: ..........0..................... = Not VMS BROWSER: .0.............................. = Not Local List Only BROWSER: 1............................... = Domain Enum BROWSER: Comment Pointer = 28311416 (0x1AFFF78) BROWSER: Server Name = ATT-SERVER

Announcement Request FrameThis frame causes all local browsers to announce themselves. This frame is sent at browser client startup to find the master browser for the domain. The frame is usually broadcast to the special NetBIOS name <DOMAIN><1d>, which is only registered by a master browser. Sometimes it is sent directly to the master browser.

Example:

BROWSER: Announcement Request [0x02] BROWSER: Command = Announcement Request [0x02] BROWSER: Unused Flags = 0 (0x0) BROWSER: Reply System Name = A-CLIENT

Election FrameThis frame is sent when a master browser election is required. This usually occurs when the master browser goes down or when the network is starting up.

Version: Specifies the version of this election packet. Criteria: Specifies the election criteria of the client. This contains two subfields. Operating System: Specifies the operating system type and version which is

one of the election criteria. Election Revision: Part of the browser software version. Election Desire: Contains items that help determine the election criteria. Some

items deal with current browser state, such as Current Backup Browser. TimeUp: The amount of time that the server has been up, which is one of the


39

election criteria. ServerName: Null-terminated ASCII server name.

Example:

BROWSER: Election [0x08] BROWSER: Command = Election [0x08] BROWSER: Election Version = 1 (0x1) BROWSER: Election Criteria = 536940294 (0x20010F06) BROWSER: Election OS Summary = 32 (0x20) BROWSER: .......0 = Not WFW BROWSER: ......0. = Not used BROWSER: .....0.. = Not used BROWSER: ....0... = Not used BROWSER: ...0.... = Not Windows NT Workstation BROWSER: ..1..... = Advanced Server Windows NT BROWSER: .0...... = Not used BROWSER: 0....... = Not used BROWSER: Election Revision = 271 (0x10F) BROWSER: Election Desire Summary = 6 (0x6) BROWSER: .......0 = Not Backup Browse Server BROWSER: ......1. = Standby Browser Server BROWSER: .....1.. = Currently Master Browser Server BROWSER: ....0... = Not Domain Master Browser BROWSER: ...0.... = Not used BROWSER: ..0..... = Not WINS Client BROWSER: .0...... = Not used BROWSER: 0....... = Not Advanced Server BROWSER: Server Up Time [DD:hh:mm:ss] 0:0:31:31 BROWSER: Election Server Name = ATT-SERVER

Become Backup FrameThis frame is used by the master browser to tell a potential browser to become a backup. To see how the master browser determines this refer to the backup ration chart in the Master Browser section. Even though this message is only intended for one particular system, the master browser still broadcasts this frame.

Example:

BROWSER: Become Backup [0x0b] BROWSER: Command = Become Backup [0x0b] BROWSER: Name = BATCOMPUTER3

Get Backup List Request FrameThis frame is broadcast to get a list of backup browsers from a particular domain. The domain is specified by the special NetBIOS name in the NetBIOS frame section. It is sent with the name <DOMAIN><1d>. The workstation stores a maximum of three of the names returned. 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. From this list it picks one at random to which to send NetServerEnum2.

Fields:

Requested Count: Indicates the maximum number for browser server names to return. It may return fewer.

Token: Used by the sender to correlate a request with a response. The client might send multiple requests on multiple transports for different domain names.


Example:

BROWSER: Get Backup List Request [0x09] BROWSER: Command = Get Backup List Request [0x09] BROWSER: Get Backup List Requested Count = 4 (0x4) BROWSER: Backup Request Token = 1 (0x1)

Get Backup List Response FrameThis is the response to a Get Backup List Request.

Example:

BROWSER: Get Backup List Response [0x0a] BROWSER: Command = Get Backup List Response [0x0a] BROWSER: Backup Server Count = 2 (0x2) BROWSER: Backup Response Token = 1 (0x1) BROWSER: Backup Servers = LCSCOTTSU1 BROWSER: Backup Servers = RTHOM1

Master Announcement FrameThis frame is sent by the master browser on a subnet to the PDC (DomainMaster). It announces the presence of the master on the domain to allow the PDC to retrieve the local subnets domain list. This is one of the few browser frames that is sent directly to the master browser; it is a directed datagram.

Example:

BROWSER: Master Announcement [0x0d] BROWSER: Command = Master Announcement [0x0d] BROWSER: Master Name = LCSCOTTSU5

Reset Browser State FrameThis frame is a diagnostic packet that can be used to force a master browser to stop functioning as a master browser.

Options:

RESET_STATE_STOP_MASTER (0x01)This indicates that the master browser should stop functioning as a master. This means that it should remove the master name and the domain announcement name and fall back as a backup browser.

RESET_STATE_CLEAR_ALL (0x02)This indicates that a browser should clear its browser state. This means that the browser should discard its server list and effectively restart.

RESET_STATE_STOP (0x04)This indicates that the browser should stop functioning at all. For security reasons, the NT browser does not support this packet.

Example:

BROWSER: Reset Browser [0x0e] BROWSER: Command = Reset Browser [0x0e] BROWSER: Options Summary = 2 (0x2) BROWSER: .......0 = Zero BROWSER: ......1. = Reset Entire Browser State BROWSER: .....0.. = Zero


41

Windows NT Browser v.4.0€¦ · Web viewWindows NT® Server. Server Operating System. Microsoft...

Documents

Transcript of Windows NT Browser v.4.0€¦ · Web viewWindows NT® Server. Server Operating System. Microsoft...