Lars Appel wrote:
>
> Rocky,
>
> >One last thing, the PC, MONTVALE, and PARAMUS are all in separate
> >buildings, connected via routers.
>
> This is most probably the clue to the cause of the problem!
> NetBIOS browsing does not work well across subnets/routers.
>
> >I'm thinking it is either a WINS issue or a workgroup issue.
>
> I've had some success by making sure that PC and 3000 use the same
> WINS server.

You speak of "browsing" not working - I imply that you refer to the
infamous Windows "Network Neighborhood".  This is perhaps the most
misunderstood feture of Windows networking imaginable.  I can elaborate
from a network/protocol standpoint, and perhaps some our more astute
Windows administrators can elaborate on what buttons to push to get
things to work.  I primarily deal with the consequences of these
configurations after-the-fact (escalated network trouble tickets) and
leave the findings to our NT/95/98/Novell folks to tweak configuration
of the machines in question.

WINS has very little to do with the "Network Neighborhood".  On the
other hand, if you manually map a network drive using a computer name,
it has everything to do with NetBIOS name resolution.  It is entirely
possible, even probable in large networks, that you can map drives to
servers not present in the "Network Neighborhood".

The view of the "Network Neighborhood" is a combination of Novell and
Microsoft shares on your subnet (for Win95 and I think Win98) that are
on your local subnet.  Novell shares are learned through the client
startup sequence and the initial "Get Nearest Server" (GNS) request used
to find the correct network number and a routing source; the services it
learns are based on a "Get General Services" (GGS) request.
For MS shares, it listens to NetBEUI/NetBIOS name broadcasts and a whole
plethora of other MS chatter on the local segment.

The initial neighborhood may be very limited.  The "Entire Network" is
the next step - in the MS case, it goes to the "elected master browser"
to get a list of servers.  Assuming you're doing NetBIOS over TCP, this
can propagate shares from one segment to another if there are "suitable"
machines on each segment - NT machines in particular, acting as a master
browser.

The problem lies in "kludges" introduced to make peer-to-peer sharing
possible.  If Win95 is enabled for Novell sharing, it pretends to be a
Novell server, but cannot do name resolution nor provide a browser type
list of available services.  If Win95 is enabled for MS sharing, it will
pretend to be a master browser, and if no authoritative NT machine is on
the same segment, will win the "browser election" exchange, and again,
you won't get what you expect.  But in all cases, WINS hasn't yet been
touched by the client.

Now, if you enable WINS (nmbd) in Samba you can be a bit more visible
with co-operating machines on the subnet, but not necessarily "see" it.
If you have a real WINS machine that the client knows about, and it
knows about the 3000, it will be able to map a drive, though not
necessarily "see" it in the neighborhood.  If you don't have one, use
nmbd on the 3000 and you can map it (though again, maybe not see it; I
don't know the level of implementation of NetBIOS name resolution and
browser support in Samba, but I'd have my reservations about the
latter).

Bottom line - if you can't see it in the neighborhood, it's not
necessarily broken.  If you can't map it, then it is.  There are a few
dozen other variables that can interfere that I can't even begin to
explain :-)

Jeff Kell <[log in to unmask]>