[718] in winnt
Re: Windows NetWork Neighborhood
daemon@ATHENA.MIT.EDU (Kerem B. Limon)
Wed Sep 19 13:13:23 2001
Message-Id: <4.2.2.20010918171719.0306b878@PO11.MIT.EDU>
Date: Wed, 19 Sep 2001 13:13:01 -0400
To: Dave Broderick <djbroder@MIT.Edu>
From: "Kerem B. Limon" <Kerem.Limon@MIT.EDU>
Cc: "Christopher Tresco" <ctresco@economics.mit.edu>, winpartners@MIT.Edu,
jaglogow@MIT.Edu
In-Reply-To: <200109181942.PAA16507@melbourne-city-street.mit.edu>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_91948314==_.ALT"
--=====================_91948314==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hello--
You seem to be all confusing "seeing machines on the network" (and
specifically in the original context, "in the Network Neighborhood") with
seeing files and shares, once connected to a machine. :)
These are very extensive and open-ended questions that involve--what is
commonly referred to as--"Windows Networking" and how it inter-operates
with TCP/IP and other protocols. They also involve what is often seen as
the only means to access Windows Networking: the "Network Neighborhood" or
"My Network Places"--they really are not.
I will try not to delve into Windows Networking too much; it will get too
complicated too quickly, as it both inter-operates with TCP/IP and
otherwise "piggy backs" its own on some TCP/IP mechanisms to operate.
Instead, I'll try to explain very symbolically how it works and then offer
some practical suggestions.
The fundamental problem is the following: We have a "source" machine from
which we want to locate (on the network) a "target" machine, connect to it,
authenticate ourselves if necessary, and access shares/share points (shared
file and folder containers, printers, etc.). Microsoft has incorporated
into Windows versions an interface component known as the "Network
Neighborhood" or "My Network Places". This is a graphical interface to the
"locating" process mentioned above. It is not the only means, however, to
"locate" other machines doing Windows Networking, and is not "thorough" in
terms of what and how it can locate. Because of these and its prominent
default place on the Desktop, it is often a source of great confusion to users.
Windows Networking, through which Network Neighborhood operates, uses a
number of different means to _locate_ a target machine to connect to from a
source machine--technically referred to as the "NetBIOS node type". Some of
these means involve a "broadcast" mechanism where, essentially, the machine
transmits broadly over the LAN (the subnet the source machine is on, in our
case) calling for the target machine, awaiting and listening for it to
respond. Other means involve some kind of name resolution (that may or may
not use DNS) and then a direct addressing of the target machine, via its IP
address.
In most default Windows configurations, especially if the machines were
installed/configured disparately out-of-the-box and then made to gather in
a workgroup or LAN, locating the target machine attempt often starts with a
broadcast approach by default and upon failing, switches to a direct,
point-to-point addressing--only if the name resolution mechanisms are
configured properly, as often is not the case.
There are additional criteria for the broadcast mechanism to work and it
often is time consuming since target machines need to be "discovered".
Microsoft has specified very complex--if not confusing--"order of
speaking/responding" rules for machines on a subnet/LAN, all simultaneously
wanting to use Windows Networking. This usually involves, quite literally,
the "election" of a "browse master" and backup "browsers"--machines who
keep track of Windows Networking capable machines on that subnet/LAN as
they come and go. Of course, due to this complexity and the broadcast
mechanism, this list the browse master keeps is dynamic and often lags
behind compared to the machines physically appearing and disappearing on
and off the subnet/LAN--up to 12 minutes sometimes.
The moral of the story here is, Network Neigborhood or My Network
Places--unless configured very carefully on a workgroup/network/NT- or
2000-domain level--will not necessarily be a reliable method of getting to
other Windows machines sharing data. This is particularly more complicated
when we need to go across routers, where additional complications and
Microsoft/Windows Networking rules surface.
Having hopefully clarified/listed some of these caveats, what follows are
some suggestions to Joe's original inquiry.
First of all, if possible, I'd recommend a client/server model for file
sharing over a peer-to-peer approach like Joe's, as I understand him to
imply. This does not necessarily imply using NT 4 or 2000 Server, but
rather indicates there is one or two (few) machines that act as "servers"
where the sahred data are pooled and the rest are "clients" that connect to
these specific machines to access those data. Depending on the volume of
data sharing, number of client machines, and frequency of access, the
"server" machines _may_ double as workstations, but I'd not recommend it if
you can avoid it.
I do not have a grudge against peer-to-peer; my reasons for recommending
are simple and pragmatic:
- A client/server model is easier to interpret and administer--there is one
(or few) machine(s) where the data is kept, so there is no question of "who
connects to what machine to get what" or concern over the availability of
each peer machine.
- Windows security is an ongoing source of concern, especially at MIT, and
securing one, single type of machine--the "server"--is often easier than
securing each of the heterogeneous Windows flavors acting as peers.
This does not mean you should not be concerned about securing individual
workstations, though.
- If you have access to NT 4 Server or 2000 Server, you have access to
Microsoft tools (such as an NT/2000 Domain) setup that can help you in
streamlining user/password/permissions/etc. management compared to that of
a peer-to-peer setup.
- You are likely to ease the traffic on your subnet with a designated
"server" and "clients" connecting to it, rather than a combination of
multiple interconnected sessions among peer-to-peer clients. Windows
Networking can be very demanding on a subnet under certain conditions (such
as during large file transfers), and it is best if you minimize the
connections for better performance for all.
Second, I would suggest deciding on a mechanism by which the machines will
"locate" the server for Windows networking and so users can connect. This
is best achieved by either a "proper" means of name resolution (e.g. you
enter the TCP/IP hostname or the "Windows Name" of the machine somewhere
appropriate and it gets properly resolved to an IP address, and Windows
subsequently connects to it over TCP/IP), OR by a simple logon script or
the like each user runs on their client machine that simply refers to the
"server" via its IP address. I can provide specific assistance to those
interested, including Joe, separately as this is already running quite long.
Windows 2000 comes configured "smarter" in these terms by default, compared
to NT 4 and 9x/ME series. That is probably why Joe had a better experience
with 2000 clients.
Third, I would try to standardize on a few--if not just one--Windows
platforms, if at all possible; things will run smoother and updates and
maintenance will be less diverse. But, there is nothing holding you back
from using one Windows OS with another, though there are caveats here and
there. It is a matter of manageability and overall cost. Depending on
driver availability and vendor support, MIT's licensing agreements for NT4
and 2000 may be economical and useful in these cases.
I can discuss this further if there is interest or deal with individually.
Cheers,
Kerem
PS: <disclaimer> I am a member of I/S, the Computing Help Desk and Software
Release Teams, but this is not an official recommendation or indication of
support on part of I/S; rather my own professional opinion. </disclaimer>
At 15.42 2001/09/18 -0400, Dave Broderick wrote:
>When you connect to another Windows machine, you can see ALL files on it,
>(if you have permissions).
>If I have a Win95 machine, I can log on to an NTFS machine and see all of
>its files. I do this every day. I have a network with Win2k, WinNT, Win98,
>and Win95 machines.
>
>When you access another machine on a network, the other machine is showing
>you its files, so the file system is irrelevant between Windows platforms
>(assumes you are authenticated as user). My old Win 95 machine says "Can I
>see your files?" If the Win2K host says "OK", then all file system stuf is
>managed by the host machine.
>
>The only time this would not be the case is where you take a disk drive
>(physically) out of an NTFS machine (for example) and stick it in a Win9x
>machine.
>
>At 02:35 PM 9/18/2001 -0400, you wrote:
>>Shares are blind to filesystems.
>>
>>
>>
>>Chris
>>>----- Original Message -----
>>>From: <mailto:mbryan@MIT.EDU>Michael Bryan
>>>To: <mailto:jaglogow@MIT.EDU>Joseph A. Glogowski, Jr. ;
>>><mailto:itpartners@MIT.EDU>itpartners@MIT.EDU
>>>Sent: Tuesday, September 18, 2001 2:19 PM
>>>Subject: Re: Windows NetWork Neighborhood
>>>
>>>Could the problem be the file systems:
>>>
>>>Win98 can see FAT & Fat32
>>>NT 4 can see FAT & NTFS
>>>Win 2000 can see FAT, FAT32 and NTFS ( reason why 2000 can see all the
>>>machines in the group)
>>>
>>>This is just a hunch I could be way off here.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>At 10:34 AM 9/18/2001 -0400, you wrote:
>>>>Hi,
>>>>
>>>>I have Win2000, WinNT4, Win95 and some Win98 machines on the MIT
>>>>network, all with IP addresses.
>>>>
>>>>We have to share files across the network and I tried to setup a
>>>>workgroup to share /exchange files.
>>>>
>>>>Trouble is some machines are visible and others are not. Most of the
>>>>problems seem to be with teh NT machines, the Win2000 machines see all
>>>>the machines in the group.
>>>>
>>>>Any ideas as to what could be wrong?
>>>>
>>>>Also, is it approved to use NetWork Neighborhood here at MIT?
>>>>
>>>>I've updated the SP to 6 on the NT machines.
>>>>
>>>>Thank you in advance.
>>>>
>>>>Joe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>____________________________________
>>>Michael Bryan (mbryan@mit.edu)
>>>E19-504G
>>>258-8230
>>>
>>>
>>>
>>>David J. Broderick
>>>djbroder@mit.edu
>>> Senior Audio Visual Specialist
>>> MIT AV 617 253 2808
>>> FAX 617 253 5945
>>> <http://web.mit.edu/djbroder/www>http://web.mit.edu/djbroder/www
>>>
>>></x-html>
--=====================_91948314==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Hello--<br>
<br>
You seem to be all confusing "seeing machines on the network"
(and specifically in the original context, "in the Network
Neighborhood") with seeing files and shares, once connected to a
machine. :)<br>
<br>
These are very extensive and open-ended questions that involve--what is
commonly referred to as--"Windows Networking" and how it
inter-operates with TCP/IP and other protocols. They also involve what is
often seen as the only means to access Windows Networking: the
"Network Neighborhood" or "My Network Places"--they
really are not.<br>
<br>
I will try not to delve into Windows Networking too much; it will get too
complicated too quickly, as it both inter-operates with TCP/IP and
otherwise "piggy backs" its own on some TCP/IP mechanisms to
operate. Instead, I'll try to explain very symbolically how it works and
then offer some practical suggestions.<br>
<br>
<br>
The fundamental problem is the following: We have a "source"
machine from which we want to locate (on the network) a
"target" machine, connect to it, authenticate ourselves if
necessary, and access shares/share points (shared file and folder
containers, printers, etc.). Microsoft has incorporated into Windows
versions an interface component known as the "Network
Neighborhood" or "My Network Places". This is a graphical
interface to the "locating" process mentioned above. It is not
the only means, however, to "locate" other machines doing
Windows Networking, and is not "thorough" in terms of what and
how it can locate. Because of these and its prominent default place on
the Desktop, it is often a source of great confusion to users.<br>
<br>
Windows Networking, through which Network Neighborhood operates, uses a
number of different means to _locate_ a target machine to connect to from
a source machine--technically referred to as the "NetBIOS node
type". Some of these means involve a "broadcast" mechanism
where, essentially, the machine transmits broadly over the LAN (the
subnet the source machine is on, in our case) calling for the target
machine, awaiting and listening for it to respond. Other means involve
some kind of name resolution (that may or may not use DNS) and then a
direct addressing of the target machine, via its IP address.<br>
<br>
In most default Windows configurations, especially if the machines were
installed/configured disparately out-of-the-box and then made to gather
in a workgroup or LAN, locating the target machine attempt often starts
with a broadcast approach by default and upon failing, switches to a
direct, point-to-point addressing--only if the name resolution mechanisms
are configured properly, as often is not the case.<br>
<br>
There are additional criteria for the broadcast mechanism to work and it
often is time consuming since target machines need to be
"discovered". Microsoft has specified very complex--if not
confusing--"order of speaking/responding" rules for machines on
a subnet/LAN, all simultaneously wanting to use Windows Networking. This
usually involves, quite literally, the "election" of a
"browse master" and backup "browsers"--machines who
keep track of Windows Networking capable machines on that subnet/LAN as
they come and go. Of course, due to this complexity and the broadcast
mechanism, this list the browse master keeps is dynamic and often lags
behind compared to the machines physically appearing and disappearing on
and off the subnet/LAN--up to 12 minutes sometimes.<br>
<br>
The moral of the story here is, Network Neigborhood or My Network
Places--unless configured very carefully on a workgroup/network/NT- or
2000-domain level--will not necessarily be a reliable method of getting
to other Windows machines sharing data. This is particularly more
complicated when we need to go across routers, where additional
complications and Microsoft/Windows Networking rules surface.<br>
<br>
<br>
Having hopefully clarified/listed some of these caveats, what follows are
some suggestions to Joe's original inquiry.<br>
<br>
<br>
First of all, if possible, I'd recommend a client/server model for file
sharing over a peer-to-peer approach like Joe's, as I understand him to
imply. This does not necessarily imply using NT 4 or 2000 Server, but
rather indicates there is one or two (few) machines that act as
"servers" where the sahred data are pooled and the rest are
"clients" that connect to these specific machines to access
those data. Depending on the volume of data sharing, number of client
machines, and frequency of access, the "server" machines _may_
double as workstations, but I'd not recommend it if you can avoid
it.<br>
<br>
I do not have a grudge against peer-to-peer; my reasons for recommending
are simple and pragmatic:<br>
<br>
- A client/server model is easier to interpret and administer--there is
one (or few) machine(s) where the data is kept, so there is no question
of "who connects to what machine to get what" or concern over
the availability of each peer machine.<br>
<br>
- Windows security is an ongoing source of concern, especially at MIT,
and securing one, single type of machine--the "server"--is
often easier than securing each of the heterogeneous Windows flavors
acting as peers.<br>
<br>
This does not mean you should not be concerned about securing individual
workstations, though.<br>
<br>
- If you have access to NT 4 Server or 2000 Server, you have access to
Microsoft tools (such as an NT/2000 Domain) setup that can help you in
streamlining user/password/permissions/etc. management compared to that
of a peer-to-peer setup.<br>
<br>
- You are likely to ease the traffic on your subnet with a designated
"server" and "clients" connecting to it, rather than
a combination of multiple interconnected sessions among peer-to-peer
clients. Windows Networking can be very demanding on a subnet under
certain conditions (such as during large file transfers), and it is best
if you minimize the connections for better performance for all.<br>
<br>
Second, I would suggest deciding on a mechanism by which the machines
will "locate" the server for Windows networking and so users
can connect. This is best achieved by either a "proper" means
of name resolution (e.g. you enter the TCP/IP hostname or the
"Windows Name" of the machine somewhere appropriate and it gets
properly resolved to an IP address, and Windows subsequently connects to
it over TCP/IP), OR by a simple logon script or the like each user runs
on their client machine that simply refers to the "server" via
its IP address. I can provide specific assistance to those interested,
including Joe, separately as this is already running quite long.<br>
<br>
Windows 2000 comes configured "smarter" in these terms by
default, compared to NT 4 and 9x/ME series. That is probably why Joe had
a better experience with 2000 clients.<br>
<br>
Third, I would try to standardize on a few--if not just one--Windows
platforms, if at all possible; things will run smoother and updates and
maintenance will be less diverse. But, there is nothing holding you back
from using one Windows OS with another, though there are caveats here and
there. It is a matter of manageability and overall cost. Depending on
driver availability and vendor support, MIT's licensing agreements for
NT4 and 2000 may be economical and useful in these cases.<br>
<br>
I can discuss this further if there is interest or deal with
individually.<br>
<br>
Cheers,<br>
Kerem<br>
<br>
PS: <disclaimer> I am a member of I/S, the Computing Help Desk and
Software Release Teams, but this is not an official recommendation or
indication of support on part of I/S; rather my own professional opinion.
</disclaimer><br>
<br>
<br>
At 15.42 2001/09/18 -0400, Dave Broderick wrote:<br>
<blockquote type=cite cite>When you connect to another Windows machine,
you can see ALL files on it, (if you have permissions).<br>
If I have a Win95 machine, I can log on to an NTFS machine and see all of
its files. I do this every day. I have a network with Win2k, WinNT,
Win98, and Win95 machines. <br>
<br>
When you access another machine on a network, the other machine is
showing you its files, so the file system is irrelevant between Windows
platforms (assumes you are authenticated as user). My old Win 95 machine
says "Can I see your files?" If the Win2K host says
"OK", then all file system stuf is managed by the host
machine.<br>
<br>
The only time this would not be the case is where you take a disk drive
(physically) out of an NTFS machine (for example) and stick it in a Win9x
machine.<br>
<br>
At 02:35 PM 9/18/2001 -0400, you wrote: <br>
<font face="arial" size=2><blockquote type=cite cite>Shares are blind to
filesystems.</font><br>
<br>
<br>
<br>
Chris<blockquote><font size=4>
<dl>
<dd>----- Original Message -----
<dd>From: <a href="mailto:mbryan@MIT.EDU">Michael Bryan</a>
<dd>To: <a href="mailto:jaglogow@MIT.EDU">Joseph A. Glogowski, Jr.</a> ;
<a href="mailto:itpartners@MIT.EDU">itpartners@MIT.EDU</a>
<dd>Sent: Tuesday, September 18, 2001 2:19 PM
<dd>Subject: Re: Windows NetWork Neighborhood<br>
<br>
<dd>Could the problem be the file systems:<br>
<br>
<dd>Win98 can see FAT & Fat32
<dd>NT 4 can see FAT & NTFS
<dd>Win 2000 can see FAT, FAT32 and NTFS ( reason why 2000 can see
all the machines in the group)<br>
<br>
<dd>This is just a hunch I could be way off here.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<dd>At 10:34 AM 9/18/2001 -0400, you wrote:<blockquote type=cite cite>
<dd>Hi,<br>
<br>
<dd>I have Win2000, WinNT4, Win95 and some Win98 machines on the MIT
network, all with IP addresses.<br>
<br>
<dd>We have to share files across the network and I tried to setup a
workgroup to share /exchange files.<br>
<br>
<dd>Trouble is some machines are visible and others are not. Most of the
problems seem to be with teh NT machines, the Win2000 machines see all
the machines in the group.<br>
<br>
<dd>Any ideas as to what could be wrong?<br>
<br>
<dd>Also, is it approved to use NetWork Neighborhood here at MIT?<br>
<br>
<dd>I've updated the SP to 6 on the NT machines.<br>
<br>
<dd>Thank you in advance.<br>
<br>
<dd>Joe<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<dd>____________________________________
<dd>Michael Bryan (mbryan@mit.edu)
<dd>E19-504G
<dd>258-8230 <br>
<br>
</dl><br>
<br>
David J. Broderick <br>
</font><font size=4 color="#0000FF">djbroder@mit.edu <br>
</font></b><x-tab> </x-tab>Senior
Audio Visual Specialist <br>
<x-tab> </x-tab>MIT AV 617
253 2808 <br>
</b><x-tab> </x-tab>FAX
617 253 5945 <br>
<x-tab> </x-tab><a href="http://web.mit.edu/djbroder/www">http://web.mit.edu/djbroder/www</a>
<br>
<br>
</x-html> </blockquote></blockquote></html>
--=====================_91948314==_.ALT--
