Network Setup

Important note: This will not be an attempt to offer a "paint by numbers" approach. The discussion will basically center around key ideas and concepts, and how this information is presented by Windows 95 (the assumed most prolific OS of this writing). The reader will learn much by using the help file (in my opinion, the single greatest tool available) when necessary to accomplish the needed tasks.

General considerations

Client for Microsoft Networks is, for our purpose, the Microsoft networking software. It most cases it will be added during OS installation or during the addition of a network device such as an interface card, terminal adapter, or modem. If for some reason it doesn't appear in when you examine control panel/network/configuration, then it will be necessary to add it.

In addition to installing the Client for Microsoft Networks, and the network adapter, we also need to install a communications protocol, the language of the network. By default and/or definition we will install the Microsoft TCP/IP protocol. Removal of all other protocols, such as NetBEUI and IPX/SPX will facilitate verification that TCP/IP is correctly installed and set up as well as keeping network performance at maximum levels.

Peer to peer Microsoft networking uses a concept called workgroups, a logical grouping of systems that allow all members in the group to browse their shared resources. In your home network you will want to insure that each computer belongs to the same workgroup, control panel/network/identification. Watch out for typographical errors as they can be difficult to spot, especially a leading space before the workgroup name. If the workgroup names are not identical you will have browsing difficulties causing server (or pseudo-server: those running peer services) systems to not be seen via Network Neighborhood.

All systems must have a unique computer name, control panel/network/identification. This is sometimes referred to as the system's NetBIOS name.

IP addressing

TCP/IP relies on a logical addressing scheme that provides unique IP addresses to all systems on a network. IP addresses are normally presented in "dotted quad notation", that is 4 bytes (usually written in decimal - 254 instead of FEh for example) separated by periods (dots), such as "192.168.143.109". IP addresses also have a related subnet field (also presented in dotted quad notation) that defines their scope. For systems to interact locally without the use of routing they must be on the same subnet (a Boolean AND of the IP address and subnet mask are equivalent for all systems). There is much material on this subject and it is left to the reader to research those areas that peak further interest.

For our purposes we will simplify choose and use a class C subnet mask: 255.255.255.000 and one of the class C address blocks reserved for private use: 192.168.xxx.yyy; where xxx must be the same for all systems on this subnet and yyy must be different for each system thereby providing a group of systems on the same subnet with unique addresses.

Let's choose, for example: 192.168.12.0 as our network. This address, a class C address with a 0 in the last quad position, defines the network and is a special case address, i.e. it does not get applied as a system's address. Another special address, in this case, would be 192.168.12.255, which is designated as the broadcast address and also does not get applied to a specific system. All of the remaining address from 192.168.12.1 through 192.168.12.254 inclusive are available for system addresses. Notice that a Boolean AND of this range of IP addresses (192.168.12.1 through 192.168.12.254) and our subnet mask (255.255.255.000) create our network ID of 192.168.12.0 in every case; systems addressed as such can communicate directly without being routed and are on the same subnet.

For practical purposes of this discussion, all systems on our network must have a unique IP address, have identical subnet masks, and be on the same subnet.

The lmhosts and hosts files

When it comes to communicating with any particular system, the unique IP addresses are great for software but we humans prefer a more natural interface. We prefer to talk to "www.microsoft.com", map a drive on "Charlie", or print to a printer on "MyServer". These domain and/or NetBIOS names are mnemonic and people friendly whereas the actual IP addresses such as 209.32.54.127 are not.

On the Internet, we tell our browser to go to "www.microsoft.com" and a DNS (Domain Name Server) dynamically translates that into an IP address like 207.46.131.135 so our software can find its way.

In Microsoft Networking (as it is now) there is a similar correlation between a system's NetBIOS name (this is the name we give our system when we install the OS) and its IP address. The translation from its human friendly NetBIOS name to its system friendly IP address can be handled dynamically by a WINS server.

In a small network we may not have a WINS server (requires NT server) or a DNS server. There may be no need to use the resources to run these servers even if we have them. So static maps of IP addresses, one for domain names and one for NetBIOS names, are used as lookup tables to provide this name resolution in the absence of these dynamic servers. The hosts file fills in for the DNS server, and the lmhosts file fills in for the WINS server. Name resolution may also occur by broadcasting as well, but properly setup hosts and lmhosts files will aid this process and improve network performance.

A post that occurs frequently in MS networking forums is "I can attach to another systems resources but I can't ping it". "Ping"  is a native IP command and needs DNS/hosts file resolution whereas mapping a drive through MS Networking is a NetBIOS function and requires WINS/lmhosts file resolution. It's best to provide the system with both.

These files need to be located in the proper folder which is different for NT and Win95/98 systems. Under NT the files reside in the \winnt\system32\drivers\etc folder and under Win95/98 in the \windows folder. Follow the installed Microsoft sample template files (hosts.sam and lmhosts.sam) or the example file links below to produce your own proper static maps. After entering the last line be sure to hit enter as these files must terminate with a carriage return. Save these files with no extension, just plain "hosts" and "lmhosts" and place a copy on every system.

Example lmhosts file.

Example hosts file.

Sharing resources

Windows NT users will find file and print sharing capabilities automatically installed with the network thereby creating immediate visibility and browse-ability of these servers via Network Neighborhood. Windows 95/98 users will need to install the file and printer sharing peer services in order to share either of these resources or to provide browse-ability. I recommend that you keep the network as logically straight forward as possible and avoid installing the file and print peer services just to "see" a system in Network Neighborhood. If that system is not providing (sharing) any needed resource then there is little reason to "see" it. What is important is that it can get to and use the resources it needs.

Like most other things the K.I.S.S. principle applies. Some planning in the beginning can make things easier and less confusing later on.