[721] in winnt
Re: Windows NetWork Neighborhood
daemon@ATHENA.MIT.EDU (Barbara Santorella)
Thu Sep 20 08:19:38 2001
Message-ID: <3BA9DF08.328A554B@mit.edu>
Date: Thu, 20 Sep 2001 08:20:24 -0400
From: Barbara Santorella <bsantore@MIT.EDU>
MIME-Version: 1.0
To: Stephen Dowdy <sdowdy@mit.edu>
CC: "Kerem B. Limon" <Kerem.Limon@mit.edu>, Dave Broderick <djbroder@mit.edu>,
winpartners@mit.edu, jaglogow@mit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This is an interesting thread. I recently switched all the IP numbers in
my domain from MITNet (18.77.x.x) to ESNet (198.125.x.x). The only way
I could get the machines to join the domain when I did this was to
install the NETBEUI protocol. I have an NT Domain controller and both
NT and win2k workstations. The only *any* machine in the domain could
see all the other machines (In Network Neighborhood) was if NETBEUI was
installed on the machine.
Stephen Dowdy wrote:
>
> Kerem,
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> At 01:13 PM 9/19/2001 -0400, Kerem B. Limon wrote:
>
> > 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: Michael Bryan
> >> > To: Joseph A. Glogowski, Jr. ; 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
> >> >
> >> > </x-html>
> >> >
--
_____________________________________________________________________________________
Barbara Santorella, MCSE
NT Systems Administrator
MIT, Bates Linac
