Go Premium for a chance to win a PS4. Enter to Win

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3404
  • Last Modified:

event id 8009 : master browser // subnetmask problem


we have our pdc in vlan A ( and our clients in Vlan B (, C, D and E. The pdc has no physial nics in the other vlans

Our clients are giving :
Event ID: 8009
Description: The browser was unable to promote itself to master browser. The computer that currently believes it is the master browser is <PDC>.

Microsoft says:
This problem occurs if the subnet mask of the Windows NT client computer is incorrect or different from the PDC. The client computer attempts to promote itself to the master browser of the subnet and fails.

Any idea how to resolve this ?
Any help is greatly appreciated,

Kind regards,
5 Solutions
Krzysztof PytkoActive Directory EngineerCommented:
Can you post here the output from a DC

dcdiag /e /c /v >c:\dcdiag.log
repadmin /showrepl /all /intersite /verbose >c:\repadmin.log
dsquery server -name * -limit 0 | dsget server -dnsname -site -isgc >>c:\dsquery.log

and attach them here. Thank you in advance

From Microsoft on troubleshooting browsing (includes issues with VLAN boundaries) ;-

Troubleshooting Browsing

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.


      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:

      Status 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>
      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>.


      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.

      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:

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

      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.

      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.

      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:

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

      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.

      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:


      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.

      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.

      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:


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.
What you are seeing is "normal" when you have multiple VLANs and you allow UDP broadcast between the VLANs. Each site should have a Master browser, but when a host in a segment starts an election, this traffic is broadcasted to the other VLANs aswell. Including the segment where the DC is.

The DC don't like this because it knows that it should be the Master. Event 8009 is logged.

If you use ip-helper, you can stop UDP broadcast.

Cisco: http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_tech_note09186a00802373f3.shtml

Additional: http://support.microsoft.com/?kbid=135464

The theory: http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/net/chptr3.mspx?mfr=true

New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

I believe you can also set in the registry that the DC is ALWAYS the Master Browser.

KOV_VZWAuthor Commented:
Hi guys,

thank you very much for all the help. I've started with the simplest thing: activating the master browser service on the Win2008R2 DC. Didn't know that it was off by default.

II'll wait and see what's coming of this
KOV_VZWAuthor Commented:
Thanks for helping out
problem solved with the activation of the master browser service
KOV_VZWAuthor Commented:
problem solved

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now