Not too many years ago, networking was an afterthought to most computer users. Personal computers were sitting on desktops, and people exchanged information via disks or printed reports. Then a number of vendors started to network their computers together. It started with the technical computer communities, which tended to use VAX and UNIX computers. They had to ship large files between machines and developed computer utilities that could use network cards to transfer this information.
Once these networking utilities evolved from being laboratory grade to production grade, people were able to build a case for networking office computers together. Initially, it was just to share printers and ship a few files around. Next thing you know, people were developing ways to store software on servers and meter out usage licenses to individual PCs and all sorts of other useful utilities. Some organizations even started to store key corporate information in digital form and make it available in a centralized location on the network.
Windows NT was developed after this push to networking really gained momentum. The Microsoft team recognized that this trend was here to stay and build networking in as a central component of the operating system (similar to many UNIX systems that are out there on the market). Most PC systems in the past (such as Windows 3.1) came without any built-in networking. People had to purchase add-on packages from various vendors. Each vendor had a vision of how networking was to be implemented, and you had to spend a lot of time and effort learning their systems. Also, in many ways these packages always seem to be an add-on and not really part of the operating system itself (for example, memory management, which was always a nightmare when you had several network drivers loaded).
Windows NT has taken networking to heart and built networking in as an integrated part of the operating system. You still have a choice on drivers and services, but there is a standard interface between the operating system and the network that all vendors are writing to. Also, because Windows NT is a 32-bit operating system that supports better memory management and multitasking, it is much easier to implement network drivers and services. This is especially true of those network services such as FTP servers, which have to continuously monitor the network in background to see if there are any requests for information from other computers on the network.
This leads me to the purpose of this chapter. From its title, you see the focus is installing the networking components that come as part of the Windows NT server operating system itself. There are still a number of add-on packages made by Microsoft and third-party vendors. Examples of these products include Telnet servers and World Wide Web servers. However, this chapter covers installation of the basic components, which are actually fairly robust and tend to meet the vast majority of the business needs that I have run across.
Let me start by going over what makes up Windows NT's integrated networking. Previous chapters have covered some of the technologies (such as Netware services and FTP) at the technology level. This section is devoted to presenting an integrated picture of the networking components and how they all fit together. Perhaps the easiest way to start this task is with a picture. (See Figure 7.1.)
Windows NT networking overview.
You need to understand these components and how they fit together before you can start configuring your network. The basic goal is to get data from a user application (such as Explorer or a client/server database application that you develop locally) to the networking wire running out of you machine. For purposes of this discussion, I have divided the networking hierarchy into three components:
Following up on a point made in the previous section, the key to connecting workstations together for network communications is standards. Of course, the industry has a number of players who think that they are, by definition, the standard. (I am not just talking about Microsoft.) Therefore, your ability to connect to other workstations is limited by the standards that your computer supports. Fortunately, Windows NT supports a wide range of computers through its built-in networking protocols and services. Because almost everyone is building operating systems that connect to the Internet, TCP/IP is the most common communications protocol in use today and Windows NT supports it as part of the standard delivery (no extra products or options to buy).
Therefore, before I go into the actual configuration procedures for Windows NT networking, it might be helpful to review the list of options that you have that relate to network standards. These standards include not only the protocols that you will use to configure your network but also several interface standards that will allow applications that you purchase to interface with the NT networking services to communicate with remote systems:
Working with the standards listed above are dozens of other lower-level items such as the Ethernet and token ring transmission standards associated with a given network card. However, for our purposes, the preceding list can be thought of as a basic laundry list of services that you would install under Windows NT networking. These standards make it easy to integrate Windows NT servers and workstations into existing networks. This is especially true of the Netware connectivity and TCP/IP (hence UNIX) connectivity components. You might still have to work out the details of the connection, but it is a good start to know that communication is possible and relatively easy in the NT environment.
Many of the acronyms in this chapter end in the letter P and the P usually stands for protocol. I like to think of a protocol as an agreed upon standard that ensures that I can communicate my information with others. This section focuses on a specific set of protocols that determine who can receive your signals on the network. These transmission protocols set standards that allow computers on the network to determine whether the packets are intended for them and then determine what should be done with the information.
There are entire books devoted to the details of these protocols from SAMS and the Windows NT Networking Guide in the resource kit provides some more detailed discussions on protocols. I have chosen to focus this section on providing an overview of these protocols that covers the information that a system administrator (not a network engineer) would want to see. This includes:
Let me start with a discussion of TCP/IP. What is it that makes TCP/IP and important protocol for today's system administrators? It is the protocol that drives the Internet, for one thing. It is also a protocol that can be routed (signals sent only to those network segments that need them as opposed to being broadcast throughout the entire network) which keeps overall network traffic loads down. It is also a robust protocol that incorporates transmission reliability features and an ability to interface applications to sockets for specialized forms of communications (i.e. FTP or client-server database communications).
The TCP/IP protocols was originally developed by the United States military. This protocol was soon adopted by universities and other government agencies as a standard. A large boost came when the Berkely Unix world started to emphasize networking and adopted TCP/IP as its standard. Over the years, the Internet and its protocol suite has developed a sort of life of its own. There are working groups composed of industry experts and concerned users who are working to evolve the standards to meet the new requirements that are coming up. An example of this is the work being done to address the issue of the rapid expansion of the Internet, how additional addresses can be made available and how to improve traffic routing.
The acronym TCP/IP can be broken down into TCP (Transmission Control Protocol) and IP (Internet Protocol). My rough distinction between these two is that TCP handles the details of the message while IP provides a means to provide an easy to use and route address for each computer. There are a number of other standard supporting protocols that are grouped into the TCP/IP family in common practice. Examples of this would include ping to see if a remote server is responding to the network or ftp to transfer files between computers.
The pros and cons of this protocol (from the system administrator's point of view) include:
NetBEUI sort of falls at the other end of the spectrum in terms of standardization and robustness. Windows NT uses the NetBEUI Frame (NBF) protocol which is an extension of the old NetBIOS Extended User Interface (NetBEUI) protocol. IBM introduced NetBEUI in 1985 to support its PC network communications. It was intended to be simple and optimized for simple network functions such as printing and file sharing which are common to PC networks. NBF's main enhancement is that is allows you to have more than the 254 sessions that are permitted under NetBEUI.
Back when NetBEUI was invented, this seemed a very reasonable limit for local area networks. A more telling limitation is the fact that NetBEUI was not designed to provide reliable connectionless communications. The Windows NT Networking Guide provides an interesting discussion of this topic, but what it basically means is that it does not get a confirmation that the message has made it to the sender. This is not a big problem for a print job (if you do not get your printout, you re-send it), but it could be a severe problem for a large financial database transaction sent over the network.
The summary of pros and cons, as viewed by system administrators, of NetBEUI include:
IPX/SPX is the protocol suite that forms the basis for the majority of Novell Netware installations that are out there today. Novell has recently provided you with the option of using TCP/IP for your Novell network. IPX stands for Internetwork Packet Exchange. It is designed to have a low overhead and is optimized for local area networks. SPX stands for Sequenced Packet Exchange and it functions like NetBIOS for IPX/SPX networks. It is connection oriented (both sides talk to one another about the transmissions they are making).
As with the previous two protocols, there are books on the subject that can take you into the details of the packets, addressing, etc. However, the keys points to take away from this chapter about IPX/SPX are:
As with most Windows NT components that are integrated with the operating system, networking is configured using the Control Panel, which can be accessed with from the My Computer desktop icon or from the settings option of the start menu. As you can see in Figure 7.2, there are a number of Control Panel icons that relate to networking: FTP server, modems, ODBC, services, and the one that we are interested in for this chapter—Network. This icon is the key to setting up your networking functionality, and you need to complete this setup before you can set up the other functions.
Windows NT Control Panel and Network icon.
When you double-click on the network icon, you will be presented with the new Windows NT 4.0 setup panel. (See Fig. 7.3.) Based on my observations of Windows NT 4.0 and Windows 95, Microsoft seems to be moving heavily towards the tabbed dialog interface for configuring items, so it would be useful for you to get comfortable with this interface. It is relatively simple to work with; there are a number of tabs across the top, each of which corresponds to a data entry or display panel that you need to work with. The items that are being configured are listed in a window similar to the one showing network adapters in Figure 7.3. The plus sign indicates that if you click the icon, you will get an expanded list of items that are associated with the item that you just clicked (an expanding list). Finally, there are a series of buttons (such as Add, Remove, and Configure) that allow you to perform the allowable actions on the list.
Network Setup panel.
The tabs correspond to the items in the hierarchy discussed earlier in this chapter. In this case, you build your network from the bottom up, starting with the adapters. Next, you select the protocols and then the services. To connect this all together, use the Bindings tab dialog. Finally, an identification tab that lets you specify how your computer is identified on a Microsoft network. Each of these tabs builds upon the others to form the complete network picture, so you have to work with all of them to set up your network.
When you set up networking, you are probably going to have to reboot your computer after you are done entering the new settings. This is because networking is tightly integrated into the operating system itself. At the end of the setup, you will receive a prompt that asks if you want to reboot the system now. I like to choose a time when I can do the reboot immediately after my work so that I can check to see if everything went okay. (A little mistake could deactivate your client-server database connection, for example.). Also, if I were to click the wrong button (Yes) when prompted for the reboot, the system will be shut down and restarted. Therefore, I do not do this work on a production server during production hours. Users of a network-based computer system get really sensitive when their server is down unexpectedly.
Back to configuration. One of the things that some people were hoping for in Windows NT 4.0 was what Microsoft and others refer to as Plug and Play. Unfortunately, that will not be completed in this release. Under Windows 95, the system has a reasonable chance of recognizing the existence and type for a large number of cards and peripherals that you might connect to your system. It will then take you through a series of wizards to set things up (hopefully) correctly. It is not perfect but makes life much easier when it works.
Under the 4.0 version of Windows NT, you still have to go through and manually tell the operating system what components you have installed. Therefore, you start the networking section with the network adapters. You might be thinking that Windows NT 4.0 is more like Windows 95. Even though modems are part of networking under Windows NT, they do not show up as a network adapter like they do under Windows 95. However, you will find bindings to the RAS wrappers later in the network setup, so RAS is not a totally separate subsystem.
Now let me focus on your options in the Adapters tab on the Network Setup panel. (See Figure 7.3 again.) As you can see, it lists my network adapter. It would list multiple network adapters and allow you to configure each of them individually. Let us now examine what setting up an adapter involves. If you added a new adapter to your system, you would click the Add button on the Adapters tab of the Network Setup panel. NT would then present you with a list of adapters that it supports (that are distributed on the Windows NT operating system CD) and allows you to choose one of them, as shown in Figure 7.4. This list is not very long when compared with that of say Windows 95, so it is important to check that your adapter is supported by Windows NT before you buy it. If it is not one of the ones that Microsoft provides drivers for on the NT operating system CD, you can use the Have Disk button to allow NT to read a disk or CD drive that contains drivers given to you by the manufacturer.
Adapter Selection panel.
Once you have selected the adapter that you are going to use, you need to configure it. Here is where all of that hardware stuff can be a challenge for an operating system type who just wants to get things up and running quickly. The various adapter manufacturers have different ways to configure an adapter. Some use jumpers located on the card itself, others use software utilities which will allow you to set it up programmatically. Whatever the method, you may have quite a challenge in front of you to select settings for this network card that do not conflict with other hardware components that you might have installed such as serial ports, drives or sound systems.
There are two key addresses that you need to worry about when setting up an Intel-based machine which is the most popular platform for NT, by far. The first address is known as the IRQ level which is also referred to as the interrupt number. It is one of 16 addresses that are available to get the attention of the operating system at the hardware level. You may think that 16 is a lot of addresses, but the machine that I am typing on has all 16 addresses used up between network cards, modems, a sound card, and the motherboard itself (which takes up 4 or more addresses before you put the first card on the system). The next address is usually referred to as the I/O port address. It is a section of the memory of your computer that is used for transferring data from the various installed cards and components.
When you buy workstations based on the MIPS or Alpha architectures, they usually have fixed addresses for their various components and your task is to figure out what these standard addresses are and just use them. The unfortunate part of the Intel world is that the operating system fixes a couple of addresses for such things as the system clock and then throws the rest up for grabs with only some suggestions as to what should be used for what purpose. To make matters more complex, certain peripheral devices only support a few of the many possible combinations of IRQ and I/O port address. You will need to have this worked out before you start working on your server or else schedule plenty of time for you to try out all of the possible combinations. Finally, don't feel bad if it takes a while. I have found several machines that no matter what combinations we tried, we could not make certain components work and we had to replace them with others that were more compatible with the other components in the system.
Now back to the actual configuration task itself. You will be asked to set the addresses and possibly some additional configuration parameters for the adapter that you have chosen. You may choose poorly and be informed that your networking services did not start up because of some addressing conflict. You task is to then adjust the settings of your adapter card, both through its jumper settings or setup utility and through the Network Setup panel. On the Network Setup panel, you select the Adapters tab and then choose the Configure button. You will be presented with a panel similar to Figure 7.5 which will allow you to alter the settings.
Network Adapter Configuration settings.
Perhaps you have gathered from the tone of my writings that this can be a very frustrating part of setting up a system. I can always tell in my group when one of us is setting up the hardware on a computer system. They are usually staring intently at their monitor with a mean look on their face or yelling at their system (I dread the day when they can yell back). There are a few tips that may help when you are trying to get through the installation and configuration of hardware:
After that, you're working a puzzle to see if you can get all of the pieces to fit together.
The next step in configuring your network is to decide which protocols you need to support. Usually, you will have these dictated to you by corporate standards, places you need to connect to, etc. There are a few general suggestions for you to consider when deciding:
To set up protocols in your system, you will use the Protocols tab on the Network Setup panel (see Fig. 7.6). The nice thing that you will notice is that it looks very similar to the previous Adapters tab. That is the real benefit to this common interface for property setting. Basically, you have to add protocols from the list of available protocols (you can even add protocols from third party manufacturer diskettes, but I have never had to use more than what is provided on the NT distribution CD). The complexity comes in when you go to configure the protocols. NetBEUI is relatively simple to configure and IPX/SPX usually works with the minimal default settings. However, TCP/IP usually requires some work to get running properly.
Protocol setup.
The reason that TCP/IP is so complex to set up comes from some of its ambitious design goals. It connects millions of computers worldwide through a logical network made up of many thousands of other networks. To make this all work together, software and hardware vendors have built up a scheme started by the United States military that allows you to map the hardware address (the Ethernet address which is a set of hexidecimal numbers assigned by the network card manufacturer) to a set of numbers that correspond to your organization (the Internet address or IP address). Therefore, the first key to remember is that an IP address is your key to getting on the Internet and therefore all of the TCP/IP software is designed to work with this address (even if you do not plan on surfing the Internet).
Figure 7.7 shows you the panel that will pop up when you go to configure TCP/IP. It is far more complex than the protocol setup panel and also requires that you understand a little bit about the fundamentals of TCP/IP systems before you can answer all of the questions. There are a number of considerations that you would use in making your decision, but let me list a few of the more common ones here:
Configuring the TCP/IP Protocol.
Let's just say that you want to keep things simple and get a basic TCP/IP network up and running. You do not plan on getting on the Internet. What I usually do is specify an explicit set of IP addresses similar to those shown in Figure 7.7 (the 10.x.x.x family is reserved for internal assignments). I set the simple subnet mask of 255.0.0.0. I then set up a special file used by most TCP/IP configurations known as the hosts file (which is a local file which resolves names to addresses similar to the WINS and DNS servers). Figure 7.8 provides a sample hosts file. It is a simple mapping between IP address and a name that is easier for people to type. As you can see, it would be impossible to maintain this table for the millions of people on the Internet, but it works well in small work groups. You need to place this file under your Windows NT directory in the system32\drivers\etc sub-directory. (Mine is in d:\winnt35\system32\drivers\etc because I upgraded to 4.0 from 3.51.) This file should also be distributed to all clients so that they can work with these easy names. For a more detailed discussion on IP address translation, see Chapter 12, DHCP and WINS.
Sample hosts file.
There are a lot of additional considerations with TCP/IP networking. Chapter 11, Installing and Configuring Microsoft TCP/IP goes over the configuration process in much more detail. The key to remember is that every computer that is running on a TCP/IP network at a given times should have a unique IP address. When this type of network is set up correctly, I have found it to run well and provide you with connectivity and service that is hard to beat.
So far, you have laid the foundation for networking, but you do not having much that is useful to the end user. For those of you who labored hours to set up a working IRQ setting on your network card, this may not seem fair. However, now is the time when you get to install the services that will allow your network to be used by the end users to get things done. I have found the services to be relatively simple to set up and configure once the networking basics are out of the way. So without any further ado, let me present the Services tab of the Network setup panel. (See Figure 7.9.)
Network Services setup.
To add to the services that you have installed, choose the Add button. It gives you a list of available services and the option to add additional services from separate CDs or disks (the magic Have Disk button). The most difficult task is understanding what services are available to you (and there is quite a list of services that come off of the operating system CD):
Many of these services are just installed. There are no configuration chores that you have to perform on them. For those that do require some form of configuration, you will be presented with a panel similar to Figure 7.10 that is specific to that particular service. For details on what the various options on this panel mean, you can refer to other chapters of this book and, of course, the Microsoft help system and documentation.
Remote Access setup panel.
As you can see, there are a wide range of services available under Windows NT. The key to something that is implemented as a service is that it will be a background process that is in continuous operation once started, which usually occurs at system startup. Therefore, it is available even though there are no users logged in at the console and running programs. They are essential to Windows NT server 4 being able to server clients on the network.
After the long discussion of options when setting up TCP/IP networking and the many services available under NT server, it is refreshing to see a relatively simple tab on the Network setup panel- the Identification tab. (See Figure 7.11.) This tab sets what other computers on the Microsoft network will see when they are looking for computers. The key components are the Computer Name, which is just a unique identifier for the computer that should make sense to everyone else in your workgroup or domain. The next box for workgroups is your workgroup name. (You would be asked to identify your domain if you chose the Domain option when setting up your Microsoft network.) The workgroup and domain names are names made up by administrators to refer to a particular group of computers. In the domain environment, it has special meaning in that you can teach domains to trust one another and grant privileges to members of other domains. If you are looking for a more detailed discussion of domains and workgroups, the Windows NT Networking Guide in the resource kit provides some good material.
Network identification.
So far, we have covered the various options that are available when you set up networks. Now consider the possibility that you would want to set up multiple network adapters and remote access services that would use different sets of protocols and services, and perhaps even different configuration parameters for those protocols and services. It may seem like an unusual setup to some, but I have run across several examples of this being needed. A classic example would be a server acting as a gateway between two network segments. You may have Novell and TCP/IP machines on one side which your network administrator has assigned the IP address range of 123.123.1.xxx. The other network segment might have Microsoft networking (NetBEUI) and TCP/IP clients, but they use the IP address range of 123.123.2.xxx. In this manner, you can isolate and balance network traffic between different network segments. You would use the adapter configuration tab to set up the IP addresses for the two adapters, but you would then have to use the Binding tab (see Figure 7.12) to configure which protocols went where.
Network bindings.
There are three ways to sort the list of bindings. The one that you choose depends on how you think of things and what problem you are working on. As you can see in Figure 7.12, I have linked the TCP/IP protocol to my network card and the Remote Access Server. If I wanted to remove this connectivity or add in additional connectivity, I would use the Enable and Disable buttons. You would be careful where you are when you start disabling bindings. The key is knowing what protocols, services, and adapters depend upon one another to ensure that you do not disable others things that you want when you disable a particular binding.
Under Windows 95, dial-up networking (the modems) is considered an integral part of networking and are set up pretty much the way you would set up any other adapter. Of course, they have their own property pages that take into account the unique set up parameters of a modem (all of the bit settings and whether you have to display a terminal screen before and after dialing a number). Windows NT 4 server has not quite embraced this philosophy yet. Although you do bind the network wrappers (connections between the computers connected with the modem to computers connected via your network cards) using the network setup panel, you do most of your other work setting up these connections using the Modem option on the control panel. The actual modem connections and privilege setup (who can dial in, for example) is set up through the Remote Access Administration utility accessible from the Startup Menu, Programs selection and Remote Access Service selection. (It is actually easier to show you Figure 7.13 than to describe it.)
Accessing the Remote Access Service Utilities.
The first thing that you need to set up RAS is to have a modem properly configured. This might involve some of the same painstaking work described above for network adapters (such as getting drivers loaded for your modem and resolving IRQ/memory addresses). Figure 7.14 shows you the basic modem setup screen. You have to add a modem type that is supported by Windows NT 4 (again, see the hardware compatibility list or get an NT 4 driver from the modem vendor). You then have to identify a communications port to which that modem is mapped (yet another address when dealing with serial communications devices on Intel PCs).
Modem Configuration panel.
Once you have your basic modem set up, you may have two additional panels to set up. The Properties button gets into the communications details (see Figure 7.15) associated with the modem and its connection (speed, speaker volume, and all of those bit settings common to modem communications take the defaults whenever you can on these items). The Dialing Properties button lets you set up the details of dialing such as whether you need to dial a 9 to get an outside line.
Modem Properties panel.
Once your modem is set up, you are ready to use the Remote Access Admin utility that is located in the Remote Access Service program group show in Figure 7.13. This utility is based on a pull-down menu system that allows you to perform the following useful services:
With the number of people who are accessing networks from remote locations (other groups that you work with or road warriors who travel a lot), RAS connectivity and modem pools are an important part of the Windows NT networking architecture. After having set up similar functions under UNIX and earlier versions of Novell, the RAS configuration is relatively simple and I have found it to be very reliable. I have set up my home PC to dial in to the server and perform functions ranging from simple file transfers from my work PC to interacting with client/server databases using ODBC. If you have a modem, take some time to learn how to use it as a remote administrator. It could save you a trip into work in the middle of the night when your server has a few problems. Chapter 20, Using Remote Access Services goes through the use of RAS in much more detail.
There are a lot of network clients out there (Windows NT workstation, Windows 95, Windows for Workgroups, Macintoshes, and so on). This can present a challenge to administrators who have to support these clients accessing their NT server. The fundamental problem is that you need compatible and working configurations on both ends of a network before communications can take place. It is useful to come up with standard setup procedures for each of the types of clients that you support that contains specifics such as the Internet address of your servers.
One of the challenges with working and providing services in a network environment is that most users only see the end result. For example, they install a new client/server application on their PC and complain that they can't access the database which is on your server. What is the problem? (I can't tell you how many error messages read something like, I couldn't talk to the server.) Going back to earlier discussions, the many layers and bindings involved have to be set up correctly on both ends to make communications happen. You also have to worry about logon IDs and passwords being set and used correctly to provide access to resources that are password protected.
With all of the things that can go wrong, I like to follow some basic checks from the client end to troubleshoot problems.
If anyone has trouble accessing the server, I usually try accessing the server from my workstation using the My Computer icon or File Manager. (Note that File Manager and Explorer allow you to enter explicit network paths that may be available, but somehow the network browsing function does not detect when looking at the available nodes.) You can also use the NET VIEW command at the command prompt (for example, NET VIEW \\joe). This proves the server is up and accepting at least NetBEUI communications.
If I am troubleshooting a TCP/IP link from the user workstation, I go to the DOS prompt and type ping followed by the IP address of the server. If this works, you can try the ping command with the name to see if your problem lies in the name resolution process. Together, these utilities test the basics of TCP/IP networking on the server.
The tools that are available depend to a high degree on your environment. However, if you keep the fundamental principles in mind and start testing the various types of communications from the lower levels (such as Ping and File Manager) and then work your way up in the chain (such as ODBC connections or trying to access a shared directory using the user's logon ID and password), you can usually spot the problem. If all else fails, try doing the same things using the user's logon ID from a similar workstation in the same area and see if that clears up the problem.
This chapter has taken on the somewhat ambitious task of describing the basic setup of Windows NT Server's networking. The operating system comes with a large variety of networking support built in to the basic product. Your challenge is to map out which of the services and protocols are needed in your environment. You might also have to change these services over time as your network world evolves. Most networking is controlled from the control panel or the Remote Access Service utilities. I would like to leave you with my observation that I have found it relatively easy to use NT server to connect to a wide variety of network types (UNIX, Novell, and the Internet) and achieve a high degree of reliability with minimal maintenance once things are set up.
