User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
Brian Tully wrote:
...
The 6 Windows PCs on the network are all set up to not use a domain and
to belong to a workgroup "GSC".
On the Xserve, I have set up Windows service as "Standalone Server" and
workgroup as "GSC".
80% of the time, the Windows users can go to their Network Places and
see the "GSC" workgroup and see the Xserve within the workgroup and
connect to it.
The other 20% of the time they can not see or connect to the Xserve.
Under the Logging section of Windows Service within Server Admin I see
the following errors whenever the PCs can't connect:
Anyone know what is causing this and preventing Windows Service from
running consistently? Seems extremely unstable.
I've tried enabling/disabling the options of Workgroup Master Browser
to no avail.
Enable WINS server is selected.
Arghhh....this is the ancient problem of "browsing" in Windows. It can
happen in an all-Windows network. Fixing it is a pain, but first some
background about the NETBIOS networking at the heart of this. NETBIOS
is the legacy protocol which MS has been trying to get rid of it since
Win2K but is still the default.
...NETBIOS names
The first problem is that the NETBIOS names Windows is using are
actually *completely independent* of DNS names. Although one would
be crazy not to make them correspond, there's no requirement that
they do and no mechanism to enforce it. The namespace is a flat
15 character string which ignores case. Originally each machine self-assigned
it's names and responded to queries (which were local broadcast packets).
...browsing
The Windows NETBIOS networking was originally conceived of as a P2P net
without a central controller. In such a world, there's a question of
where the list of resources is kept so they added a "browsing" service.
Because there was no central control, they hold elections to decide
which machine holds the list of resources -- the master browser.
Obviously if the wrong machine becomes the browse master, the resource
list will be incomplete. The master browser is just another NETBIOS
name which clients query to discover. To find out which machine
the X-serve thinks is the current master browser, do:
nmblookup -M GSC
(nmblookup is a handy Samba utility for checking NETBIOS name stuff)
...WINS
By depending on broadcasts, the original NETBIOS is by design a purely
local LAN protocol which means it could not cross a subnet boundary.
The WINS service hack was added to create a central name registry which
can span subnets but without it, each subnet operates independently.
You have to specifically set up a WINS server and there can be only one.
The really bad news is that *each and every* client and server machine must
be configured to talk to the WINS server (best done via DHCP). Because
WINS is just an add-on, a machines will revert to using broadcasts
if they don't get an answer from WINS.
The result of all this is confusion. It's perfectly possible to be able
to browse resources you'll never be able to connect to (because you
lack authorization) or to be able access resource you can't browse (because
browsing is just a convenience function). Indeed, on those days when the machines
can't browse your X-Serve they could still acutally access it --- but only
if they map the share using an FQDN or the explicit IP address.
So to get this all done right:
a) set up a WINS server (can be the X-serve)
b) make sure *all* machines use the WINS server
c) make sure that only one machine can win the
election as master browser. The WINS server does not
have to be the master browser but it's more straightforward if it is.
