Provide Feedback on this Broadcast

Note This document is based on the original spoken Support WebCast transcript. It has been edited for clarity.

Tim Rains: Thanks, everyone, for joining us. This session focuses on NetBIOS Browsing and a new utility called the NetBIOS Browsing Console.

As far as the agenda goes (slide 2), specifically we will examine the following three topics. First I will define what NetBIOS Browsing is, how it gets used, and identify its components. Then we will look at typical problems encountered with NetBIOS Browsing mechanisms and how to troubleshoot such problems. Finally, I will introduce the NetBIOS Browsing Console and discuss how it can help during the troubleshooting process. Although NetBIOS Browsing is protocol dependent, I will focus on scenarios where TCP/IP is used and where Windows domains are used as opposed to workgroups.

Before we get started, I want to point out two really good resources for NetBIOS Browsing and troubleshooting it. The NetBIOS Browsing white paper contains very detailed information on NetBIOS Browsing, how it works, and how to troubleshoot it. It's an excellent source of information. As well, Knowledge Base article number 188001 also describes browsing in an abridged format.

So what is NetBIOS Browsing (slide 3)? In a nutshell it is a mechanism that provides a list of network resources to clients on the network (slide 4). Put another way, clients use NetBIOS Browsing mechanisms to populate lists of computers and printers. The NetBIOS Browsing mechanism has been around since LANMAN 1.0, so it's been around a long time.

NetBIOS Browsing is supported in Microsoft® Windows® for Workgroups, Windows 95, Windows 98, Windows NT® 4.0, Windows 2000, Windows XP, and Windows Server 2003. It's a very pervasive technology (slide 5). This slide gives you an idea of some of the applications that use NetBIOS Browsing and, of course, there are many, many third-party applications that utilize NetBIOS Browsing as well. Again, NetBIOS Browsing is very pervasive.

For example, this graphic (slide 6) illustrates My Network Places opened on a Windows XP client. As the network is explored, a list of network resources is displayed. This list is populated using the NetBIOS Browsing mechanism that we're going to discuss.

This graphic (slide 7) illustrates Microsoft Word opening a document. In this case, the user is browsing for a server that has the document shared out. Word essentially uses the same NetBIOS Browsing mechanism to populate this list as any other application would.

The Computer Browser service (slide 8), which runs on Windows systems, maintains a list of network resources. This list can contain domain resources and workgroups across your wide area network. That said, not every system on your network necessarily needs to run the Computer Browser service. When this service is stopped or disabled, the system will be able to browse the network for resources, but it won't maintain a browse list and distribute the list to other clients like a master browser does.

What is a master browser? The Windows systems that run the Computer Browser service are called potential browsers because they can potentially maintain and distribute browse lists. A potential browser can assume several different roles in a network. I will outline these roles on the next few slides.

Before I get to the browser roles, I want to mention a few more points about the Computer Browser service. By default this service is enabled and starts automatically when Windows systems start. While troubleshooting NetBIOS Browsing problems, many times support engineers will stop and/or disable the Computer Browser service on selected systems in order to reduce the complexity of the browsing infrastructure. Doing this makes it easier to troubleshoot and control the browsing infrastructure. There are also two registry values that can help to do this as well, the MaintainServerList value and the IsDomainMaster value can both be used to architect a NetBIOS Browsing infrastructure.

What is this infrastructure I keep mentioning? Let's move on to the topic of browser roles to see. I will mention these registry settings again later in the presentation.

As I mentioned earlier, a potential browser can take on different roles in a network. One such role is called the domain master browser (slide 9). The PDC, meaning the primary domain controller, or the PDC emulator, should always be the domain master browser. It will maintain the master list of all resources in the domain. It does this by merging the browse list provided by segment master browsers.

A segment master browser (slide 10) maintains a list of resources that are announced on its segment. Each logical IP subnet should have one master browser that maintains a browse list of resources in its domain. This list is sent to the domain master browser to be merged with lists from other segment master browsers in the domain. The domain master browser will send a merged list of domain resources to each segment master browser so that they have a complete list of domain resources. This happens approximately every 15 minutes.

For every 32 systems on a segment the segment master browser will designate a system to become a backup master browser (slide 11). The backup master browsers help the master browser distribute browse lists to clients. The backup master browsers request a new browse list from the segment master browser every 15 minutes so that its list is relatively up to date.

To quickly recap what the browser infrastructure generally looks like, each logical IP subnet should have a segment master browser on it. The segment master browser maintains a browse list of domain resources and helps to keep the domain master browsers list up to date. For every 32 Windows systems on a segment there should be one backup master browser. The segment master browser shares its list with the backup master browsers on its segment. Backup master browsers distribute the list to clients when the clients request it.

If you are not familiar with NetBIOS Browsing, you may be asking yourself, "Why do we need this type of infrastructure? Why can't the domain master browser just do all of these functions?" There are a few reasons why this is so.

First, systems register themselves or announce themselves in a browse list using broadcasts. Since broadcasts typically are not forwarded between subnets, each subnet needs to track its own resources. Each subnet's list of resources is merged by the domain master browser and redistributed so everyone can see all resources.

The second reason for this type of infrastructure is to ensure scalability and performance. As more systems are added to a subnet, more backup subnet master browsers are employed. If the network shrinks, the browsing infrastructure dynamically shrinks with it.

The next question you may be asking is, "If the domain master browser is the PDC and the backup master browsers are designated by the segment master browser, how do segment master browsers get selected?" The answer is that each segment holds an election. The system that wins this browser election becomes the segment master browser. Specific criteria are used during elections to decide which system should hold the role. Ultimately, the system that runs the newest operating system and/or the most critical role should win. A full list of the criteria is available in the NetBIOS Browsing white paper that I referenced earlier.

This is where the two registry values that I mentioned earlier come into play. They bias the election to try to ensure that the system that the administrator prefers to hold the segment master browser role wins the election. The white paper contains more detail on this, as well as numerous Knowledge Base articles, like 102878.

In order for browsing to work across network segments, NetBIOS name resolution is critical. As I mentioned, the segment master browsers must be able to communicate with the domain master browser wherever it is located on the network. To do this the segment master browsers must be able to find the domain master browser. This requires a NetBIOS name resolution mechanism. You could use Lmhost files, but this approach rapidly becomes unmanageable. WINS (Windows Internet Name Service) is the best mechanism to ensure that the segment master browser can find the domain master browser using its domain name. The segment master browser queries WINS for the PDC's name and then queries WINS for the PDC's IP address. Then it can connect to the PDC for the browse list.

So we have a NetBIOS Browsing infrastructure that is scaleable. It requires NetBIOS name resolution for it to successfully work across subnets. What can go wrong? This slide (13) lists some of the common problems that can occur. For instance, systems not displaying in the browse list, systems intermittently displayed in the browse list, a whole subnet of systems not displayed in the browse list, some clients can browse this system and some clients cannot. These are very typical problems on large networks. How do we troubleshoot these types of problems? Fortunately, the same approach can help troubleshoot all of these scenarios.

