[720] in winnt
Re: Windows NetWork Neighborhood
daemon@ATHENA.MIT.EDU (Stephen Dowdy)
Wed Sep 19 16:51:50 2001
Message-Id: <5.0.2.1.2.20010919161500.01a591d8@po10.mit.edu>
Date: Wed, 19 Sep 2001 16:48:35 -0400
To: "Kerem B. Limon" <Kerem.Limon@mit.edu>, Dave Broderick <djbroder@mit.edu>
From: Stephen Dowdy <sdowdy@MIT.EDU>
Cc: winpartners@mit.edu, jaglogow@mit.edu
In-Reply-To: <4.2.2.20010918171719.0306b878@PO11.MIT.EDU>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
<html>
Kerem,<br>
<br>
Thanks for taking the time to write this up. It is a useful
overview. Now, I have a little "problem" that I haven't
been able to overcome in OSP. Since these threads are
related, I thought I continue and expand on them theme.<br>
<br>
I have a NT domain controller called "OSP". I have about
50 machines that connect to the domain controller. About half of
the machines are NT and the other half are W2K. I recently received
several new machines. All W2K that would replace some of the NT
workstations.<br>
<br>
On these new W2k machines, I only installed TCP/IP and not
NetBEUI. The disks of the machines were cloned from a master,
so for most of them, bringing them up on the MIT network was a matter of
switching the machine name and assigning an IP address. I find it
difficult to change both the machine name and trying to join the domain
in a single operation. Instead, I must change the machine name and
join a fictitious workgroup. Re-boot and then attempt to join the
domain. <br>
<br>
For all but one machine, when trying to join the domain, the dialogue
window opens and asks for an account that is allowed to have machines
join the domain. W2K seems to "think" about this for a
very long time. It would sometimes take 2-3 minutes before the
"Welcome to the OSP domain" message would appear. But for
14 machines, this worked and the new machines were able to join the
domain after changing the name, followed by a reboot, followed by
attempting to join the domain.<br>
<br>
Now my problem child. I have one machine that continued to complain
that it couldn't locate the OSP domain controller. It didn't even
think. The second I attempted to join the OSP domain, the error
window appeared. This machine is on the same subnet as every other
machine in the office. In fact, all of these machines begin with
18.142.2. No matter how many re-boots and changing the name, I
could not get the machine to join the OSP domain.<br>
<br>
So, I added the NetBEUI protocol. Voila, the machine joined the
domain with no problem. If I remove the NetBEUI protocol, the
machine won't work again. <br>
<br>
I guess my question is: any idea why this one machine can't
join the domain? It is a new machine that doesn't have a DNS entry
with Netops at this time. I don't think that should be an issue
since I have other NT machines that join the domain without DNS entries
associated with their IP address. It may be, that all thes NT
machines have the NetBEUI protocol. <br>
<br>
Do you know for a fact, that the machine must be registered with DNS in
order to join the domain if only TCP/IP is installed?
The thing that is confusing me a bit.... my domain is called
"OSP"... but the machine is not called OSP. So, I
can't see how it would be using DNS entries to locate the OSP domain
since this is not the machine's name. But perhaps it is the OSP
domain complaining about the workstation machine and the message is just
not clear.<br>
<br>
<br>
At 01:13 PM 9/19/2001 -0400, Kerem B. Limon wrote:<br>
<blockquote type=cite class=cite cite>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 class=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>
<blockquote type=cite class=cite cite><font face="arial" size=2>Shares
are blind to filesystems.</font><br>
<br>
<br>
<br>
Chris
<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>
<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 class=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>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<dd>____________________________________
<dd>Michael Bryan (mbryan@mit.edu)
<dd>E19-504G
<dd>258-8230
</dl><br>
<br>
David J. Broderick <br>
<font size=4 color="#0000FF">djbroder@mit.edu <br>
</font><x-tab> </x-tab>Senior
Audio Visual Specialist <br>
<x-tab> </x-tab>MIT AV 617
253 2808 <br>
<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> <br>
</blockquote></blockquote></blockquote></html>
