| UO Computing Center Microcomputer Services |
|
| Networking Issues with Windows 95 & NT |
|
Table of Contents
What's Up in the Network Neighborhood?Windows 95 and NT users who have installed network protocols on their machines have access to various resources by double-clicking on the icon called "Network Neighborhood." What a number of users have noticed is that what they see in their Network Neighborhood is not always consistent. From different physical locations (say from home and the office) you will often see a very different view of the University of Oregon network in your Network Neighborhood. This is dependent upon what types of network protocols you have installed on your machine and how you have configured each of these protocols in your Network Control Panel. This discussion does not cover getting TCP/IP applications to work per se, but you will see the correct default configuration for the TCP/IP Control Panel (minus something called the WINS server) later in this article.When you look in your Network Neighborhood you may see a number of different items. If you double-click on the "Entire Network" item you will see yet more items. Each of these items relates to a different type of resource. You can identify what the resource is by the icon used for the item. Below is an example of a view of the "Entire Network" from a Windows 95 machine which can see Novell Fileservers and Microsoft Network capable machines (Windows 95, NT and possibly Windows for Workgroups). The item below named, "Zeus", represents a popular Novell fileserver on campus. If you were to double-click on this item and you had an account on Zeus, or you used the public account "PD" then you could connect to this fileserver and see the various files and printers which it serves. The Next item represents what is called the "Uoregon" Domain. This is a group of machines running Windows 95, NT, or 3.11 for Workgroups which all have agreed to reside on this Domain. This same type of icon can represent a Workgroup which acts differently than a Domain, but looks the same to you. If you have correctly configured your Windows environment to see all the resources in the Uoregon Domain and you double-click on this icon, then you would see something like what is shown below. Now you might be asking yourself, "How do I configure my machine to see Novell Netware fileservers and/or Domains and Workgroups in their Network Neighborhood." Even after you do this you may ask yourself, "OK, why can't I reliably see all the machines inside of each Domain or Workgroup?" This has become more of an issue as more and more people start to use Windows 95 and NT in their offices on campus and from home. This document will explain how to do this (as well as you can) for Windows 95 users. Windows NT users can take this information and pretty much translate the concepts directly to their configurations. Some of the specific steps mentioned for the Network Control Panel will, however, be different. We may create a document in the future which contains specific steps for NT users. This document does not go over products (such as Apple's COPSTalk) which allow you to see AppleShare fileserver and System 7 personal filesharing through the Network Neighborhood. Configuring Your Machine to Access Resources in the Network NeighborhoodSeeing Novell Fileservers in the Network NeighborhoodThis is the easy part of our configuration game. In general you should have a Network Control Panel which has, at least, the following network components installed:
If you want to to always login on a certain Novell fileserver when you startup your machine then you would go to the "Primary Network Logon" list in the opening screen of the Network Control Panel and choose "Client for Netware Networks" as your primary logon. If you are dialing in this is usually not a good idea. It is best to leave your Primary Network Logon as "Windows Logon" and then login on servers after you connect via modem using the built-in dialup networking. You can double-click on the Client for Netware Networks and point it at a specific server if you wish in the "Preferred Server" box. After you do all this you should close the Network Control panel by clicking on OK and then reboot your machine. You will, most likely, be asked for your original Windows 95 disks or CD-ROM to copy over the new drivers you have requested. After rebooting, if you are on campus then you should be able to see the Novell Filerservers in your Network Neighborhood when you restart. You may notice that some of the Microsoft Domains and Workgroups appear. This will be explained further below. [These steps are significantly different for NT users.] Seeing Microsoft Domains and Workgroups in the Network NeighborhoodFirst, you will need to understand the intention behind how Microsoft has designed Domains and Workgroups. The concepts here are the following:Workgroups: This is a collection of Windows 95, NT and possibly Windows 3.11 for Workgroups machines which all agree to belong to the same named Workgroup. There is a major limitation to this model - All these machines must reside on the same physical network. On the University of Oregon network, known as the UOnet, there are many separate networks known as subnets. You can think of these subnets as being little networks which help to divide the campus up into logical divisions. For instance, most departments are on one physical subnet on the UOnet. Each subnet has a number to identify it. The subnet "net32" belongs to the Computing Center. So, if you are physically located in one building on campus, or maybe you are dialing in from home, and you want to belong to a Workgroup which reside in another building you will not be able to do this reliably, or at all using Workgroups. Technical Aside: The reason why you cannot reliably see machines in a Workgroup which reside in another physical location is because the Microsoft network protocol known as NetBEUI does not have a method for routing itself from one physical subnetwork to another. Another reason for this problem is that a Workgroup does not have a machine which reliably broadcasts the names of all the other machines in a Workgroup. Since no machine is setup to do this on a Workgroup you can never be sure if you are really seeing every machine in a Workgroup. So, how do you resolve this? Well, read on... Domains:A Domain in the Microsoft networking scheme has two major differences over a Workgroup.
Why Can't I See All Machines in All Domains/Workgroups?First off, to begin we must be a little fair to Microsoft. There is actually a model by which it is possible to setup a network where everyone can see every machine on every Domain (you must have Domains with Windows NT Servers on each one to do this) in their Network Neighborhood. This model is called,The Complete Trust Model: In this model every Windows NT server must be setup so that it knows the IP address of every other Windows NT Server on the network and it must give full permissions to all of these servers. This means that the administrator of the server must be willing to allow the administrators of all the other servers to have privileges to create, delete, and modify pretty much anything on their server. Still, even if you wanted to do this it is not practical on the UOnet. The formula for how many separate trust relationships you must setup for each server is (((number of servers) X (number of servers)) - (number of servers)). For just 20 NT servers (the UO has exceede this number) the number of trust relationships would then be ((20 * 20) - 20), which is 380! That means 380 phone calls, e-mail messages, etc. to setup the trust relationships between the servers. If you were to do this, then each server receives information from all the other servers about what machines are on each of their Domains, thus users can see all machines on all machines on the network. Another way to to do this is to have one master Windows NT serverthat all the other servers are subordinate to. This only works for smaller networks and organizations where one group has absolute control over all the other groups (this is not the model at the UO). So, what can you expect on the UOnet? Well, to begin with if you want to have a group of machines where you can always be guarranteed of seeing all the other machines via your Network Neighborhood, then you must have a Windows NT Server on the Domain to act, at the least, as the Primary Domain Controller. Network Services provides such a service on one Domain called "Uoregon" so that there is a central place you can point your Windows 95 and NT boxes at for services. It's kind of like having a central meeting place. Accessing Other Workgroups on the UOnetIf you are on the same physical subnet on the UOnet then you may create a Workgroup and agree to point at this workgroup. You should see most machines pretty reliably on this Workgroup using this method. To point at a Workgroup just click on the Identification tab in the Network Control Panel and enter in the Workgroup name you wish to belong to. Remember, and this is critical, if the Workgroup resides on a different physical subnet then you cannot reliably see other machines using this method.If there is a Windows NT server on your Subnet which is acting as a WINS (Windows Internet Naming Service) server, then there is a method to see all the machines in the Domain from any subnet (including via dialin). Here is what you do:
What Protocols Do You Need to See Machines, Domains, and Workgroups and Why?One of the key problems with all of the following concepts explained above is how do they work with the underlying network protocols you have available to you. Let's do a very quick rundown of the typical network protocols in use at the UO.
What About Seeing Machines in Two Separate Domains?So, a few of you may have already been asking yourself this question. If each Domain only ensures that you can see all the machines in that Domain (remember, a Domain means that there is a Windows NT Server taking care of business), then how can you see machines in another Domain in your Network Neighborhood. Remember above we already gave you the answer, and that is that you cannot. This is an unfortunate, and very confusing result of using Microsoft's networking model as setup in Windows 95 and NT. Still, do not completely despair, there is a way around this. Remember we said that using IPX/SPX was a workaround to allowing NetBEUI packets to go between subnets, well the workaround we are about to present might be called a kludge. This is computerese for, "A workaround which works but is somewhat silly in nature." OK, here is what you do to see any Windows 95 or NT machine on the network which is running the TCP/IP protocol. If the machine does not have TCP/IP loaded then this trick will not work.
A Technical Discussion of BrowsingThe first thing to understand is that the term Browsing is the act of viewing resources in your Network Neighborhood and accessing resources through the "Run..." command under the Start menu. Besides all the various reasons we've discussed about why you can see resources and why can't see resources we have not, yet, discussed how Browsing actually works on a technical level. In the next section we give a few more rather esoteric hints for improving your browsing. Here we tell you how your machine actually gets the lists of available resources which it can see. This is important since Microsoft's current implementation of Browsing is a patchwork of rules that you may find surprise and which directly affect what you see when you double-click on your Network Neighborhood icon. This remainder of this discusion is coming soon! A Few Additional Notes For Improving Browsing
WINIPCFG: If you ever want to know the IP address of a machine you are on go to the Start menu, choose "Run..." and type "winipcfg" then click on OK. Lots of good network information specific to your machine will be displayed, including its IP address.
Obviously this document is quite long and detailed. Still, there are many bits and pieces we have left out to try and keep the length somewhat reasonable. If you have comments about this document please feel free to send e-mail to microhelp@oregon. You can find more details about the information presented here in the Windows NT Resource Kit available in most bookstores, and in many other computer books by companies such as SAMS publishing. Good places in the Eugene area to find such books are The Smith Family Bookstore, Barnes & Nobles, the UO Bookstore, and Walden Books. You can also checkout many of these books in the Documents Room Library in Room 205 of the UO Computing Center. This is not a definitive list and should not be construed as an endorsement of one book or store over another. One Big Difference With Windows 98: Avoiding LMHOSTSWindows 98 appears to have the functionality of the LMHOSTS file built-in directly to its network services. From the Start menu in Windows 98 you can now choose "Run...," and type in an IP address of a resource on the network directly. This means that you do not have to create an LMHOSTS file which contains both the DNS name of the resource and its IP address. As an example, the IP address of the Windows NT server named kahuna is 128.223.60.48. If you type this address in the "Run..." box in Windows 98 Kahuna should come up on your screen. You may notice a slightly longer delay than if you had typed in "\\kahuna," but this method does seem to work in most cases. Remember, this method requires that both the client machine (where you type in the IP address) and the resource you wish to reach be running TCP/IP to work. A Few AcronymsIf you've been wondering what TCP/IP, IPX/SPX, NetBEUI, or DHCP stand for, well here's your chance to find out.
|
|
Hervey Allen,
6/4/98 |
[Home][CC Home][UO Home]
[VMS/UNIX][Network Services]
|