You have to determine what piece of the infrastructure is not working as expected (slide 14). In the case of a single system missing from the browse list, the following questions must be answered: Does the missing system's own segment master browser have the system in the browse list? Does the domain master browser have the missing system in its browse list? For a particular client that can't see the missing system, does its segment master browser have the system in its browse list?

In order to answer these questions you need to identify the following systems on the network (slide 15): The missing system's segment master browser, the domain master browser, and the client's segment master browser (the client being the system that can't see the missing system). Once you've identified all of the systems holding these browser roles, you need to dump the browse list from each of them and then look for the missing system in each of those lists (slide 16). Identifying the browsers that have the missing system in their list and the browsers that do not, is the key to understanding where the problem is.

For example, if the missing system's own segment master browser does not have it in its browse list, this problem must be addressed before any other systems on the network will be able to see the missing system. If the missing system's segment master browser does have it in its browse list, but the domain master browser does not, this indicates a different problem. If the missing system is in the domain master browser's list, but not in the list maintained on a segment master browser located on a remote subnet this, again, is a different problem. Each of these scenarios shares a common symptom, but the root cause can be quite different in each case.

So how does someone dump the browse list from a particular master browser (slide 17)? One tool that can be used to do this is called Browstat.exe. Browstat.exe is included in the Windows support tools included on the Windows 2000 Server CD. Prior to this, I believe it was also available in the Windows NT 4.0 Resource Kit. The NetBIOS Browsing white paper describes how to use Browstat.exe to troubleshoot NetBIOS Browsing issues in detail. Browstat is a very powerful tool and it's helped many people troubleshoot NetBIOS Browsing issues over the years.

For many people, using Browstat.exe can be confusing (slide 18). It is a command-line utility that requires some knowledge of NetBIOS Browsing. Also, Browstat may need to be run from several locations on the network. This may not always be possible or easily done. This slide (19) illustrates some of the options available when running Browstat.exe.

To make it easier for people to troubleshoot NetBIOS Browsing issues, I decided to create a tool that leverages the power of Browstat that makes it easier to use and understand (slide 20). I envisioned a tool that collects all of the pertinent data needed to troubleshoot a browsing issue and that presents it to the troubleshooter in an easy to understand interface. The tool would give troubleshooting suggestions based on the data that it finds. So I developed the NetBIOS Browsing Console (slide 21).

It has two components — a console and an agent. The console provides troubleshooters with an easy-to-use graphical interface. The agent allows the console to collect browsing data from remote subnets. The console can be run on Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003. It requires TCP/IP version 4.0. The console also requires the .NET Framework, which is a free download available from Microsoft.com. The console can be run, generally, from any point on the network.

This slide (22) illustrates what the console looks like. The pane on the left contains a tree view of the network. After the console runs, this pane is updated with browser information and browse lists from each system queried. The user starts the troubleshooting process by specifying which system is missing from the browse list, which subnet it's located on, and which system and subnet can't see the missing system. A wizard collects this information when the console is run for the first time. The right pane shows the user the steps that the console is taking to collect the data.

The agent is a small application that listens for console connections (slide 23). It runs on Windows NT 4.0, 2000, XP, and Server 2003. It does not require the .NET Framework and it has no installation or setup program. The agent does, however, require TCP/IP version 4.0. You simply copy it onto any system, into any directory and run it. It should be run on one system per subnet, but it does not have to be run on the subnet where the console is being run from. It runs the Browstat.exe commands required and returns the data back to the console where it is analyzed. This slide (24) illustrates what the agent looks like when it's running. It logs connection attempts to the screen.

It is worth mentioning that neither the console nor the agent should be run on a multi-homed system. Systems with multiple interfaces have problems with NetBIOS Browsing and should be avoided when running Browcon.exe.

The first time you run the console, the Network Profile Wizard starts and collects the information needed to perform the troubleshooting steps (slide 25). You should have this information ready. For example, the NetBIOS name of all of the Windows domains on your network; the NetBIOS name of the PDC for each Windows domain; the IP address of the PDC for each Windows domain; IP addresses of all of the WINS servers on the network; lists of all IP subnets on the network; and the NetBIOS name of each system on the network that is running the NetBIOS Console Agent.

Then, as I mentioned earlier, using the drop-down boxes and text fields in the console, you answer four quick questions (slide 26) and click on the Start Troubleshooting button.

The Console will use agents as needed to identify the domain master browser, all segment master browsers, and backup master browsers (slide 27). It will collect browse lists from the segment master browsers and domain master browser. It analyzes the data and presents the user with one or more reports. The reports are in HTML format (slide 28). They give the user suggestions on what troubleshooting steps to take to find the cause of the current problem.

This slide (29) illustrates what a report looks like. The reports give you a diagnosis based on the data it collected, and then what the possible causes could be. These possible causes are based on the problems we see most often in customer environments. In my experience, the number one cause of NetBIOS Browsing issues is a multi-homed server is used for domain or segment master browsers. Please avoid multi-homing servers, if possible. Architect a browsing infrastructure using the registry values that I mentioned and strategic use of the Computer Browser service.

These are some great resources to review, and version 1.0 of the NetBIOS Browsing Console is available for download via the link inside KB article 818092. Check for updates in the future, for updated versions of the NetBIOS Browsing Console.

Thank you for listening to my presentation today.

Otto Cate: Great. Thank you very much for the presentation, Tim. Before we jump into the Q&A portion of the Support WebCast, I would like to share a couple of quick program notes with our listeners. If you'd like to have a copy of the PowerPoint® slides, they are available for download from the Web site at support.microsoft.com/webcasts, along with the on-demand streaming archive.

The Q&A portion of the Support WebCast is really intended to encourage further discussion of the topic that we addressed today. In addition, one-on-one product support issues are really outside the scope of what we're able to address. So if you do find that you need some more complex technical assistance, feel free to submit an incident on the Web or contact Product Support Services directly and speak to a Support Professional.

With that, let's go ahead and jump into these questions. It looks like we've gotten a few so far.

The first one is as follows: Is there a backup master browser if there are less than 32 PCs on the network segment?

Tim: Good question and the answer should be yes. There should always be a master browser and a backup master browser for every 32 PCs. If you have less than 32 PCs on a segment, you should have a segment master browser, as well as one backup master browser. Then, as you crest 32 PCs and get larger on that segment, another backup master browser will be added. Good question.

Otto: Next question: On one segment there are machines from two different domains. Are there going to be two master browsers for each domain or just one master browser for both of those domains?

Tim: That's another good question. In theory what should happen is the segment master browser goes ahead and gets a list of all of the resources on that segment that belong to its domain. As well, that segment master browser will collect the names of other domains that are on that segment. So it will supply the domain master browser with a list of domain resources that are on its segment, as well as the names of other domains where resources happen to reside on that segment.

It is possible that a second master browser for the other domain may well exist on the IP subnet. It really depends on the nature of the IP subnet. To give you kind of a convoluted scenario that we see sometimes, a customer goes ahead and creates a Super-Scope in DHCP (Dynamic Host Configuration Protocol), which allocates IP address leases out to a given physical subnet, but the IP addresses, let's say, use three different ranges, a 10. range, a 192 range and, let's say, a 172 range all on the same subnet. That's fine. We're combining different IP subnets on the same physical subnet. In a situation like that you would expect that there would be at least three segment master browsers, one for each IP subnet.

To answer the question, yes, it is possible that you'll have multiple segment master browsers on the same subnet. It depends on many different factors.

Otto: The next question, speaking of subnets: Is it a problem if the agent is running on more than one host per subnet?

Tim: No, not at all. You could have the agent running on as many systems as you wanted really. Basically what happens is the console will use only one agent per subnet for communication, so if you run the console from multiple places on your network and you want to have multiple agents on subnets, that's fine. It's not a big deal, but all you really have to do is run it on a single machine, on a subnet. What the agent does is it finds the segment master browser and the backup master browsers on that segment, and then the console will communicate with those browsers directly. The agent plays a big role in identifying those systems. We can't easily do that across subnets, and then the console takes over from there.

Otto: The next question: You had mentioned that this was for NT, but we're wondering if this also applies to Windows 2000?

Tim: Yes, absolutely. The NetBIOS Browsing infrastructure was updated between the days of LANMAN 1.0 Windows for Workgroups. It was heavily updated for Windows NT 4.0. From NT 4.0 on, the NetBIOS Browsing infrastructure has changed very little. NetBIOS Browsing has been implemented in NT 4.0, Windows 2000, XP, Windows Server 2003, and possibly beyond. The NetBIOS Browsing Console will run on NT 4.0, Windows 2000, Windows Server 2003, and Windows XP, as I mentioned earlier. So the answer is yes.

Otto: What happens in a pure DNS environment, such as found in an Active Directory® network that doesn't happen to use WINS? Does Browsing still work and is it even needed?

Tim: Right. That's a good question. The short answer is Browsing, if it is a wide area network with multiple segments and you don't have a WINS infrastructure, Browsing will be broken. NetBIOS name resolution is absolutely required for Browsing to work in a multi-segment environment.

As far as Active Directory goes in DNS, DNS is the cornerstone of the Active Directory and is a requirement for Active Directory to run. Active Directory is really meant to be the replacement for NetBIOS Browsing, and NetBIOS Browsing has been included in products where Active Directory has been implemented just for backward compatibility.

Our customers generally love NetBIOS Browsing and that's why it's included in the product, so yes, AD is supposed to really replace NetBIOS Browsing, but in a pure DNS environment with no WINS and no Lmhost files, no name resolution infrastructure, browsing is going to be very, very poor. It is required for browsing in a multi-segment environment, as I mentioned.

Otto: Here is an interesting question: Can the Browsing Console be used for workgroup troubleshooting as well?

Tim: You know, it can, but it was never designed for that purpose. I work in Enterprise Platform Support, which deals with professional customers as well as premier customers, and in that space you get very, very few people calling us that run workgroups anymore. Everyone wants the advantage that domains provide. The tool is really designed with domains infrastructure in mind, but it can potentially help in a workgroup environment.

Some of the problems that you're going to run into when you try to troubleshoot Browsing in a workgroup environment is the fact that there is no PDC or no domain master browser to speak of. The way that Browsing works in a workgroup is slightly different from that in a domain, and the approach that you take for troubleshooting is going to be slightly different as well.

Yes, Browcon.exe or the NetBIOS Browsing Console can add some value in troubleshooting workgroup scenarios, but it really wasn't designed to do that.

Otto: Now I am not sure if we had addressed this question with the very first one that we hit regarding the 32 PCs on the network segment, but the question is: What happens if you don't have enough backup browsers, 32 per segment?

Tim: It depends on the scenario. If you don't have enough backup master browsers, what's really supposed to happen here, is that the backup master browsers have fault tolerance, as well as sort of a load sharing. What happens is when a client wants to access a browse list, it goes ahead and finds who the master browser is on that segment and asks the master browser for a list of backup browsers. Now if there's not that many backup master browsers on the network what will end up happening is any backup master browsers that are on that segment will be provided to the client, as well as the segment master browser will include its own name in that list of backup master browsers, and it usually does anyway. What ends up happening is the client gets a list. The client typically only uses three of those servers in the list anyway. If the list is very, very large, the client will go ahead and pick three and then randomly use that list to request a browse list from.

What could potentially happen? You could have some performance issues. You could have some failures if the servers are not shut down properly on the network or if you're having problems with browsing elections on a segment. There could be lots of different things that would happen, but it really, generally speaking, is not that big of a deal if you don't have exactly the right number of backup master browsers. It's simply there to provide fault tolerance and a little bit of performance.

Otto: Where can we download the tool? Is that link available on the "Additional Resources" slide by any chance?

Tim: You bet. The link is actually not included on that slide. {Editor’s note: Slide 30 has been updated to include the link.} If you go to the Knowledge Base and look up KB article 818092, it's an article that describes the NetBIOS Browsing Console. There is link inside that article where you can download the tool. Again, that was 818092. If you go to the Knowledge Base or just go up to http://support.microsoft.com and do a search on Browcon.exe or NetBIOS Browsing Console (using the exact phrase option when you query), you will get a hit and that will be the article. There is only one article. That will be really easy to find. Just click on that article, go inside of it. Near the top of the article there is a link that allows you to download the tool.

Otto: Great. Thank you. The next question: Is it a good idea to turn off the Browser service on laptop computers that connect from many locations in many different ways?

Tim: That's actually a really good question. My response to that, given all of the troubleshooting that I have had to do with NetBIOS Browsing is I am a big fan of reducing the number of services that machines use, not only from a security perspective, but just from a general manageability perspective. I wouldn't be scared to disable the Computer Browser service on any system, especially desktop systems in a big corporate environment. You want to use the Computer Browser service in more of a strategic way than every system on a network running it.

That said, you may have some application compatibility issues, applications that require the use of the Computer Browser service. So I don't want you to go off and start disabling it on all of the systems in your network, but PSS support engineers have helped customers greatly by reducing the number of systems on a subnet that actually run the Computer Browser service where you can actually do that, where it's applicable. That really helps troubleshoot and helps maintain a nice healthy browser infrastructure, because really, servers are the best potential browsers. Those are the systems that you want involved in browsing elections unless you have segments that don't have servers, but that simply have desktop operating systems, you don't want your desktops running the Computer Browser service unless they have to.

I think strategic use of the Computer Browser service and the two registry values that I mentioned during the presentation are really important. You can architect your own browsing infrastructure and that way when things go wrong with it, you already know the systems that should be involved in browsing on those subjects, and it makes it very easy to maintain and troubleshoot in that type of scenario.

Otto: In the absence of WINS in a single-subnet scenario are the identities of master and backup browsers resolved by broadcast?

Tim: Yes, they are. The systems, as they come online, they do announcements and they register themselves in the network using UDP datagrams. Some of the datagrams are going to be unicast to the PDC or the domain master browser, and some of the datagrams are going to be broadcast so that other systems on a segment can see them.

Yes, if you have a single segment, WINS is not required, but if you have multiple segments WINS is definitely required.

Otto: Can you describe the various ways that SAMBA servers participate in Browsing and how you can force a Windows machine to win the election no matter what?

Tim: That's a good question. From time to time we have customers call us with issues with SAMBA servers. I am not that familiar with SAMBA or their implementation of NetBIOS Browsing, but I have been involved in cases where a SAMBA server interferes with the NetBIOS Browser election process.

That said, I really can't comment on SAMBA because I am not that familiar with it, but as far as using the registry values I mentioned to control the infrastructure, so you can go and use the MaintainServerList value or IsDomainMaster values to determine what systems you want involved on a browsing infrastructure and what systems you don't.

If you go and change the MaintainServerList value, that basically is almost like shutting off the Computer Browser service. You are basically telling the Computer Browser service, which will continue to run, that you don't want it to maintain a list; therefore, you don't want it to participate in browsing elections. If you go around and change that registry value on enough systems on a subnet, you are pretty much architecting a browsing infrastructure on that subnet dictating which systems participate in elections, which really biases a particular system's chance to win the election and become the master browser on that segment.

Otto: What is the recommended browser server configuration in a VLAN (Virtual Local Area Network) environment? We have a separate server VLAN and desktops are in VLANs according to what building floor they're on.

Tim: VLANs generally are kind of synonymous with separate IP subnets, so you can configure VLANs in many different ways. But in general, if you think about a particular segment as an IP collision domain that's really what you want to architect your browsing infrastructure around. So if you have VLAN set up and you have multiple VLANs for each browsing collision domain that's basically where you're going to have your segment master browser. Whether it's VLANs or physical equipment, however you are segmenting your network, that's basically how you want to try to architect your browsing infrastructure. If you've got a bunch of VLANs, each one of those VLANs or broadcast collision domains should have their own little browsing infrastructure; so one segment master browser, one backup master browser for every 32 systems on that subnet.

Otto: Great. The next question: What ports are required for communication between all of the master browsing roles?

Tim: Good question. Essentially, you've got two ports that are used for NetBIOS communication as far as browsing goes, and that's UDP port 137 and UDP port 138. UDP port 137 will be used to communicate with the WINS server and do name registrations on the network. UDP port 138 will be used to do NetBIOS name announcements and the like on local segments and to communicate with master browsers and that sort of thing.

Otto: Next question: If you have WINS on your network and your clients are all pointed to it, don't the clients use the WINS server for resolution and not the browser systems, assuming that the clients are set up correctly via an option there in DHCP?

Tim: Excellent question. That's a great question. When customers call us with browsing issues, depending on how savvy they are, a lot of times customers make that assumption, "If I see the computer's name in WINS, why can't I browse to it?" The short answer to that question is no. WINS is not the infrastructure that populates browse lists in your application, so Network Neighborhood, that list is not populated by WINS. That list is populated using the Computer Browser service and all of the infrastructure that we talked about during the presentation. WINS facilitates name resolution only.

To give you an example, the Computer Browser service and the browser infrastructure that we discussed during the presentation is used to collect lists and merge lists of all of the resources on a network. So we're talking about computers, printers, domains, workgroups, et cetera. It basically populates lists so that those lists can be presented to the user. For instance, you open up Network Neighborhood, you go ahead and navigate through the network to a particular system on the network. You double-click on that system in Network Neighborhood. Now WINS is being used. WINS is being used to resolve the name of that system that you double-clicked on to an IP address. Now that your server or the client that you're on has the IP address of the server that you're trying to connect to, the regular TCP/IP transport mechanism is used to connect. So for instance, the three-way handshake using TCP to the IP address that we got from WINS; then whether we're doing RPC, SMB, whatever we're doing, higher level protocols takeover.

It's a really good question because it's a really common misconception that WINS populates the list. Again, WINS is used to resolve the name that we find in the list to an IP address, but it is not used to populate those lists.

Otto: Is there any limitation to the size of the segment, number of devices? If so, what type of problems might arise with a large segment consisting of, let's say, thousands of devices?

Tim: I think as far as browsing goes, you can run into some problems in which you get into very large segment sizes. The same can be said for almost anything. By the time you get into really, really large segments you're going to start having some contention problems on that segment unless it's really well managed. But in general, the types of problems you can see in the context of the NetBIOS Browsing are what I like to call browser wars, where multiple systems claim that they've won a browsing election and want to maintain or hold the role of segment master browser. So situations where servers are arguing constantly about who is the segment master browser, and you can see those events being logged in the NT and Windows 2000 event logs where a system says it's the master browser, but it's not, I am the master browser, and so on and so forth. Once you get into really, really large segments, you get computers arguing about who the master browser is many times.

The other thing is we see that forwarding UDP port 137 and UDP port 138 traffic between segments, which is almost like creating one big segment, as this particular individual is asking about, is a bad idea because that causes all sorts of problems where, again, multiple systems claim that they're the segment master browser and they only end up tracking portions of lists.

The other thing to keep in mind with really large segments is that NetBIOS Browsing is protocol dependent, as well as interface dependent. Now what does this mean? Let's say you have a network that runs three different protocols. That means that the segment master browser on that segment keeps track of three different browse lists. This is really important to understand because the reason why this works this way is you don't want a client that, let's say, runs NetBEUI (NetBIOS Enhanced User Interface) to try to connect to a client that runs only TCP/IP or runs only IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange). The idea, by keeping lists by protocol, is that when you double-click on a resource and you want to connect to it, you're going to connect to that resource using a protocol that that resource is using. It tries to avoid having multiple protocol issues. That was probably more important in the past when networks ran two or three protocols and that's just the way it was. Today we're seeing more homogeneous IPv4 networks and now we're starting the emergence of IPv6.

Otto: I'm not sure if we addressed this a little earlier, but I'm going to go ahead and throw this out here just in case: Does a domain controller need to be a segment or backup browser?

Tim: Typically what ends up happening is the domain controller becomes the domain master browser; it becomes the segment master browser on the segment where it's actually located; and depending on the size of the segment, its name typically gets thrown into the list of backup master browsers, so that when clients go ahead and ask for a list of backup master browsers because they want the browse list, the PDC's name ends up in that list anyway because, quite honestly, we can get a list of resources from it just like any other browser.

Otto: Any known issues with browsing on a network where the IPX protocol is present?

Tim: Yes. NetBIOS Browsing can work in an IPX/SPX environment. That shouldn't be a problem and you run into some of the same issues you do in an IP environment. The NetBIOS Browsing Console was designed specifically for an IPv4 environment, so if you have a network out there where you're trying to troubleshoot NetBIOS Browsing issues and the only protocol on the network is IPX/SPX, the NetBIOS Browsing Console won't help you because it wasn't designed to do that.

Otto: Let's say you have only three PCs on a subnet and each actually belongs to a different workgroup. How would the browser assignment stack up? In addition, would you get any browser errors or warnings there in the event log?

Tim: What will probably happen is those three systems are in different workgroups, so when they come up they'll announce themselves, their computer names, as well as the workgroup name. The actual workgroup isn't populated until someone clicks on it in Network Neighborhood, for instance. So they double-click on the workgroup, and then all of the sudden the name of the systems inside that workgroup would get populated. So in a case of three workgroups on the same subnet it shouldn't be a problem.

Otto: Can the agent be set to run as a service?

Tim: No. I specifically stayed away from the service concept because when I originally planned this utility, I thought lots of customers have subnets where only Windows 95 or Windows 98 or Windows Me clients run, and in those particular operating systems implementing a service is not going to happen. I decided to leave it as a little application. If a customer wants to implement it as a service, there is a utility in, I believe it's the resource kit, as opposed to the support tools. It's called Srvany.exe. That utility has been around for a long time. It basically allows you to take an application like the NetBIOS Browsing Console Agent and turn it into a service.

Otto: Great. Any known conflicts with the agent on a network that's running Novell?

Tim: None that I know of. I haven't done a whole bunch of testing on a Novell network. One of the cool things about the agent is you can actually specify what port you want to have console connections connect to it on. I did this because in a lot of environments customers are now changing the ACLs on their routers and they're more security conscious, so they're only going to allow certain ports access from segment to segment. Instead of hard-coding a TCP port number, by default it uses a really high port number, 49911, I believe, which is neither a well-known port nor a registered port. It's up in the non-registered range. By default it will use a high port like that so it shouldn't conflict with any other ports, but our routers between segments are going to allow you to communicate to that port number. In some environments, yes; in other environments, probably not. What you can use is the /P option on the agent and specify a port like, let's say, 53, which is a very common port inside infrastructures because that's the port that, for instance, DNS name queries use.

Then the console will connect to that port using port 53 instead of the default of 49911 and we don't have to change the infrastructure in order to troubleshoot using the console and the agent. But as far as the NetWare environment goes, I have not heard any reports of any conflicts yet.

Otto: If the Browsing Console Agent is not placed in every subnet, will the console receive any incomplete information?

Tim: It could. The agent only needs to be run on subnets that we're actually troubleshooting, so it depends on how you're going to roll this thing out. If you want to roll it out so that you can troubleshoot a NetBIOS Browsing issue any time, anywhere, you run the agent on one system per subnet and kind of forget about it. That was sort of the concept. But really, you don't need to run it on every subnet, only subnets where we're troubleshooting. So instead of having to have someone walk out to a building somewhere with a remote subnet to run Browstat commands and tell us what the commands are or e-mail us the output from those commands, you simply run the application on one machine over in that subnet, and then the console is able to communicate with it.

After we finish the troubleshooting, you can shut down the agent so that it's not running. Some people like to minimize the number of services running on systems inside their network for security reasons. They can shut down the agent so it's not running and simply start it up whenever they need to when they're doing troubleshooting.

One of the other things I built into the agent was the ability to specify the name and/or IP address of the console that it should accept connections from. This is sort of as a really rudimentary security feature so that, if you did leave an agent running on subnets all of the time, at least you would have some rudimentary security. This is where not just any system could connect to that listening port, where connections from the console would be accepted, and where connections from other systems would be rejected.

Otto: What do you use to troubleshoot Windows 98 environments?

Tim: Good question. Windows 98, in my cluster in EPS Platform Support, I specialize in server support so I don't have very much experience at the desktop. When we do have customers call in that have browsing issues in Windows 9x environments, we try to run Browstat from an NT system or a 2000 system in that environment simply because it's the best tool that you have to troubleshoot those types of issues. Incidentally, Browstat does require NT 4.0 or later operating system. If you don't have an NT 4.0 or later operating system in order to run Browstat.exe from, it becomes very difficult to troubleshoot browsing issues in a pure Windows 9x environment.

That said, the guys that work in desktop support, I'm sure, have all sorts of ways to determine what's going on there. One of the ways that comes to my mind is using Network Monitor, so essentially going ahead and installing NetMon version 1.0 on a Windows 9x client and then capturing the browsing traffic and trying to make a determination of what's wrong using Network Monitor.

Otto: Can the console and the agent run on the same machine?

Tim: They can, but there's really no point to do that because the console has an agent built into it. It essentially does all of the functions that an agent would anyway for the local subnet. You don't have to deploy the agent anywhere on the same subnet as the console, simply because the console really is an agent in and of itself.

Otto: If a workstation is unable to contact a master browser or a domain master browser and the Computer Browser service is disabled, will it then use WINS instead?

Tim: Again, we're talking about two different things there. What has to happen is, depending on the application you're using, the application presents the user a list of resources it can connect to. That list is populated using NetBIOS Browsing. If NetBIOS Browsing is broken on the subnet, that list will either be partially correct or could potentially be completely empty. Depending on how broken browsing is, that list is going to be more or less complete.

WINS comes into play when we actually try to connect to a computer name and at that point we're doing something completely different. We're doing NetBIOS name resolution. WINS is used to resolve the name that we specified to an IP address so that we can make a connection via the Server service on the remote side of the connection, so they're two different things. But again, WINS is not used to populate the list that you see in Network Neighborhood. Microsoft Word was another example I've used, or any of those other applications that I put on the third or fourth slide in the presentation.

Otto: Would a segment master browser be elected if the segment contains a domain master browser?

Tim: Typically, the domain master browser is the segment master browser on the segment where it resides. So it would appoint backup master browsers, but typically it's the same system that's the domain master browser and the segment master browser.

Otto: Can the console be run through Terminal Services?

Tim: Yes. That shouldn't be a problem. It will run like any other Windows application. If you've got a terminal session open to a system and you run the console on that remote system, it will do the screen refreshes on your terminal connection and you'll see what the result is. In fact, when I tested this utility in the lab, I tested it from my desk using a terminal server connection, so it's been well-tested using Terminal Server and I didn't run into any problems with that.

Otto: Should I turn off the Computer Browser on a standalone IIS server that's only used for FTP and serving up Web pages for security purposes?

Tim: Absolutely. Out there on Microsoft.com we do have Windows hardening guides, for instance, a Windows 2000 Security Hardening Guide that I would recommend everyone use to try to harden their systems. So in the case of an IIS server that simply serves Internet-facing content via FTP or a Web service, their Computer Browser service doesn't provide any function, for instance, if that machine is inside a DMZ (demilitarized zone; also known as perimeter network, and screened subnet) or something like this. We know the name of that server if we want to manage it; so browsing is really not an issue. I would minimize the number of services running on that server just to minimize the attack surface that attackers have in order to get to that server.

Otto: Can NetBIOS name resolution occur without effective browsing support, for instance, in a remote subnet that's supported within a Windows 2000 AD DNS environment that doesn't have WINS involved? Will NetBIOS itself break or will the major loss be to Network Neighborhood and similar services?

Tim: I think we're asking two different questions. Number one, browsing is not required in that instance. If you were to go to your desktop and click on the Start button, go to Run and put in \\servername\sharename, we're not using browsing there because we're actually specifying a computer name. All we're going to do there is try to resolve that name using regular name resolution techniques, so WINS, Lmhost file, host file DNS, broadcast, NetBIOS cache, etc. and we're going to try to resolve that name to an IP address, and then make a connection to the, let's say, SMB service on that server using TCP.

The other equation there is whether WINS is really necessary, and this is another popular question that's been around since before we shipped Windows 2000. Is WINS really necessary? What I encourage people to do is see how necessary it is in their environment is. So if you're thinking about pulling the plug on you WINS server, what you should do is check performance counters. When you install WINS on a server, WINS performance counters are also installed. You use those performance counters in Performance Monitor to see just how many queries your WINS servers are receiving from clients, how many are successful, how many are failed, and so on and so forth. You get a really good indication of how many clients are still trying to use WINS for name resolution.

If you're using DNS, again, I recorded a client-side name resolution Support WebCast probably a couple of years ago already that I know is still on-line. If you go up to Microsoft.com and simply do a search on Tim Rains, which is my name, you will see a list of Support WebCasts there, one of which is a client-side name resolution WebCast that describes the client-side name resolution process built into Windows 2000 and how all of that works. So if you were to put in \\servername\sharename and you don't have WINS on your network, what actually happens? How does DNS take care of that particular situation? That WebCast is available on demand any time you want to watch it.

Otto: Excellent. Thank you. Is there a way to stop workgroups and rogue domains from being published in that browse list?

Tim: That's a really good question. Really, the key to securing your browse list, and browsing was really designed before all of this push for security was becoming hot, I think comes down to physical safeguards. So you physically want to stop people from being able to come in some place and plug a laptop or other device into your network. You want to stop people from being able to change their network settings and try to hijack your domain name for their laptop name. So NetBIOS name hijacking and DNS name hijacking are very, very common. In the DNS world, Windows 2000 and Windows Server 2003, we added secure dynamic updates to stop name hijacking from occurring.

In the case of NetBIOS it is a problem that they realized as well, so I believe it was NT SP5 or SP6, but they actually implemented the ability to stop name hijacking from occurring, so you can go in and make some registry changes to systems so that when someone tried to come up and register the same name that was already registered on the network it wouldn't release the name. That name was not going to be hijacked. This prevents someone from changing the name of their laptop to the name of your domain and hijacking the NetBIOS name and causing all sorts of havoc on the network.

Otto: Thank you. Is there a simple way to copy the configuration information for this new tool from one PC to another after all of that setup effort has been made?

Tim: You bet. That's a great question. There's an .ini file that gets created. Just go to the directory that you installed the NetBIOS Browsing Console in, I think by default it goes into \Program Files\Microsoft\NetBIOS Browsing Console. In there you'll find an .ini file. I believe it's called Browcon.ini. That's where all of the changes that you make to your network profile are kept. It's just a text file like any other .ini file, so it's not writing anything to the registry. This makes it very, very portable. You simply take that .ini file and copy it onto another machine running the console and you instantly have your network profile. When the console starts up, if it doesn't detect that .ini file, that's when the wizard starts up that takes you through the whole process. If that .ini file is detected, it simply goes and reads the .ini file, makes sure it's a valid .ini file, and then loads up the information in the console.

Otto: What could cause a domain to be listed twice in a browse list?

Tim: To be listed twice? That's a good one. Essentially what happens is that the domain name is linked to a PDC, so each domain has a PDC. If there were two PDCs somehow, and we've seen that case before where promotions and demotions go horribly wrong and you've got two systems that think they're both PDCs; that is one way a domain could show up in a browse list twice. This happens because you have the hex 1B record in WINS, which is used to identify who the domain master browser is for a domain. You could potentially have two of those 1B records in WINS. Now I don't know how probable that is, but it's certainly within the realm of possibility.

Otto: The next question: Why is the Browsing service on by default if by being on default it causes potential problems?

Tim: It doesn't cause potential problems per se. The reason why it's on by default is when you set up your network out of the box you want to have a browsing infrastructure that's already working, so there are no extra steps that you have to take in order to enable a browsing infrastructure. Every machine simply has it running by default. When they come up, they automatically decide who the master browser on the segment is going to be. Backup master browsers are appointed as needed. It's automatic and it's dynamic and your customers don't have to worry about that infrastructure.

On small networks that's very, very true. Remember, originally this whole architecture was sort of designed back in LANMAN 1.0 days and then really revamped for multi-segment use when NT 4.0 came out.

Where potential problems come into play is where now we've got this big network that's got multiple segments, and let's say a wide area network. That's when you start to see more problems with browsing because of a requirement on something like WINS. WINS has to be healthy. WINS replication has to be working, and the complexity of the browsing infrastructure gets bigger, gets more complex all of the time. Then you add more and more PCs onto a single subnet and they start to argue about who the master browser is and you can run into some problems there. It's not necessarily true that the Computer Browser service is a source of potential problems. It's a source of potential problems in very large environments, that's true, but in most environments the idea was, "I just want to bring this thing out of the box, set it up, and have NetBIOS Browsing working immediately without taking any extra steps."

Otto: Do you have any good pointers to maybe white papers, KB articles, and best practices to design network browsing for a company that has more than a thousand computers in a wide area network environment?

Tim: That's a good question. The white paper I mentioned earlier is really, really good. It walks you through the basics to advanced knowledge of browsing, explains down to the API level how it all works, tells you about the ports you need, and tells you about how they exchange messages. There are a couple of different ways to approach an architectural design of a NetBIOS Browsing infrastructure. Some customers approach it from the point of view that they want to minimize browsing traffic on the network. They want to control network traffic more than they want to control the browsing infrastructure per se.

There is a Microsoft Press® book out there called Optimizing Network Traffic put out by MSPress. I believe it's actually written by MCS consultants who go out to customer sites. This book actually has an analysis of browsing traffic and it shows you packet by packet what's going out on the wire, and gives you really good suggestions on how to optimize that if you want to minimize the traffic or if you want to make the traffic more efficient, etc.

From a network traffic point of view, that's a really good way to go. From an architecting standpoint of how to make sure that your browsing infrastructure is healthy and you want to minimize the problems that you have with it, I'm not aware of any single document that really documents that because there are so many different ways of implementing a network. So I don't think there's any one way to do it. It really depends on what your network looks like and the applications you're using that require NetBIOS Browsing.

My own view is that you want to architect a NetBIOS Browsing infrastructure on a network so that you know which systems should win the browsing elections and which systems, when browsing goes wrong, are to blame. The NetBIOS Browsing Console is going to help you do that, but if you have intimate knowledge of which systems are responsible for browsing on a given subnet, that just makes it easier to troubleshoot when things go wrong.

The other thing is, when systems go down, if they're not shut down properly that leads to all sorts of problems. One of the nice things about the white paper, it shows you the time lags between the time a system goes down and how long it takes for the system to get removed from the browse list; if that system is a master browser, how long it takes for the election process to get triggered; all of that good stuff, because there is some latency involved here, which comes back to our last question where the individual asked about different problems with browsing and the Computer Browser service.

There is some latency involved where if the system is not shut down properly, that system is still registered on the network as up and running and it will take three browse announcement periods to go by before it gets removed from the system, and if it's a master browser there's another algorithm for that. For that type of scenario, I encourage you to read that white paper. It is the best single source of information on NetBIOS Browsing and Microsoft's implementation of it that you're going to find.

Otto: An example here: An office with browsing infrastructure set up, one remote laptop base to VPN user. I'm not about to set up a full infrastructure at his home, so we're curious how he can browse reliably. More importantly, how can other machines on the office network see his remote machine in the browse list?

Tim: Right. There are a couple of issues going on there. Typically, when a client VPNs into a network, the RRAS server that they are VPNing into, if it's a Microsoft server, is typically going to be considered the segment master browser for all of those VPN clients, and they're going to get their browse list from that server. Of course, that's not going to be true in all cases when problems occur or when a different type of browsing infrastructure is architected that may not be true. But those clients that are VPNing in there, they do need to have access to the browse list and they do need to have NetBIOS name resolution as well.

Typically, that's handled by the RRAS server that they are connecting to. So when they connect in they'll get WINS servers that the RRAS server uses and they'll get the browse list that the RRAS server has. Since it's the only server, it will be the server that wins the browsing elections on the remote subnet; it should be able to populate that list for those clients.

That said, there are plenty of problems when clients dial in and try to get browse lists via RRAS. If you go to the Knowledge Base, there are a couple of articles there that talk about that and different issues that you can run into and different ways to solve those problems.

Otto: Is it possible to use a hardware device, such as a switch or a router, as a segment browser or backup browser? The reason is that we might not have the ability to place a domain controller or server on that subnet and the average workstation is too unreliable to provide that level of service. Also, can you forward browsing requests across subnets?

Tim: Right. All very good questions. First off, I'm not familiar with any hardware-based solution that handles browse lists for a Microsoft Windows network infrastructure. There may be. I've never run into a customer that has mentioned that they're running one though.

The deal with the workstations is it's true that with end users you never know when they're going to power off the machine. You never know when, if it's a laptop, they just pick it up and take it home. Do they take your entire browsing infrastructure with them when they do something like that? What the NetBIOS Browsing white paper recommends is that you do put, at a minimum, a Windows-based server on those subnets, just one Windows-based server on those subnets. I know you're rolling your eyes saying, "I can't do that." That's what they recommend.

In the white paper you will also read that, in some instances, it makes sense to put a BDC. Once upon a time in NT 4.0, a BDC on those subnets was to ensure that the browsing elections are won by a server, and that typically servers stay up longer than clients. So the server stays up and maintains the browse list and everybody's happy. There's no easy answer in that situation where you've got subnets that are simply populated with client systems. As I mentioned, the white paper recommends putting a member server on those subnets just to maintain a nice browse list that rarely gets recycled.

Otto: What effect on browsing is had by having servers and/or workstations with multiple protocols, especially if not all machines have all of the protocols?

Tim: It's a very good question. I mentioned earlier that browsing is protocol dependent and interface dependent, so there are a couple of things going on here that are really important. We don't see this problem much anymore because everyone runs IPv4 these days, which is nice as far as browsing goes. But if you imagine a segment master browser on a segment, that segment master browser keeps a list of resources, a browse list per protocol. It also keeps a browse list per interface.

As I mentioned a couple of times in the presentation, don't use multi-homed machines for master browsers, backup master browsers, or domain master browsers. It's a recipe for disaster because when a client registers on a particular interface, only that interface knows that the client exists. Other interfaces on the same server have no knowledge of the client registration. So when requests for a browse list come to that machine, the client may or may not be returned in the browse list — it depends on which interface the request was received on. That list is the one that is kept for that one interface.

The same thing is true of protocols. A browse list will be kept, let's say, for TCP/IP and, let's say, NetBEUI. So when a client requests a list via the NetBEUI protocol, they actually get a list of systems that use NetBEUI, period. They don't get systems that use only TCP/IP, because we don't know whether the system making the request is using TCP/IP, NetBEUI, IPX/SPX, or whatever the flavor of the month is for protocols on that network.

So, it's important to realize that browse lists are kept separate per protocol and per interface. In a multi-protocol environment it makes sense, because you don't want an IP system trying to connect to a system that doesn't support IP and that's why they keep separate browse lists.

The same thing I can't stress enough, multi-homed systems break browsing. I get so many calls from customers all of the time with browsing issues where, "I only see half of the subnet," or, "An entire subnet is missing from the browse list. Why is it?" When we track it back, it's because the domain master browser, the PDC is multi-homed. Now that's a recipe for disaster not only from a browsing perspective, but also from a networking perspective. Multi-homing systems creates a lot of different problems, a lot of different problems for a lot of different services on a box. Browsing is just one of them.

Also, if customers have problems with browsing not only could it be a multi-homed PDC, but it could also be a multi-homed segment master browser. Some of the reports that you're going to see BrowCon generate will actually say, "Avoid multi-homing these systems." That's really important.

Otto: Can network browsing work across a router or between subnets if you enable NetBIOS over TCP/IP?

Tim: Yes. Enabling NetBIOS over TCP/IP is not going to buy you the ability to browse across subnets. You need a NetBIOS name resolution mechanism that is capable of going across subnets. Just enabling NetBIOS over TCP/IP doesn't give you that. You have to have WINS or else you have to have a really big Lmhost file. We do have an article out there that explains how to architect a browse list, actually manually create a browse list using an Lmhost file. I wouldn't recommend it because IP addresses change, names change, and then you have to go in and update the Lmhost files.

The best way, the most dynamic way is WINS. Somewhere along the way WINS got a bad reputation about being hard to manage or being hard to troubleshoot, and we help customers manage and troubleshoot WINS in very, very large environments and, yes, sometimes things go bad with replication because of various different reasons, but far and away WINS is the best way to enable NetBIOS name resolution across subnets, especially in a large environment. I would never hesitate to install WINS in my environment.

I just remembered, this is related to this question, but the previous question the person also asked what about enabling UDP forwarding between subnets. Those are related questions and you shouldn't do that. That will cause numerous problems in your network. You will see telltale signs of UDP forwarding in an environment. You'll see 8003 event IDs logged in your Windows systems on those subnets because they can't determine who the master browser is. The master browser on both those segments is going to be announcing itself as the master browser, and they're going to start arguing about who the master browser is and it's going to run into problems. So avoid UDP forwarding altogether.

Otto: I'm in a pure Windows 2000 environment using only DNS with no NetBIOS. Will browsing or Network Neighborhood programs no longer work?

Tim: No. The Network Neighborhood and browsing programs will still function; it's just the browse lists that will be impaired. Those applications will still make the NetServerEnum API calls to get the lists when they need them. It's just what's going to be inside those lists that get displayed to the user when it's all said and done; that's the issue here.

Again, without a NetBIOS name resolution mechanism in a multi-segment environment, how effective is browsing going to be? It's not. You need to have WINS for managing these big Lmhost files in an environment that has multiple segments. It is critical because, as I mentioned in the presentation, what has to happen here is the master browser on the segment has to find out who the domain master browser is so that it can pull down the merged list of all of the resources in the entire network.

In order to do that, it doesn't know who the domain master browser is, so what it has to do is it has to query WINS and find out who the PDC is. It does this by querying WINS for the 1B record. It uses the domain name query for the 1B record. For instance, let's say you have a domain called MyDomain. It queries WINS for the 1B record for MyDomain. What it gets back is the name of the PDC. Now we have the name of the PDC. We still need an IP address in order to connect to that PDC and get the browse list. Now I query WINS for the IP address of the PDC now that I know its name. We get back the IP address of the PDC. Now we're able to use a TCP connection to connect to that IP address end point and pull down the browse list and exchange browse lists with that master browser. Unless we have something that resolves 1B records and NetBIOS names to IP addresses, we're out of luck as far as communicating over segments. It's just not going to work.

Otto: What are the major differences between Browmon.exe and Browstat.exe and when should we use them?

Tim: That's a good question. Browmon.exe is another resource kit utility. Unlike Browstat.exe, Browman.exe does have a GUI. It's a Win32® application. Browmon.exe in troubleshooting scenarios is of limited use. In PSS we rarely use Browmon.exe to troubleshoot browsing issues where the typical symptom is that things are missing in the browse list.

Where Browmon.exe is useful is identifying who the master browsers are, the main master browsers, the subnet master browsers, and the backup master browsers. That's where Browmon.exe is very useful. How often do we use it? I can count the number of times I've used Browmon.exe on one hand to troubleshoot NetBIOS Browsing issues, and we get a lot of NetBIOS Browsing issues from customers to deal with, so I don't use it very often. I just don't find it that useful in that particular scenario where I simply want to find out why a resource is missing in the browse list.

Browstat.exe, on the other hand, is extremely powerful, but is a command-line utility with lots of switches and some customers find the output very cryptic, which leads us back to BrowCon.exe, which is the NetBIOS Browsing Console, which makes it easier to utilize Browstat.exe, because it's, again, a graphical user interface. You don't have to deal with all of these switches. A lot of the analysis is being done for you.

Otto: If a client within a LAN associates itself with a workgroup of the same name as the domain in the same LAN, will the client then assume the master browser role for its workgroup or otherwise disturb the domain browsing infrastructure?

Tim: Yes. You're going to have a NetBIOS name collision there because unlike DNS, where it's hierarchical, NetBIOS names are flat. The name space is not hierarchical. Every name in a NetBIOS name space has to be unique across your entire organization. So if you have two systems trying to register the same name you're going to have a name conflict.

This is actually one of the problems that you're going to run into when you troubleshoot NetBIOS Browsing issues is we have some resources that are missing out of the browse list. I mentioned earlier, one of the common reasons for this is multi-homed browsers. Another common reason for this is NetBIOS name conflicts on your network, so one of the things you do is go to, let's say, your PDC and you run nbtstat, which is a built-in operating system command, and you take a look at the cache. I believe it's nbtstat -c. You look at the cache, at what names are registered on the network. If you see your PDC's name is in conflict, and it will actually say, "PDC name or domain name 1B conflict," you'll know that that's the problem because the name is hijacked by someone else and you have to correct that NetBIOS name resolution issue in order to correct the whole browsing infrastructure problem that you're having.

Otto: Can frequent browser elections within a subnet cause a poor client browsing experience?

Tim: Yes, it can. I mentioned this a little earlier. You can have what I like to call browser wars, where you've got browsers constantly arguing with each other. So a browser comes up and says, "Okay, I want to be the master browser on this segment" but another system is claiming that role as well and they argue back and forth. What they do is they constantly cause browsing elections. Those symptoms will be logged in your event logs and in your Windows-based systems. You'll see that constant browser elections are happening and yes, that will cause a degraded NetBIOS Browsing experience because clients don't know who to ask for the browse list. One time when they open up Network Neighborhood they'll get a nice big complete browse list. The next time when they open it up it's completely empty or, let's say, it only has a partial list. Yes, that's a common problem.

Otto: We're getting down to the last couple of questions here. Does my server need to have Network Browsing service running in order for me to administer it using Terminal Services?

Tim: No. I don't believe Terminal Services has a requirement on the Computer Browser service and the NetBIOS Browsing Console also does not rely on the Computer Browser service. You should be able to run that NetBIOS Browsing Console on a system that has the Computer Browser service shut off. So the Computer Browser service is simply there to participate in browsing elections and to maintain and swap browsing lists with other systems.

Otto: Are the two registry values that you had mentioned the only way to affect the operation of the Browser service with respect to elections?

Tim: Yes. What they do is bias the election. If we change the MaintainServerList value to no or false, that system is not going to want to participate in a browsing election. If we change the IsDomainMaster registry value to yes, what that does is when the election happens there are specific criteria that I mentioned earlier that are used during the election. That biases the election in favor of that system with that registry value. Does that mean it's guaranteed to win? Maybe, maybe not. It depends on what the criteria are of all of the other systems on the network. What we're trying to do here is we can't hard code a system to be the master browser, per se, but we can certainly bias the browsing election in its favor to increase the likelihood that it does become the master browser on that segment.

Otto: I think we had actually already addressed this, but I'll throw it out here as a clarification. Is the Computer Browser service required for NetBIOS Browsing Console or the agent?

Tim: The answer is no. It shouldn't be required for either.

Otto: Great. I'm not sure if this is something that you're able to address. It seems to be more of a future question regarding NetBIOS. I'm going to go ahead and throw it out here just in case you can maybe give us some insight. This is a name resolution issue: Given the possible demise of NetBIOS in favor of direct hosting and DNS, do you know or can you comment on what the long-term solution for name resolution on a small peer-to-peer LAN might be with no DNA server infrastructure, given that NBT broadcasts will no longer be available when NetBIOS is no longer available?

Tim: You know, I don't have a good answer for the question. It's an excellent question and I think that the actual answer to that question is being worked on by program managers within the development groups. The program managers are the brains behind the design of these products, so I know that they are taking a very close look at that and I'm really not sure what the future direction they have planned is. I don't know if it's baked (decided) at this time. It might not be baked at this point. It might be still in the planning processes, I'm not sure. But Microsoft is committed to helping customers and I think we've proven that over time with constant backward compatibility. We understand that NetBIOS Browsing is a very important feature to many of our customers in small and large environments, so whatever the direction they plan to go with, I'm sure that they're going to take into consideration the exact scenario that you're asking about.

Otto: Excellent. With that, it appears that we've answered all of the questions that were submitted to the queue today, so I'm going to go ahead and wrap up this session.

I want to thank everyone for joining and hope that the information was useful. Of course, we want to thank Tim for coming out and giving us a great presentation as well.

Tim: Thank you for having me.

Otto: As always, if you have any suggestions for future topics, general comments about the sessions, or even the WebCast program as a whole, feel free to send e-mail to us at supweb@microsoft.com. We hope that everyone has the opportunity to tune in again soon. Thanks and have a great day.