The most important element of a successful PC network installation is thorough planning. To be successful, a network needs to be efficient and effective. Efficient means that the network is technically elegant, is installed within budget, and is maintainable and expandable with minimum staff time. Effective means that the network fully serves the needs of its users.
This chapter presents the 11 key issues you must consider to plan your network properly. Depending on your particular environment and the scale of your network, some of these issues take precedence over others. Regardless of priority, each issue is important and deserves consideration in the planning process. Considering each planning issue in turn helps you develop a framework for your network, prevents you from overlooking important needs, and avoids common stumbling blocks along the way to implementation.
This chapter explains how to
Traditionally, most Windows NT Server installations occur within a corporate or institutional environment. Windows NT Server is particularly appealing to small to mid-sized organizations because of its relatively low acquisition cost, moderately priced client licenses, ease of installation, and simplicity of maintenance. Although Microsoft proudly points to "buys" of hundreds of Windows NT Server installations, plus thousands of Windows NT Workstation licenses from well-known Fortune 500 firms, single-server installations with 10 to 100 clients fuel much of the momentum of the Windows NT market.
You can download the current version of Microsoft's Enterprise Planning Guide (for large organizations) and the Deployment Guide for Windows NT Server and NetWare Integration from http://www.microsoft.com/ntserver/epds.htm. When this book was written, these two guides had not been updated to Windows NT Server 4.0. The basic concepts outlined in these two publications, however, apply equally to versions 3.51 and 4.0 of Windows NT Server.
Regardless of the size of the organization adopting a Windows NT 4.0 network, the following 11 topics are critical to the planning process:
The sections that follow describe these planning elements in detail.
It's easy to focus so much attention on the technical issues of planning a network that you lose sight of the primary goal, which is to meet your organization's strategic and tactical business objectives. These objectives may be stated broadly-for instance, "To improve corporate-wide communications among all employees." The objectives may be stated more narrowly: "To provide access to Internet mail and the World Wide Web for executive and administrative staff members." In many cases, the objectives may not be explicitly stated. Whatever the case, you can be sure that before management approves the funds to implement your network installation or upgrade, management must see that the plan will meet a perceived objective or solve a problem.
Talk to upper management to discover the rationale for the project, keeping in mind that the stated reasons aren't always the real reasons why such a project has been initiated. Find out what results upper management foresees. Ask what management expects to be accomplished when the project is complete, or what should be done more quickly, inexpensively, or efficiently as a result of the project.
Sometimes the real motivation behind the project doesn't originate with upper management at all, but instead derives from a particular department head or group within the organization. It's up to you to uncover the true objectives of the network installation, and to make sure that the network you design and install meets the objectives, solves the problems, and fulfills the expectations of your executive management.
The planning stage also is the time to consider proposing that the scope of the project be expanded beyond that originally requested. Upper management focuses on the big picture and, as a result, is typically unaware of all the implications and possibilities inherent in networking technology. It often happens that planning a network project to solve stated needs also offers you the opportunity to address other pressing computer-related problems with minimum additional money and effort. Upper management may not even realize that the organization is missing such an opportunity, unless you describe the opportunity. Often, by spending a bit more money, you can kill two birds with one stone; sometimes you can even nail an entire flock.
You want to keep upper management happy, because it controls the size of your paycheck. But you also want to keep users happy, because unhappy users can make your life miserable. Take the time early in the planning process to find out what users expect from the network; then modify your plan, as needed, to give them as much as possible of what they asked for. If management requirements determine the strategic thrust of the network, user needs determine the tactical direction.
The core unit of network planning, a workgroup comprises a group of people who share related job functions. Workgroups are typically-although by no means always-formally defined units of the organization. Members of a workgroup often not only use specialized software not used elsewhere in the organization, but they also have a common need to access the same data. A workgroup can range in size from one or two people in a small firm's accounting department to hundreds or even thousands of people in the outbound telemarketing group of a large firm. Figure 2.1 illustrates a network comprising three workgroups-Personnel, Engineering, and Finance-each of which has at least one workgroup server, connected by switched Ethernet. The key to determining what comprises a workgroup is to discover shared job functions, plus similarities in the software used and the data accessed.
2.1
Personnel, Engineering, and Finance workgroups connected by switched Ethernet.
After you analyze the workgroup makeup within your organization and determine which workgroup will be affected by the project, the next step is to talk to workgroup leaders to find out their views on the project. Depending on the workgroup's size and how much time you have available, you may find it worthwhile to talk to each staff member in the group, either individually or in a group meeting. It's during this process that you discover the detailed information about user needs that will allow you to make the network more useful to the people who actually use it. No one is in a better position to know the real day-to-day problems than the folks in the trenches. All you have to do is ask them.
Workgroup members are likely to tell you where shared printers should be located, that they can't read accounting Excel worksheets because they have only Quattro Pro, that having Internet mail would let them deal with customers more efficiently, or that their 486SX PCs are too slow to run the new version of the inventory software. All of this is useful information that you never discover unless you ask. You'll also hear a lot of requests that you can't possibly grant, so don't make the mistake of letting workgroup members believe they'll automatically get everything they want.
Ask specific questions, such as "Where would be the best place to locate the network laser printer for your workgroup?" as well as more general questions, such as "What two or three things could we do to make your life easier?" After you go through this process with each workgroup, you have a much better idea of how to configure your network and what minor changes and additions you can make that have a big payoff. You also become a hero to the users, simply by asking the questions.
Now is also the time to consider whether workgroups not a part of the original plan can be added to the plan at little or no additional cost. For example, the original project might cover connecting the accounting workgroup to a server that shares an accounting database. During the planning phase, you might discover that the human resource management (HRM) group located on the other side of the wall could also be connected within budget and run its HRM application on the same server. Often, all that stands in the way of providing a major benefit to an overlooked workgroup is a few Ethernet cards and an additional hundred feet or so of cable.
Workgroups often are provided with a server dedicated to specific workgroup activities, such as accounting, purchasing, production, and marketing. The constantly decreasing cost of server hardware makes distributing the server workload among workgroups economically feasible. The workgroup servers are organized as members of a common domain serving a single geographic site. Chapter 16, "Distributing Network Services with Domains," describes the topology of Windows NT Server domains. You also can download a copy of the Microsoft white paper "Windows NT Server Domain Planning for Your Enterprise" from http://www.microsoft.com/ntserver/enter.htm.
Security means protecting your hardware, software, and data. The time to start thinking about security is during the network planning process. Security is made up of the following four elements:
Although your environment may make it difficult or impossible to physically secure all your components, strive to put all server-related hardware behind locked doors. Physical security for network servers is especially important today because of the recent trend toward burglary of server-grade PCs. Servers have the latest Pentium or Pentium Pro chips, large amounts of memory, high-speed disk drives, and other costly components bringing top dollar from PC fences.
Even more important for most organizations is the possibility of their data being stolen. This is a two-edged sword:
All servers and active network components should be situated in equipment rooms or wiring closets, and only you and your network administrative staff should have the keys to these locations. This can be a hard battle to win because, invariably, some users and managers feel they have the right to gain unrestricted access to "their" equipment. These folks will resort to everything from quoting fire codes to lobbying senior management to obtain such access. Stake out your claim early and fight to keep it. After all, you're responsible for maintaining the equipment and assuring its online availability; such responsibilities require that the network administration team have absolute control of the server(s).
If you do secure your equipment rooms, also be sure to establish a key-control policy to ensure that those on the approved list can always gain access when necessary. Designate backup staff, and make sure that each backup person is provided with a key or with access to the key box. Otherwise, if the primary person is sick, on vacation, or simply unreachable, the backup person may be unable to effect repairs simply because he can't get through a locked door.
Here's an example of what can happen if you lose the server access battle: A workgroup is down. Your staff expert appears, determines that the problem is caused by a misbehaving router, and decides to reboot the router-not a trivial decision. He notifies users in other affected workgroups throughout the building, shuts the network down in an orderly fashion, and reboots the router. The problem is solved and your expert returns covered in glory. Now consider what the users observed. Their workgroup was down, and the expert rebooted the router by pressing a big red button. A week, a month, or a year later, that workgroup goes down again. They call the expert for help, wait for 15 minutes with their arms crossed, and then decide that no one will show up any time soon. One bright person remembers the last time that this happened, the expert pushed the big red button on the box in the corner. The person pushes the button and takes the entire network down without notice. Guess who takes the blame?
In addition to securing access to your active network components, one step you can take to avoid such problems is to establish and post clear policies concerning how and to whom problems should be reported. Be sure to post this information where it's readily accessible to users, and not locked up in the server room. Put them instead over the coffee machine, where the users may actually notice them.
Unless your IS department or help desk is open around the clock, pay particular attention to how users should report problems after hours. Someone working desperately in the evening or on a weekend to meet a deadline may feel he has no alternative but to attempt repairs himself. Simply designating an on-call person and posting his pager number can potentially avoid a lot of grief.
Unlike physical security, which is primarily concerned with protecting your network hardware from unintentional abuse by employees, data communications security focuses primarily on protecting your data from being compromised by outside intruders. Managers of most local area networks (LANs), which are self-contained within a building or campus, don't need to be too concerned about over-the-wire data communications security. If your LAN is connected to the outside world in any fashion, however, you must take steps to prevent unauthorized access to your data by outside parties.
One important aspect of security is protecting your data from viruses. Most of today's viruses propagate via online data communication, usually as a result of downloading infected files from the Internet or bulletin-board services. Windows NT 4.0 virus-scanning programs are available now from several vendors (including McAfee, Intel, and Symantec), and more are on the way. Figure 2.2 shows the main window of McAfee VirusScan for Windows NT after finding no infected files on the server drive. Any of these scanning products will detect any virus you're at all likely to see in the real world. Don't be too impressed by how many viruses each claims to detect or pay too much attention to the comparative claims. All of them are good; none of them is perfect.
2.2
The main window of McAfee Virus Scan for Windows NT, with no viruses detected.
The burgeoning of wide area networks (WANs) and the use of the Internet to carry corporate traffic brings the data communications security issue to the forefront. Banks and other financial institutions long ago established private secure data communications networks to avoid the danger of their data being intercepted or otherwise compromised. Even private, secure networks have been compromised by determined hackers. If your environment requires you to establish links between networks at multiple locations, or if you plan to provide remote access services to mobile users, you should plan to provide at least some data communications security. Depending on your particular needs, ensuring data communications security may be easy and relatively inexpensive, or it may be quite complex and extremely expensive.
If your security needs are modest, you have only two or three locations in close proximity to link, and you don't need dial-up network access, leased lines from the telephone company (telco) may be the solution. Because leased lines provide a hard-wired dedicated link from one location to another rather than go through a telephone company switch, leased lines are inherently secure. This security stems not from any special efforts made to secure the link, but simply from the fact that the link is inaccessible to would-be eavesdroppers.
If, on the other hand, you need to link many widely geographically dispersed locations, you may have a greater problem. The cost of leased lines-especially lines providing high link speeds-mounts very quickly, and even leased lines may not provide an adequately high level of security for your needs. Because you pay for the dedicated bandwidth of a leased line 24 hours a day, 365 days a year, whether you're using the line or not, most companies use packet-switching networks, which charge on a usage basis. Packet switching has brought the cost of providing high bandwidth links to multiple locations within reason. From a security standpoint, the down side of packet switching is that, by its nature, packet switching combines the data from many companies and places all the data on a common carrier, thus making data vulnerable to interception and compromise at many points along the way.
Until a year or two ago, using packet switching usually meant contracting with AT&T, MCI, H&R Block, or a similar provider of specialized data delivery services. During the last two years, organizations have increasingly turned to the Internet to provide low-cost packet-switched data delivery. In theory, the Internet is an insecure means of data delivery. In practice, the Internet is probably at least as secure as your telephone. Just as your voice telephone conversations can be intercepted by anyone with a reasonable degree of technical competence and the motivation to do so, your Internet traffic can also be intercepted.
You can avoid having your data compromised by using data encryption, either at the application level or at the packet level. Encryption doesn't prevent your data from being intercepted-it simply garbles the data, making it useless to the eavesdropper. How you implement encryption determines what level of security encryption provides for your data.
Application-level encryption depends on the software you're running to perform the encryption. This can be a workable method as long as it occurs without requiring user intervention. For example, a client/server database application may be designed so that the client- and server-side software both encrypt outgoing traffic and decrypt incoming traffic transparently to the user, leaving the would-be eavesdropper watching a stream of random garbage characters.
Application-level encryption that depends on user intervention can't be considered a reliable means of protecting data. For example, although your e-mail package may allow you to encrypt outgoing messages on demand by taking certain manual steps, the likelihood that individual e-mail users will remember how to encrypt their message-not to mention the likelihood that they'll go to this extra trouble-is small. Depend on application-level encryption only in specialized circumstances, and even then only when the encryption is invisible to the users.
Microsoft's Internet Information Server 2.0, included with Windows NT Server 4.0, provides Point-to-Point Tunneling Protocol (PPTP) for secure communication over the Internet. PPTP is discussed in Chapter 18, "Managing Remote Access Services," and Chapter 19, "Setting Up the Internet Information Server."
Packet-level encryption occurs at the hardware level, typically in the boundary router or in a specialized device designed to handle it. Packet-level encryption encrypts the data portion of each outbound packet, but leaves unchanged the packet and frame header and trailer data, including the source and destination addresses. This means that the encrypted packets can be handled by standard devices along the way to the destination. At the destination, a similar device strips the packet and frame header and trailer information, decrypts the data portion of the packet, and delivers the decrypted data to the addressee.
Packet-level encryption devices can be configured to allow you to designate that only specific networks require that packets sent to them be encrypted, allowing data destined for other networks to go out unencrypted. Thus, for example, you can designate each company network site as requiring encrypted data, while allowing users to access other sites normally. This is particularly useful if you plan to use the Internet to deliver your data securely. Figure 2.3 illustrates the use of encrypting routers to assure privacy of communication over the Internet.
2.3
Using router-based encryption to ensure communication privacy on the Internet.
Firewalls are another tool in the datacomm security arsenal. Unlike encryption, which is concerned with protecting data in transit, a firewall is designed to control access to your network. A firewall filters out inbound traffic unless that traffic originates from an approved source. Likewise, a firewall can be configured to filter outbound traffic, thereby allowing internal users to access only approved external hosts.
Like any technology, firewalls aren't a complete guarantee. It's possible for a technically knowledgeable person to spoof an authorized host and get past your firewall. Still, firewalls are becoming extremely popular as a means to isolate secure internal networks from the anarchy of the Internet. Microsoft's Internet Proxy Server for Windows NT-in the beta-test stage and code-named Catapult when this book was written-is an example of a firewall that you can implement at moderate cost.
Everything has its price, and security is no exception. Assigning long, randomly generated passwords makes it much more difficult for a hacker to guess a password, but at the same time makes life more difficult for authorized users. Securing all your equipment behind locked doors limits the chance that the equipment will be damaged accidentally or maliciously, but it also makes it more difficult for your staff to maintain the equipment. Installing over-the-wire encryption hardware and firewalls minimizes the likelihood that your data will be compromised in transit, but it also requires expensive equipment and scarce staff time to install and maintain.
Too much security can be counterproductive-not only in terms of time, money, and effort, but in terms of compromising the security itself. For example, many organizations mandating long, random, frequently changed passwords simply did it because it seemed to be a "good idea at the time." They've been surprised to find a blizzard of yellow sticky notes posted on each monitor with the users' passwords written on them. Don't attempt to establish security features that require extraordinary user effort. Instead, determine what data must be protected, and at what level of security. Plan for as much security as you really need, where you need it, and no more.
Fault tolerance is a system's capability to continue to function after the failure of one or more critical components. The key to fault tolerance is the use of redundancy to eliminate single points of failure. Most networks provide at least some fault tolerance, although it may be limited to installing an uninterruptible power supply (UPS) to protect against power failures, and perhaps a RAID (redundant array of inexpensive disks) subsystem to guard against fixed-disk failures. Some networks are fully fault tolerant, achieved by providing online backup spares for each device on the network.
UPSs and RAID systems are briefly discussed in Chapter 5, "Purchasing Networking Hardware." RAID systems are covered in detail in Chapter 7, "Setting Up Redundant Arrays of Inexpensive Disks (RAID)."
Building a fault-tolerant network is expensive, and the more fault tolerance you build in, the more expensive it becomes. The cost of providing a backup bridge for each working bridge, a backup router for each working router, a backup server for each working server, and so on escalates quickly. As a result, most networks use redundancy only at those points that are either most critical or most likely to fail. Power failures are both common and critical, so nearly all networks use UPSs to protect against them. Disk failures are less common, but because they're critical, many network servers are equipped with RAID disk subsystems. Hubs, bridges, and routers fail very infrequently, so it's uncommon to see full redundancy implemented for these components.
One means of providing server fault tolerance is to implement a fail-over system, in which duplicate servers are connected to a single RAID system by a SCSI adapter in each server. Microsoft announced at the Windows Hardware Engineering Conference (WinHEC) in the spring of 1996 the intention to support fail-over redundancy as the first step in the company's plan to implement clustering technology for Windows NT servers. Fail-over clustering is expected to arrive in early 1997, as an extension of Windows NT Server 4.0.
To learn more about the future of clustering, download the white paper "Microsoft Windows NT Server Cluster Strategy: High Availability and Scalability with Industry-Standard Hardware" from http://www.microsoft.com/BackOffice/reading/clusterwp.htm.
To determine fault-tolerance requirements, you must determine the answers to the following questions about each component of the network:
When most people think about fault tolerance, they think only about hardware. A commonly overlooked fault-tolerance issue is data communications reliability. If your network is connected to remote branch offices, vendor and customer sites, or to the Internet, you must consider the reliability of each such link and determine the criticality of the data carried on the link. If the data is high-volume, real-time, and critical to your organization's operations, you may need to duplicate the high-speed links to each remote site. If the data is lower volume or less critical, you may be able to get by with a dial-up link as a backup to the main high-speed link (see fig. 2.4). In the case of batch-mode data transfer, you may be able to dispense with a backup link completely.
2.4
Substituting analog modem connections over the switched telephone network for a failed T1 leased line.
Another issue to consider is designing for fault tolerance by location. For example, your internetwork may comprise a main office in Chicago, plants in Pittsburgh and Winston-Salem, North Carolina, and both national and international sales offices. Consider designing your networks and siting your data storage so that, in the event of a data communications link failure, each site is self-supporting to the greatest extent possible. That way, when the link from the Cleveland sales office to corporate headquarters goes down, Cleveland can continue to sell and service accounts, albeit perhaps without real-time inventory data or delivery schedules. Similar results can be achieved on the local level by loading software locally on workstations rather than centrally on the server, replicating databases to multiple servers, having at least some locally attached printers, and so forth. Replication of information stored in relational databases is one of the subjects of Chapter 22, "Running Microsoft SQL Server 6.5."
Hardly any organization (except, perhaps, the military) builds fully fault-tolerant networks. Doing so can double, triple, or even quadruple network costs, both in terms of initial cost and in terms of ongoing monthly charges for things such as datacomm lines, maintenance agreements, and so on. At the same time, hardly anyone builds networks without at least some degree of fault tolerance.
The key, as usual, is to balance cost versus performance. Install just as much fault tolerance as you really need. If you can't afford even that much, install as much as you can afford, focusing your efforts on the items most likely to break and on those that will cause the most trouble when they do break. If this means that all you can afford is to install a UPS on the server, do so. Don't worry about what you haven't been able to do. Doing anything to increase fault tolerance is better than doing nothing. You might be better off putting some of the fault-tolerance money into a faster server or a network management application package.
In the best of all worlds, you can plan your new network from the ground up, choosing the best components to fit each requirement and integrating the whole into a smoothly functioning system. In the real world, however, you seldom have this luxury. The year-old server in accounting can't be thrown away. The folks in marketing are running NetBEUI on a peer LAN and would rather fight than switch networking protocols. Administration is running IPX/SPX on a Novell NetWare 3.12 server, using a critical application that runs only as a NetWare loadable module. Engineering is running TCP/IP on UNIX workstations. The graphic designers in the publications department have Macintoshes connected by an AppleTalk network. Office politics alone prevent you from changing any of this, even if you had the budget to replace everything (which you don't). Welcome to the real world.
In one sense, the presence of these legacy systems can work to your advantage by providing you with information about user needs, throughput requirements, and so on. The down side is that existing equipment may be outdated, expensive, or impossible to maintain; use protocols incompatible with those you plan to use; or lack support for the network management software you intend to install. One of the hardest aspects of planning a new LAN or a substantial upgrade to an existing LAN is taking these legacy situations into account. Legacy problems can be divided into the software- and protocol-related issues and the hardware issues described in the next two sections.
Fortunately, Windows NT Server gives you most of the tools needed to resolve software- and protocol-related problems. Unlike server software from Novell, IBM, and other vendors, Windows NT Server was designed from the ground up to work in a heterogeneous environment. Windows NT Server provides native support for IPX/SPX, NetBEUI, and TCP/IP, thereby eliminating many of the problems of dealing with a mixed-protocol environment. Various add-on products are also available from Microsoft and third parties to provide extended functionality for TCP/IP and NetWare integration, making your job just that much easier. See Chapter 17, "Integrating Windows NT with Heterogeneous Networks," for a complete discussion of these software- and protocol-related issues.
If your network will be connected to the Internet, the network must provide TCP/IP support at the server and at the workstations. Now is the time to begin planning for the Internet connection. There are three main points to consider:
Hardware-related integration issues can be thornier than software issues, especially because candidates for replacement are usually hubs, routers, and similar active network components. These hardware devices seldom are seen by upper management, who almost never understand their function. Deciding what legacy networking hardware to keep and work around versus what hardware to replace may be easily accomplished in isolation, but explaining to upper management why it makes sense to replace a recently purchased and expensive piece of networking equipment can be a tough sell. Sometimes you can successfully explain matters to management and convince them of the necessity; sometimes the "Trust-me-we-just-have-to-do-this" method works; and sometimes you just have to buy the replacement hardware quietly, put the older component on the shelf as a "spare," and hope that no one ever inquires too pointedly about it.
You typically replace existing networking hardware for at least one of these reasons:
A network built with fully managed components can often operate with half the network staff required to operate an unmanaged network, and can do so more efficiently and more effectively. Still, upper management often doesn't fully appreciate the efficiencies of using managed components. You can tell management all day long that managed network components make the difference between making a five-minute change from your desk and having someone spend four hours driving out to a site and making the change manually. Management often still sees only the direct additional costs involved in installing managed components, and ignores the indirect costs associated with using your staff inefficiently. If your network will be medium-size or larger-particularly if you'll have equipment installed at multiple sites-fight for managed components.
Few networks these days are pure LANs. The proliferation of remote access servers, fax servers, branch office connectivity, and connections to the Internet give a WAN aspect to most so-called LANs. Unless your network has no connections to the outside world, you must understand wide-area connectivity issues in order to plan your network installation properly. The days when the "phone people" and "data people" were separate groups reporting to separate department heads are long gone. If you don't know what a hunt group is or how a BRI ISDN line varies from a T1 connection, find out before you plan your network infrastructure, not afterward. Data communications line charges are becoming an increasingly large portion of monthly IS costs as more and more LANs are extended into WANs. Competition between common data communication carriers has resulted in a bewildering array of alternative services with a wide range of installation, monthly, and usage charges.
The best place to start learning about data communication is your local telco. Ask to talk to the telco's data communications group and set up a meeting. After you understand the basic issues, you're in a much better position to compare the alternatives available for data communications, along with the telco's installation costs and monthly service charges. Understanding the basics also lets you make informed decisions regarding competitive services available from various sources, including your local telco, AT&T, MCI, Sprint, and other common-carrier service providers. After you understand the fundamentals of packet switching, for example, you're in a much better position to judge whether frame relay or ATM makes sense for your WAN.
Data communications is a rapidly changing area of technology. Its terminology is confusing and changes constantly. Sometimes it seems that the price and availability of a particular service vary with which clerk happens to answer the phone. Nevertheless, planning your network properly requires that you have at least a working knowledge of data communications technology.
Is the most frequent question you hear, "How much is this going to cost?"? If so, bringing up a strong second place has to be, "How long is this going to take?" Although some elements of timing are within your control, in many cases you're at the mercy of outside parties, over whom you have little or no control. Purchasing delays, hardware vendor lead times, and data communications line installation delays conspire to prolong the process.
Making matters worse is the interdependency of some elements. Having a necessary hardware component show up one day late can cause a two- or three-week delay, if the result is the telco rescheduling line installations. You may find that everything necessary shows up just when your staff is 100 percent committed to some other activity that can't wait. You may be ready to proceed, only to find that accounting is processing payroll, preventing you from doing that department's upgrade when planned. Julius Caesar's law says that nothing comes in on time and under budget, and nowhere is this more true than in a network installation.
For all the preceding reasons, develop a detailed implementation schedule, and then do your best to stick to it if you want to have your network installed in a timely fashion. The best way to do this is to purchase and use a project-management software package, discussed in more detail later in the section "Using Project-Management Software to Manage Resources and Schedules."
Network management protocols have been developed to allow the network administrator to manage connected devices, track resource usage and trends, and detect and correct critical errors and problems, all from a central management workstation. For all but the smallest networks, having remote management installed can mean the difference between a network easily maintained with minimum staff time, and a network occupying your staff full time just to make routine changes and repairs.
Network operating-system-level utilities intended to ease user administration, track disk space allocations, administer password policies, and so forth provide useful functions, and certainly fall under the umbrella of network management. So, too, do application metering programs, backup utilities, and LAN hardware inventory programs. Packet-level analysis tools such as sniffers, protocol analyzers, and cable meters are invaluable in tracking down physical problems on the cable, misbehaving components, and the like.
More important by far to the task of keeping the network up and running efficiently on a day-to-day basis, however, are the standards-based applications designed to monitor and manage your active network components remotely by using protocols such as SNMP and Management Information Base (MIB). These applications function by using a central management station to query and control management agents installed on various critical system components, such as hubs and routers. Proxy agents installed on managed components also can be used to monitor components that aren't themselves manageable. For example, a proxy agent running on a managed router may be used to monitor a dumb hub, which otherwise wouldn't be manageable.
These applications monitor your network by allowing you to set threshold levels, referred to as traps, for various criteria on the management agent for critical system components. When one threshold level is exceeded, the management agent informs the software running on the central management station, allowing you to take action to correct the problem. Another function of network management applications is remote management. A managed component can be controlled from the central management workstation, eliminating the need to make an on-site visit to make programming changes.
Although the underlying network management protocols used by these applications are standards-based, the implementations aren't. Although the standards-based protocols offer all the basic tools needed for network management, they pay little heed to interface requirements and ease of use. Also, standards-based protocols, by their nature, must use the least-common denominator, making no provision for managing extended features and enhanced functions specific to a particular brand and model of component. As a result, major vendors have developed proprietary network management software that's specific to their own components. These products, many of which are Windows-based, provide graphic representations of the installed components, allowing monitoring and management simply with a mouse click.
Figure 2.5 shows a UNIX-based network management system displaying a diagram of traffic over a wide-area internetwork. The downside is that all but the very high-end management software products work only with the manufacturer's components, providing little or no management capabilities for components from other manufacturers.
2.5
A diagram of traffic over a wide-area internetwork (courtesy of Hewlett-Packard Company).
Installing network management isn't inexpensive. In addition to the cost of the components themselves, a central management station and management software must be purchased. Management software normally starts around $5,000 for element managers, and escalates rapidly to $20,000 and above for full-function enterprise managers. The cost of the management station itself isn't insignificant, because most of these products specify a minimum of a high-end Pentium with 16M or 32M of RAM and a 21-inch monitor. Some of them require a $30,000 Sun or Hewlett-Packard workstation. Still, all these costs pale in comparison to the usual alternative-hiring additional skilled staff to maintain the network as it expands and extends to remote sites.
For most medium-size and larger networks-particularly those that support multiple sites-the cost of installing network management is quickly repaid in increased productivity and in a reduced need to expand staff as the network grows and extends to other sites. At the same time, given the relatively high cost of purchasing the central management workstation and software, you certainly don't want to duplicate these costs to provide additional stations. Because network management software is proprietary, the only way to avoid doing so is to make sure that all your managed components are provided by the same manufacturer.
Microsoft's System Management Server (SMS), a component of the BackOffice server suite, provides many of the features of large-scale network management systems at moderate cost. The primary advantage of SMS is that it's fully integrated with Windows NT Server 4.0 and is designed specifically for managing Windows clients, as well as providing automated installation of application software for client workstations. A dedicated SMS server usually serves a single domain. Installing SMS is the subject of Chapter 24, "Administering Clients with System Management Server."
All organizations have short-term tactical goals and long-term strategic objectives, all of which must be supported by the network if they're to be successful. As you plan and design your network and internetwork, keep constantly in mind that you're aiming at a moving target. Storage requirements increase as time passes. The total number of employees and workstations served by the network are likely to increase, as well as the number of sites to be connected. Newer technologies, such as client/server applications and document imaging, may be implemented in the future, placing increased demands on your servers and on network bandwidth. A properly planned and designed network must have the scalability needed to support future growth, both that of a predictable nature and that due to unforeseeable changes in the technology and the way your organization does business.
Begin planning for future growth by examining trends for the past few years. Have employee counts been increasing, decreasing, or remaining stable? Has the number of installed PCs increased, or are most newly purchased PCs simply replacing older models? Have all departments and sites been fully computerized, both in terms of hardware and applications, or is computerization an ongoing process? Have some functions of your organization been outsourced? If so, is this outsourcing likely to occur for other functions? Examine each such historical trend and discover whether a trend will likely continue or change over time.
Turn next to examining expected changes for the near future. What projects are in the planning stage that could affect network resource requirements? Perhaps your paper archives are due to be converted to magneto-optical storage. Your organization may plan to establish a major Web site on the Internet. A new branch office may be in the cards a year or so down the road.
After you consider all these issues and come up with your best guess for what your network will need to support a year, two years, or further in the future, design your network around components that will support its expected future size. Following are four keys to designing your network for future growth:
Spending 5 percent or 10 percent more than needed to provide a bare-bones network infrastructure pays off in the following ways:
The key to working within a budget is to plan exactly what to buy before you spend a cent. Buying networking products on a piecemeal basis is a great temptation but is almost always a mistake. When the project is approved and the budgeted funds are transferred to your account, there's often an impetus to show progress quickly. Vendors encourage this behavior by offering limited-duration specials and promotions. The inevitable result of falling into the trap of piecemeal purchasing is that you either overbuy on the early items and find yourself scrambling later on-perhaps settling for much less than you really need on the later items-or that you take a more conservative approach to spending early and later find that you spent less than you should have on the items purchased first. In either case, you haven't optimized the allocation of funding for the project.
The alternative to network-purchasing anarchy is to sit down at the start of the project to map out exactly what needs to be done and what items need to purchased to accomplish the task. The benefit to this approach is that it gives you the flexibility to prioritize needs and allocate funds accordingly before any money is committed. You may find that the budgeted amount is totally inadequate to do the job at even a minimum level. You may find that the budgeted funds are adequate to do the job, but that a small additional amount would allow you to do a much better job. If you're very fortunate, you may find that you can buy everything you need to do the job right and still have funds left over, which you may be able to apply to a guerrilla upgrade to an orphaned project. Whatever the result, this preliminary planning step puts you in a stronger position to go back to management and negotiate either the funding level or the scope of the project, before you find yourself committed. If you don't know the numbers, you can't present a convincing case.
After you establish this baseline budget, you can begin actually purchasing items, doing so first for the more expensive and more critical components. As purchase orders come back, you can compare your budgeted costs with the real costs, adjusting later purchases to take into account any overages or shortfalls in purchasing the earlier items. Buy less important and optional items late in the purchasing process to make sure that any compromises needed to meet budget are made on these less critical items.
A good way to go about the process is to create a master purchasing spreadsheet with one line item for each individual item to be purchased. If designed properly, this spreadsheet can be an invaluable tool not only for establishing the initial budget, but for tracking receipt of components as they arrive and flagging overdue items.
The following list provides a good starting point for the columns of a purchasing spreadsheet:
The columns in this spreadsheet will vary, depending on your purchasing policies and procedures. If you have the luxury of being able to do your own purchasing directly instead of working through a purchasing department, for example, many of the columns listed aren't needed.
In addition to this master budgeting spreadsheet, you're likely to find that it's useful to develop supporting spreadsheets for various purposes. Some line items on the master spreadsheet may require more detail than is appropriate, such as server configurations and options. Other related items, such as configuration planning by site or department, can have a separate spreadsheet, with summary totals linked to the master budgeting spreadsheet. This methodology keeps the master to a manageable level of detail.
One final item that's often overlooked in setting up a project budget is establishing a contingency reserve to cover unexpected requirements. If your budgeted amount seems likely to be adequate to complete the project, or if this is your first such project, 10 percent of the total budgeted amount is a reasonable contingency reserve. If the budgeted amount is stingier, or if you have considerable experience in doing similar projects, 5 percent may suffice. Guard this reserve jealously, releasing it only very late in the project. It's better to return unspent funds than to run out of money with purchases still to be made.
The importance of user training and its impact on your planning and budgeting vary widely, depending on your particular situation. If your networking project is simply an upgrade or a replacement of an existing network, and your users continue to use the same applications, training may have a negligible impact on planning and budgeting. If your network is a completely new installation intended to serve users who aren't currently computerized, you may have major planning and budgeting issues to consider, perhaps including a computer training classroom with equipment and instructors. If your network links users who previously used stand-alone PCs, at the very least you must make provision for training these users to use e-mail and other network-specific applications.
You must balance the need for user training against the funds, space, and other resources available, keeping in mind that users being trained can't to do their usual jobs simultaneously. If you decide to provide training, you must decide whether to conduct the training in-house, conduct it at a commercial training center, or pay an independent trainer to give classes at your site. Unless you live in a major metropolitan area or decide to train only on the most common Windows productivity applications, you're likely to find that there's no alternative but to train in-house, because no one offers classes on the software you're using. Many organizations compromise by providing a "train the trainer" program, where one or more chosen individuals from each department or location undergo training and then return to their groups where they, in turn, train the other users.
After the basic planning and budgeting issues are resolved, you must initiate and manage the installation of the network. The following sections describe how to use commercial project-management software to determine the schedule of the work and to allocate the resources required to complete the installation and startup of the network, including acquiring the services of vendors, value-added resellers, and independent network consultants.
In the course of planning, purchasing, and implementing your network, you accumulate vast amounts of information: scores of specific user requests, hundreds of to-do items, dozens or hundreds of individual items to be purchased, vendor lead times to be coordinated, and data communications line installation schedules. Throughout the course of the project, many changes occur. Item prices actually quoted may be higher or lower than you initially estimated. Key components may be backordered. Managers suddenly discover a desperate need for something they didn't bother to mention during your initial interviews, and upper management backs up the new requests. Winter storms result in delayed deliveries. All this information must be recorded, updated as changes occur, and kept organized if you're to have any hope of staying on schedule and within budget.
Installation of a PC network is, in fact, a construction project, and deserves to be treated as such. Project-management software, which is critical to construction projects, runs the gamut in features and functionality from Schedule+'s to-do lists to mid-range project management software, such as Microsoft Project. Figures 2.6 and 2.7 illustrate Gantt and PERT (Program Evaluation and Review Technique) charts, respectively, for NetWare to Windows NT network migration using a Microsoft Project template included in the Windows NT 3.51 Resource Kit. Simple to-do lists lack the capability to handle a project of this scale. High-end project-management applications, such as Primavera, are intended for people who manage multimillion-dollar construction projects for a living. High-end packages are very expensive, quite difficult to learn, and are overkill for this type of project.
2.6
A Gantt chart created by the Network Planning template for Microsoft Project.
2.7
A PERT chart created by the Network Planning template for Microsoft Project.
Buy Microsoft Project (or one of the competing mid-range project-management applications) and spend a half day or so learning the basics. You don't need to master every feature of the software to obtain useful results. After you learn to enter and edit tasks and resources, set milestones, track critical paths, and print Gantt charts, you have most of the tools you need to manage your resources and schedules successfully.
In most situations, the major resource you must manage is your own time and that of your staff. The availability of resources affects schedules, because completing any given task requires commitment of a certain period of time by a staff member with a particular skill. While that staff member is occupied with a particular task, he's unavailable to work on another task requiring similar skills. You'll likely find that one or two key people form a bottleneck, with more demand for their services than can be fulfilled. As a result, the time line stretches out, even though other resources may be standing idle. Following are three keys to maintaining a schedule from a resource point of view:
One of the many benefits of using project-management software is the reports it provides. These reports can tip you off early to potential budget overruns, resource conflicts, and deadlines unlikely to be met. These reports, in summary or consolidated form, are also useful for keeping management informed of progress, one often-overlooked aspect of successful project management. Giving management weekly or even daily updates-depending on the size and scope of the project-allows managers to become active participants in the project and accomplishes three things:
Few organizations have in-house all the skills needed to plan and implement a major networking project, particularly a project that involves internetworking. Even those organizations that do have such staff often find that other demands on staff time make it impractical to take on a major project while continuing to meet day-to-day obligations for existing networks. As a result, it's often necessary to look outside the organization for help in implementing such a project. Such outside help falls into two categories: manufacturers and value added resellers (VARs) of networking components, and consultants.
Vendors and VARs can be very useful sources of advice in configuring your network. Vendors and VARs are obviously intimately familiar with the capabilities of their equipment and have probably installed many similar networks for organizations much like your own.
Balanced against these advantages is the obvious conflict of interest. The vendor or VAR wants to sell specific brands of equipment, so more than likely that person won't recommend competing gear that may be a better or more cost-effective solution for your particular needs. Another negative factor is that the vendor or VAR focuses on just one part of the total picture, leaving you to worry about integrating the system as a whole. On balance, although vendors and VARs often provide a surprisingly high level of commitment to helping you plan and implement your network, you're usually better off to first select a vendor or VAR, and then later use whatever services are available from the vendor or VAR to help you implement your chosen design.
The second source of outside help is an independent consultant. True consultants bill you only for their time and expenses and, therefore, are an unbiased source of advice-at least in theory. In practice, many individuals and companies who represent themselves as consultants are, in fact, thinly disguised VARs who make some or most of their income from reselling hardware and software. A properly qualified independent consultant can help you with all aspects of your project, from the initial planning through the implementation phase.
Consultants have two drawbacks:
Choosing a consultant can be difficult. There are no state licensing boards for computer consultants; as a result, anyone can call himself a computer consultant, regardless of his qualifications (or lack thereof). To make matters worse, even a consultant who has done good work for you in the past or is highly recommended to you by your peers may not be qualified for your particular project. Even worse, the consultant may not be aware that he isn't qualified for your project and, thus, not disclose this fact.
When you speak to someone for whom the candidate consultant has done work, ask that person whether the project was completed successfully, on time, and under budget. Ask what problems have developed since that time and if the consultant was responsive to the problem. Focus not on personalities, but on results.
A more objective method of assessing a consultant's qualifications is to find what industry certifications he holds and what those certifications imply. Networking hardware and software vendors long ago realized that, in the absence of formal state licensing boards for consultants, it was up to them, the vendors, to provide some mechanism for assuring would-be clients that consultants had achieved at least some minimum level of competence with their products.
Microsoft has developed a certification program for Windows NT Server called the Microsoft Certified System Engineer, or MCSE. The youth of this program and the still relatively small market share of Windows NT Server, compared with Novell NetWare, means that relatively few people have completed the requirements for the MCSE. (As of early 1996, there were about 7,500 MCSEs in North America.) This situation likely will change, as many Novell Certified NetWare Engineers (CNEs) are adding MCSE certifications to their resumes. Unless the consultant you plan to hire is a specialist in a particular product area, such as data communications, make sure that the consultant you employ holds an MCSE certification.
Before you purchase the components to build your network, balance the resources you have available with your requirements. Unless you are in the enviable and unlikely position of being given an unlimited budget, you must make compromises in some areas to get what you need in other areas. It does little good to have the best server on the market if purchasing the server leaves you without enough money to buy network cards for your workstations. Chapter 5, "Purchasing Networking Hardware," is devoted to the hardware acquisition process, but advance planning is required to assure that you can complete the network installation without exceeding your budget.
Begin the purchase planning process by establishing a minimum acceptable configuration for each component. Don't compromise in terms of quality, but rather in terms of features and function. Stick to brand names, but work from the low end of the product line rather than the high end. Determine the minimum server configuration in terms of processor, disk storage, RAM, and other features that will do the job. Even if you would prefer to install 100Mbps 100BaseT network cards, instead determine the cost for 10Mbps 10BaseT cards for each workstation. Calculate the cost of installing a cabling system with only enough horizontal runs to meet your immediate needs. Plan on unmanaged hubs and other active components rather than the latest and greatest in managed equipment.
If you're lucky, you'll find at the end of this process that you have money left in your budget. If you're very lucky, it may be a significant amount. If you're already over budget, it's time to go to management and state that the job can't be done with the funds available. Don't make the mistake of trying to install a network with inadequate funding.
After you establish a baseline via the process described in the preceding section, carefully consider how the remaining funds, if any, can best be spent.
Server memory can always be upgraded easily later, but Category 3 wire in the wall remains Category 3 wire in the wall forever. If you have to choose between an expensive managed hub, an inexpensive dumb hub that isn't upgradable, or a moderately priced hub that's configured initially as dumb but later can be upgraded to managed, pick the moderately priced hub. You're likely to find the money to upgrade the moderately priced hub in the future, but if you buy the non-upgradable hub, you probably will be stuck with it into the next century.
Maximize the number of free adapter card slots, free drive bays, and memory sockets in the server. For example, if you choose to equip your server with 64M of RAM, specify two 32M SIMMs (single in-line memory modules) in preference to four 16M SIMMs. Later, you won't have to replace all your memory to upgrade the server because it has no free SIMM sockets. Although, in principle, your server may be better off having as many drive spindles running as possible, in practice you're better served by buying fewer larger disks in preference to more smaller ones, leaving drive bays available for future expansion. Substantial improvement in the reliability of large (4G and bigger) fixed-disk drives has occurred in the past two years.
Favor a few expensive items rather than many inexpensive ones. It's always easier to obtain subsequent approval for inexpensive upgrades to many small items than it is to acquire funding for a single expensive upgrade. Upgrading all your workstation NICs from 10Mbps to 100Mbps is a much harder sell than is a request to add another 32M of RAM or a few more gigabytes of disk space to the server.
Buy now what you may not be able to buy later. If expanding the memory on your server requires an expansion card, and that card doesn't come with the server, buy the card now. You may not be able to obtain the card when you're ready to add memory.
Similarly, pay close attention to the type of fixed-disk drives supported by your RAID controller. Many RAID controllers support only a few specific drive models. Some controllers require that all drives be identical. You don't want to find in a year or two that your only alternative is to replace all of your drives just because the drive you need is no longer available.
A good vendor is a godsend and can be very helpful in the initial planning process. A bad supplier can make your life miserable. Good vendors deliver what you ordered at the price they quoted, and do so on time. Bad vendors are usually a day late and a dollar short. Good vendors have the expertise and take the time to advise you on your purchases. Although you obviously must take into account suppliers' vested economic interest, their close relationship with manufacturers benefits you in terms of timely information and advice.
Unfortunately, good vendors are seldom the lowest bidder. Depending on your environment, you may be forced to buy only from low bidders, or you may have the luxury of choosing vendors based on factors other than simply lowest price. Do everything you can to select a good vendor and direct purchases his way. You'll find that the small additional cost is more than made up for by the services that the vendor provides, not only in terms of good advice, but also in delivery preference for items in short supply, generous interpretation of warranty terms, and/or provision of equipment on loan. Don't hesitate to use lower prices quoted by other vendors as a bargaining tool, but realize that good vendors incur additional costs to provide additional services and thus are entitled to a moderate price premium.
Decide first what you consider to be commodity items. This decision is determined by the level of in-house expertise and by where you choose to focus your efforts. All shrink-wrapped 3Com 3C509 Ethernet cards are the same, so you can safely treat this type of item as a commodity and simply shop for the best price. On the other hand, a Hewlett-Packard NetServer LM2 network server is not a commodity item. If you have a dozen other NetServers installed and have a network staff to configure them to your way of doing things, adding one more LM2 should be easy, and you can probably safely shop for the lowest price.
Otherwise, you can probably use, and should be willing to pay for, the advice a good vendor will give you. Don't make the mistake of trying to get the best of both worlds by soliciting extensive pre-purchase help from a knowledgeable vendor, and then turn around and price-shopping the configuration with others.
This chapter outlined the overall process of planning a network installation, with emphasis on establishing a new network or upgrading an existing PC network to Windows NT Server 4.0. Much of the content of this chapter is applicable to planning the installation of any network operating system and isn't specific to Windows NT Server 4.0. The intent of this chapter is to provide you with a planning framework before you delve into the details of Windows NT networking architecture. The remaining three chapters in Part I are devoted to Windows NT 4.0:
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.
