Link to home
Start Free TrialLog in
Avatar of miket71
miket71Flag for United States of America

asked on

MrxSmb Event 8003

Hello,

We have been receiving the following errors on what we think should be the master browser server because it holds all 5 FSMO roles:

The master browser has received a server announcement from the computer [several SERVERNAMES in the domain] that believes that it is the master browser for the domain on transport NetBT_Tcpip_{0A9AA15E-6DCD-4A91. The master browser is stopping or an election is being forced.

We have been checking the following path on all of the domain controllers:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters

IsDomainMaster is set to FALSE on all of the DCs, as well as the FSMO role holder, so we changed it to TRUE so at least one DC is the master.  After all this time, none of the servers have been the master.  Hopefully these errors will stop now.  After making the change, we restarted the Computer Browser service on that DC.

MaintainServerList is set to YES on all of the DCs.  The other choices are AUTO and NO.  I guess they should stay at YES since that's how we fond them, but we are wondering what the difference is between YES and AUTO.  I'm guessing NO would be used for a special circumstance.

Any further questions, comments, or help would be appreciated.

Thanks,
Mike
Avatar of Jeremy Weisinger
Jeremy Weisinger

From MS:
Yes = Specifies that the computer will become a master or backup browser.

No = Specifies that the computer cannot become a master or backup browser.

Auto = Specifies that the computer can become a master or backup browser if needed, that is, if there is no master browser on the subnet or there are not enough master browsers on the subnet. This is the default value.

http://technet2.microsoft.com/WindowsVista/en/library/931ffbc5-4a9b-44ca-a71f-fa3702e8f6081033.mspx?mfr=true


And to learn all you'd want to know about the browser service and elections, see this: http://www.microsoft.com/technet/network/evaluate/technol/tcpipfund/tcpipfund_appc.mspx
Avatar of miket71

ASKER

All of our DCs here are set to Yes, so I'm wondering why they ended up with a Yes setting versus an Auto setting if Auto is the default value.  If Auto is recommended, I could put all of them to Auto while leaving the Master set to TRUE as explained below.

I also check the event log of the Master Browser domain controller with has since been set to TRUE from FALSE, and I'm still getting errors stating that other DCs are trying to announce themselves as a Master Browser.  I'm wondering if I have to restart the Computer Browser service on those machines where the errors are coming from.  All of the other DCs are still FALSE for the IsDomainMaster setting.  There has to be at least one DC set to TRUE, correct?
ASKER CERTIFIED SOLUTION
Avatar of Jeremy Weisinger
Jeremy Weisinger

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of miket71

ASKER

Okay then.  I'll try setting all the DCs to TRUE from FALSE for IsDomainMaster.  Maybe I am confused on this one though.  Wouldn't setting all DCs to TRUE make them fight with each other to be the master then?  Or will they see that there is a master and gracefully stop electing, only to attept again later?

I'll also set all the other DCs from YES to AUTO for the election, while leaving the master browser DC set to YES.
Those settings should be fine but I'm not sure that we're tackling the issue that's causing the error.

In the error, is it always one of the DCs that is listed? Or is it other servers too? Have you checked the eventid.net link I posted? One of the first things I'd check would be to make sure all the servers (and clients) have the correct subnet mask.
Avatar of miket71

ASKER

Okay, after going back further in time on the DC that is supposed to be the master browser and 5 FSMO role holder, I have only been coming across 5 other DCs in it's logs that keep wanting to elect themself as the master browser.  The remaining 9 servers don't show up in the system log for event 8003.  We have 14 DCs total.  I confirmed that the servers all have the correct full class C subnet on them.  PCs that are in the same subnets as those servers will take a little more time to review though, but if it is at least one PC in the same subnet as the server showing up in the log, is it then the possible incorrect subnet mask of the PC that is making the server try to elect itself as the master?

I'm also reviewing the link that you suggested.
Avatar of miket71

ASKER

Update:  On the main 5 role holder/master browser server, we continued to get MrxSmb errors on behalf of other remote DCs in the WAN that were trying to become the master browser.  Only half of the total DCs out there were making the attempt though.  Others were not.  We disabled NetBIOS over TCP/IP earlier this past weekend to give it some time and see what that would do, and the errors went away.  We have NetBIOS over TCP/IP set to default on all other remote DCs though, so we're not sure why turning it off on the master DC causes the errors to go away.
Sorry for the long delay. I was/am super busy at work and I went away for a few days.

The computer browser functions through NetBIOS. Disabling NetBT would stop the errors. But is your DC functioning properly? There's a lot of things that use NetBIOS (like file and print sharing).

Do you use WINS?
Any multihomed DCs?
Avatar of miket71

ASKER

No problem.  I was out for a week also.  The main DC appears to be functioning normally still.  There is another DC in the same subnet as the main one.  All other subnets have at least one DC as well.  For DNS, we have it set to append the domain name suffix so that we can ping anywhere by NetBIOS name only without having to type in the whole FQDN.  In DHCP, we use the 015 DNS entry for the domain name suffix as well so DHCP clients automatically get that setting when they are given an IP address.  The main DC doesn't do any file/printer sharing other than DC related sharing.  We don't use WINS.  Thanks.