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.
Overview of Windows NT Networking
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.)
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:
Services and programs: This layer is a series of services that handle the high-level functions that users and applications require. Examples of services would be File and Print Sharing for Microsoft Networks. Windows NT Server also has some services that run in background and are available whenever they are started (even if no one is logged into the server console). Examples of these services would include the FTP server or the remote procedure call server. Finally, there are a series of applications that are run in the foreground that provide specific networking services such as checking to see if other TCP/IP computers are available (Ping) or to log into a remote computer (Telnet).
Protocol: This is the language and format of the communication signals. This really gets into some dirty, gut-level communications parameters, but for the purposes of most system administrators, all you have to worry about is that you are using the same protocol on all machines that you want to communicate with. You should be careful with NT, which allows multiple protocols to be available at a given time to ensure that you have the appropriate protocols for all of the applications and remote machines supported by your NT server.
Adapter: This is the device that connects the logical signals that you formed in the protocol portion of the hierarchy to the physical wires (or electromagnetic emissions, because there are some wireless networks out there) that connect your computer to other computers. Windows NT considers a modem to be a network adapter (although it also provides additional control panel icons to set it up completely), and you also have to set up protocols and services for the modems.
Standards Implemented in Windows NT 4.0
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:
TCP/IP protocol for communications with the Internet and UNIX worlds.
NetBEUI protocol for communications with traditional Microsoft networks such as those under Windows for Workgroups.
IPX and SPX protocols, which allow communications with Novell Netware networks using their own language (not a gateway or interpreter).
Remote access services (a Microsoft standard) allows you to dial in from compatible Microsoft remote computers to your server and from your server to other Microsoft remote computers (such as Windows NT and Windows 95).
The Telnet program allows you to connect to remote servers (such as UNIX computers) that have a Telnet server active. You effectively become a terminal on that computer through this program.
FTP services allow other workstations that have FTP to connect to your workstation and your computer to connect to other FTP servers.
Remote procedure calls (RPCs) allow you to execute programs on other computers that support RPCs.
Named pipes allows you to connect two Windows applications together to communicate.
Open Database Connection (ODBC) enables client/server applications to communicate with databases for queries and results.
Object Linking and Embedding (OLE) allows applications to communicate with and use one another in a cooperative fashion. OLE can be used for simple functions such as embedding a spreadsheet in the middle of a document or complex functions such as communications between a client application and a database server.
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.
Common Networking Protocols
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 guides 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:
An overview of the history of the protocol
The basics of how the protocol transmits signals
A discussion of the pros and cons of this protocol
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:
It is the most accepted protocol in the world. Almost all major computer operating systems support this protocol. A huge suite of software (from Internet web browsers to client-server database tools) is build to use this protocol.
It is robust enough to support demanding communications. For example, it is extremely difficult to get reliability and performance for client-server database communications in the Oracle database management system using NetBEUI, but things work very smoothly under TCP/IP
You can route TCP/IP thereby segmenting your network into segments that carry only the traffic that is applicable to their users. Also, with a well-defined set of application-specific interfaces (sockets), you can control what type of traffic is allowed on to a network segment. This is one of the keys to security devices such as firewalls.
It is a multi-purpose transmission protocol. Therefore, it is not optimized to simple file and printer sharing services, although it gets the job done.
It requires a fair amount of configuration work to get everyone talking to one another. You absolutely need a plan and control mechanisms before you implement a TCP/IP network.
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:
It cannot be routed. Therefore, you cannot segment your network without losing the ability to communicate between certain computers or using another protocol such as TCP/IP.
It is small and efficient for the tasks that it was designed to accomplish. Most of your basic workgroup and small domain processing fits into this category.
It is supported on a wide range of Microsoft and IBM PC operating systems (which make up the majority of computers installed today).
It is not robust enough to handle demanding messaging needs such as client-server database transactions.
It is really simple to configure and would be a good choice for a small, simple local area network.
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 guides 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:
It is the most common way to interface with Novell Netware networks. Chapter 22 covers this interface in more detail, but it is impressive at how smoothly you can integrate NT into a Novell environment and share resources.
It is a routable protocol
It is a fairly robust protocol and able to handle some more demanding network applications
It is small and efficient for the types of communications it was designed for (file and print sharing)
It is simple to configure
Configuring Networking in NT 4.0
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 chapterNetwork. 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.
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.
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.
Network Adapter Setup
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.
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.
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:
Keep all of your hardware manuals and read them.
Look at your boards that have jumpers and record what their settings are.
Make a chart that shows the addresses used by your various system components so that you can figure out what is available.
If you are really stuck and comfortable with Windows 95, try installing Windows 95 on this machine first to see if the setup wizards in Windows 95 can figure out a workable combination of settings for the hardware in your machine.
After that, you're working a puzzle to see if you can get all of the pieces to fit together.
Network Protocol Setup
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:
If you might be using the Internet, you need to load TCP/IP.
If you are going to be doing a lot of client-server database work, you should seriously consider using TCP/IP or IPX, not NetBEUI.
If you just need a simple Microsoft network, NetBEUI is probably the easiest protocol to set up.
If you are going to be coexisting with Novell Netware systems, the IPX/SPX protocol is needed.
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.
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:
IP addresses are made up of a series of four numbers (bytes) ranging between 0 and 255 that are separated by periods (such as 18.104.22.168).
If you are on an isolated network that you do not intend on connecting to the Internet, then you can make up your own addresses (by convention, you should use addresses in the 10.x.x.x range). Keep all of the addresses that you want to communicate with one another starting with the same first number.
If you are on a network connected to the Internet, then you have to have someone (usually in the network group) who parcels out official addresses. Otherwise, they are coordinated by someone responsible for your local network.
The subnet mask parameter is designed to help you ignore addresses that are not of concern to you (outside of your group and therefore the responsibility of a gateway if you have one). The subnet mask is a bit pattern comparison (255 in one of the digits means that the address incoming has to match while 0 means let everything in this digit pass). For example, 255.0.0.0 as a subnet mask means pass everything that has the same first number as my address and reject everything else.
Gateways are computers or network devices that allow you to communicate outside of your local network to the bigger world. When you define a gateway (or multiple gateways, TCP/IP traffic that is outside of your subnet mask is routed to the gateway(s) to see if they can resolve the address and transmit the information to the remote computer. You may actually go through a series of gateways when transmitting to distant computers.
Domain name servers are computers that allow you to use text names instead of IP addresses to describe remote computers. These are officially assigned names that are coordinated through the various Internet agencies and reflect the purpose and country in which the computer is located. (For example, aol.com references America Online; com identifies it as a commercial organization and the lack of a country suffix indicates that it is in the United States.) Windows NT can act as a domain name server or use it to translate IP names for your users. You are allowed to have primary and backup name servers in case one of these computers is unavailable.
WINS stands for Windows Internet Naming Service, which allows you to enter the IP addresses for your local computers and have other computers use these central lookup tables to translate a name into an address. This product now works together with DNS to resolve names on networks with both local and larger scopes. Again, NT can act as a WINS server or use its services.
The routing tab determines whether your workstation will forward packets that it receives that are intended for other TCP/IP computers that it can communicate with (for example, act as a router). This can be useful if you have multiple networks and want to use one of your servers to forward traffic and connect the two networks together, but only transmit those packets that need to cross between the networks.
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.
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.
Network Services Setup
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.)
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):
Computer Browser: This service allows you to see a list of computers that are available on the network.
NetBIOS Interface: This is the basic interface to the Network Basic Internal Operating System.
Server: This allows your machine to act as a network server.
Workstation: This provides the services that you will need when using your server as a workstation.
BOOTP Relay Agent: This was the predecessor of DHCP; use it if you already have such a network else stick with the newer DHCP service. (You never know when they'll drop support on older products.)
FTP Server: This service allows your computer to provide access to its files to other computers using the file transfer protocol common to UNIX and other computers.
Gateway (and Client) Services for Netware: This is your door into the world of Novell Netware providing you with file sharing, print sharing, and other common Novell services.
Microsoft DHCP Server: This service, the dynamic host configuration protocol, allows your computer to act as a master repository for IP addresses so that you do not have to assign them manually to each computer..
Microsoft DNS Server: This allows your computer to act as a TCP/IP domain name server.
Microsoft TCP/IP Printing: This allows your computer to use UNIX TCP/IP print job transfer services (LPR/LPD).
Network Monitor Agent: This allows your computer to perform basic monitoring on the network.
Network Monitor Tools and Agent: This provides tools to allow your computer to monitor the network via the Simple Network Monitoring Protocol (SNMP).
Remote Access Service: This is the modem interface under Windows NT that allows you to dial in to the server.
Remoteboot Service: This allows your server to serve as the boot drive for remote computers with compatible remote boot software.
RIP for Internet Protocol: This allows your computer to route TCP/IP traffic between segments on your network (i.e. act as a router).
RIP for NWLink IPX/SPC Compatible Transport: This allows your computer to determine routes for IPX/SPX (Novell) traffic on your network.
RPC Configuration: This allows you to execute remote procedure calls (a standard way of executing jobs on other computers in the UNIX world).
RPC Support for Banyan: This allows you to execute jobs on computers using Banyan networks.
SAP Agent: This Service Advertising Protocol allows remote computers to determine the network access points on your computer.
Services for Macintosh: This provides you with a gateway into the world of Macintosh Appletalk networks. (See Chapter 10, Working with Macintosh Clients for further details.)
Simple TCP/IP Services: This provides you with the basic services that you need to participate in a TCP/IP network (many other services require this service before they can start).
SNMP Services: This allows your server to provide basic operational information on load, availability, and so on, using the Simple Network Monitoring Services protocols that can be read by a number of monitoring packages.
Windows Internet Name Service: This allows your server to resolve IP addresses for clients on your network.
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 guide and, of course, the Microsoft help system and documentation.
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.
Network Identification Setup
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.
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.
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.
Remote Access Service (RAS)
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.)
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).
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.
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:
Start/Stop your remote access service (such as stop picking up incoming calls). Note that you might need to do this to allow other applications to access your modem because RAS tends to monopolize the modem even when it is not actively processing a call.
Grant permission to users to dial in from remote locations.
Show users who are currently connected to RAS.
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.
Network Client Setup
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.
Useful Networking Utilities
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.