MS BackOffice Unleashed

• Overview of Server Planning
• Requirements Gathering
• Basic NT Requirements
• Budgeting
• Sizing—Metrics and Advice
• Considering All of the Options
• Preparing a Plan
• Expansion Planning
• Revisiting Your Plan
• Summary

— 9 —

Planning a Server

The preceding chapters have laid some groundwork of both the BackOffice family and the Windows NT environment. It's now time to get into the actual implementation of the BackOffice family of tools on your servers. What I am suggest in this chapter is that you spend a some time planning your server before you begin the implementation process. I have found that it usually saves time to do some planning up front.

Overview of Server Planning

Server planning is a process that is somewhat dependent on the preferences of the person who is doing the analysis and the standard methods employed in a given organization. For example, government agencies usually prefer formal written analysis documentation and recommendations that follow a standard outline format. In the business world, many companies prefer interactive briefing slides that enable you to present the concepts to management for approval. What I stress here is not the delivery format, but the tools and techniques that you should consider when conducting an analysis for your server.

In Figure 9.1, I summarized the basic process that I recommend as a baseline on to which you can add local preferences. It merges information gained during requirements gathering with technical requirements of the software components and budgeting to form the basis of an analysis. It also builds directly into the process the concepts of expansion planning. An important concept is that of revisiting the plan on a routine basis. With the current pace of changes in the computer industry, few plans are good for more than a year or so.

FIGURE 9.1. Basic requirements analysis process.

Some other processes and techniques that you might want to consider during your planning process include the following:

• Preliminary analyses to reserve funds. Sometimes the beginning of the entire planning process is a quick analysis that is used to justify funding requests. There are no detailed user requirements analyses, just a general mission statement and rough cost.
  
  
• Preparation and approval of engineering and program change documentation. In formal organizations and government contracts, you may have to go through quite a process to get your equipment ordered.
  
  
• Involvement from outside consultants. Some organizations listen to outsiders better than they do their own people. In these cases, it is sometimes important to get a consultant in to perform portions of the needs analysis or concur with your recommendations.
  
  
• Team formation and analysis. Some organizations form teams or committees to study everything and make recommendations. In these cases, you have to go through the process of forming the group, making assignments of tasks and then fusing together the various opinions into a unified recommendation.
  
  

There are a number of other options that could pop up. Although I could not think of or document all of them, I think that was I have listed previously is a good start. It gives you an idea of what is involved with the process and lets me get on to my next several topics that provide you with a few thoughts on the steps in the planning process.

Requirements Gathering

It's always risky to start out assuming that you understand everything that is needed with regard to a computer system. Perhaps you are in such close contact with your users and have already discussed the subject so many times that you already know their opinions. However, if you are not in a small group where you have a lot of direct communication with all your users, you might want to consider taking some time to gather your requirements. Some techniques that can be useful in this process include the following:

• Brain storming sessions. This usually takes the form of a meeting where you invite users and other players to come in and present ideas. The key concept of brain storming is that you do not criticize ideas or try to take each of the ideas to the detailed design stage. Instead, you just let people express their opinions and write them down for further analysis. It may seem like a somewhat chaotic technique, but some of the most interesting and amazing ideas come out when people start to loosen up and think freely.
  
  
• Guided analysis sessions. Many organizations have more formal processes used to rapidly build useful designs for system such as software applications. There are a number of terms for this process, such as joint application development (JAD). The key here is that there are trained facilitators who go through a formal, tested process to get information out of the key players and use that information to fuse a design that can be implemented. It may take some time to adapt your process to system designs, but it is something that you might want to at least consider.
  
  
• Open request for suggestions. Perhaps you do not have time for formal sessions. Perhaps your users are scattered so far across the building or even across the world that it is impractical for you to convene a meeting with them. One solution might be to use existing technology and send out either a memo or an electronic mail message asking them for their input on the requirements for the new server. It is not as personal as a meeting, but it least it gives them a chance for input.
  
  
• Group design sessions. Another technique that you might consider in the design process would be group design sessions. More limited than guided analysis sections and more focused on analysis and results that brain storming sessions, these meetings can bring together the key technical, managerial and even financial players to work though various alternatives to nail down the requirements for the system and maybe even work out the parts list for the order. It is a good technique when you have to get players in from a number of groups within the information systems community such as the network group, the operations group, etc.
  
  
• Iterative designs. The final technique that I want to throw out for your consideration is that of the iterative design. Some people want to sit down, and in one massive session of brain power, nail down all the details and produce a design that is absolutely perfect. Others have trouble getting anyone to provide you with input because they are just too busy or have a meeting or some other distraction. A technique that can be useful in these cases is to just make up a design with what input you have and send it out for people to review. You have to balance statements that you are looking for help and advice with statements that say that this design will become final and the system will be ordered if no comments are received by a certain date.
  
  

One feature of the requirements gathering process that I want to stress is that of making the users and other technical support groups feel as if they are part of the process and have input on the alternatives being discussed. People tend to be resistant to change. This feeling is heightened if they feel something is being shoved down their throats—something they didn't help plan. Motivational theory types talk about things such as feelings of ownership and having others buy in to a play. It could be a small representative sample of people from different groups. All I know is that I get a lot more help and fewer complaints from users when they have at least had representation in the planning process.

Basic NT Requirements

There are some requirements that you have to factor into the system planning process that users and even other technical support groups cannot help you with. Those requirements are levied from Microsoft and other vendors when they design their products. Here are a few tips on collecting these requirements and factoring them into your planning process:

• Web pages. Back in ancient times (which was actually just a few years ago), I prided myself on the collection of vendor literature that I maintained. I religiously gathered and filed the information that I gathered from conferences and vendor briefings. I send in a lot of vendor literature requests from magazines to get data on products that might be of use in the future. While I still keep some of this information, there is a much better source today. Most computer vendors (and even other companies) have build World Wide Web servers that contain a wealth of up-to-date product literature. The better sites go beyond salesman talk to provide detailed technical specifications, white papers on their technical architectures, and other such information. It has the benefits of being an on-demand system (you do not have to collect it until you need it) and also being much more current than a paper document (that you might have had for six months or so—an eternity in the computer world).
  
  
• Technical specification sheets. Many vendors put out sales literature that uses a lot of terms such as better, strong, and faster. They talk about how they can work with a wide variety of products in a wide variety of computer environments. While this may be interesting literature that contains impressive art work and color coordination, you cannot do any design work on a new NT server unless you have technical specifications. You have to look for the little detail such as how much memory is required when running the product in the NT operating system, exactly which versions of the operating system and supporting products will work with this product, and so on. With some vendors, you have to get down into some low level details to find things such as their product is certified to run under NT 3.51, but if you install NT 4.0 all bets are off.
  
  
• Hardware compatibility list. Microsoft does a lot of testing with products to ensure that they will work properly in the NT environment. Remember that for a device to work on NT, there has to be a compatible device driver for it. You could trust hardware salesmen who are trying to make a commission when they tell you that their printers work wonderfully with NT, but I tend to feel better when a third party comes in, performs a structured test, and then tells me whether or not the product is compatible. Microsoft does test products and certify which ones it considers compatible with Windows NT. They publish these results routinely. The best place to get hold of this information is on the Microsoft Web site (start at www.microsoft.com and follow the links to the Windows NT product and find the hardware compatibility list). The latest version is always up there and it is a reasonable length download. I cannot stress enough that you have to ensure a device is NT compatible. There are a number of PC hardware vendors who have targeted the DOS/Windows/Windows 95 market and have not bothered to write drivers for Windows NT.
  
  
• Check into all products. It is the little things that often get you in the technical planning process. I would recommend that you be as thorough as possible and check out every product that you plan on putting into the environment. If you have a magnificent system and all of the software that you need, but you have chosen a CD-ROM drive that is not supported by Windows NT, you will not even be able to load your operating system.
  
  
• Know which requirements are additive. When vendors list requirements, they often give numbers for amount of memory in the system and amount of disk space. You have to be careful to know which of these specifications are additive and which ones are just totals. For example, if you buy a database management system for NT, you will usually see a specification of, say, 24 Megabytes of RAM. This is a total requirement that covers the needs of the database and the operating system. It does not cover memory needs of say an electronic mail server such as Exchange Server. It's best to ask a lot of questions when reviewing this material in order to save yourself from running into problems later.
  
  
• Look for references and real-world configurations that are similar to the one you are proposing. When all is said and done, vendor literature can be confusing. It is almost always targeted to helping the vendor make a sale. One of the things that makes me feel better is when I can see a real-world system configuration that resembles the system that I am planning. If you can talk to its administrators and users to find out what they like and what they would change, you get the benefit of hands-on experience. On any complicated system design, you may want to try to get your vendor to provide you with a reference or show you one of their systems that is similar to the one on which you are working.
  
  
• Prototype a system whenever possible. One technique that can be useful if you have a few extra resources lying around is prototyping. Here you would get loaner hardware, software, or both from vendors and actually build a miniature version of the proposed system. You not only get the benefits of verifying that all of the annoying things such as version numbers and parameter files get worked out in advance, you also get experience on the installation process before you have to do it for real. I always feel better if I have had the time to build a prototype before placing a large order. Many vendors are very cooperative on this process, especially if you are placing a fairly large order or could be useful as a reference to them.
  
  

Budgeting

Now is the time to get serious. People can be easy going when it comes to talking about requirements. However, when it comes time to pay for it, they often start to ask the serious questions and look for hard answers. Because budgeting processes often involve management styles and organizational cultural issues, I cannot guess all of the hoops that you might be asked to jump through. What I can offer is a few suggestions that you might consider when preparing to go through this process:

• Prepare a list of alternatives and costs.
  
  
• Structure whole alternative solutions (for example, the high, medium and low cost alternatives).
  
  
• Link all purchases to customer/user requirements (it provides justifications up front and documentation in case the decisions are questioned later).
  
  
• Document the vendor selection process work that you have done.
  
  
• Give people rough estimates early on and then continue to refine those estimates.
  
  
• Always start out with conservative estimates and then start cutting costs.
  
  
• Always factor in some safety margin.
  
  
• Always factor in budget for growth.
  
  
• Do not forget to consider costs, such as training (user training, support staff training, conferences, and so forth) and outside consultants if you need them.
  
  
• Ensure that you have a budget for local staff time, even if it not charged directly.
  
  

Sizing—Metrics and Advice

When I discuss performance tuning in Chapter 12, "Windows NT Performance Tuning," you will see that one of the most difficult topics in performance tuning is knowing when a particular resource is overloaded. The same can be applied to your sizing analysis. How do you know the number of users that a particular computer can support when running Exchange Server and SMS? My solutions to this problem include the following:

• Prototyping can be quite useful to check performance on the actual architecture with which you are working. Remember to factor in some stress tests where you run a large number of jobs at the same to try and simulate a production environment. Also, you can find tools on the Web or supplied with vendor products that are used to simulate higher loads on their products.
  
  
• Check with any fellow system administrators who are running similar systems. Remember that they have to have a somewhat similar configuration to make their advice more meaningful.
  
  
• Post a question on an Internet newsgroup to see if they have some opinions on the subject. You have to look closely at the response to make sure that the sender knows what he or she is talking about, is working with a similar configuration, and is not a vendor trying to sell you something.
  
  
• Look at vendor literature for other client configurations. They will often include success stories from clients who have previously purchased their products. You can look at their configurations and compare their loads with your loads. Often you can even call the reference to get questions answered.
  
  

Considering All of the Options

One of the things that I cannot stress enough is that you should work hard to consider all of the options when planning a system. This not only includes purchased products, but options selected with the NT operating system itself such as which network protocols do you want to use. It is much easier to make these changes when everything is still on paper as opposed to you have a production server that needs to have some changes made. Some of the changes that you might want to make could involve serious amounts of work. For example, if you want to convert an NT server from a workgroup server to a domain controller (either primary or backup) you have to reinstall the operating system. You cannot just load some magical domain configuration file and reboot. Heck, it is hard enough to get time on production servers to perform even minor maintenance. Major upgrades like this are often almost impossible to schedule.

Preparing a Plan

Eventually the talk will subside and it will come time to actually prepare a plan. This plan takes a number of different forms from a set of notes that you make to yourself, a purchase order, a written plan document, or even a set of briefing slides for management. Whatever the form it takes, there are a few principles that I recommend you follow when you write the plan:

• Do not start with a list of what is to be purchased unless you anticipate absolutely no questions. It is usually best to start with business requirements to get agreement on what is to be accomplished. You can the move through the process that you used to prepare the design, alternatives that were considered, and then the final recommendation.
  
  
• Have backup slides or appendixes that provide alternatives if you anticipate that people will be asking for them.
  
  
• Have someone else who has both at least a rough user and technical understanding similar to your own review the plan before you publish or brief it.
  
  
• Use a format that your organization is used to. If you come up with a new presentation format, people may be concentrating on trying to figure out where the information is as opposed to listening to your ideas.
  
  
• Get to the point and avoid long discussions. You can lose people's attention. If you really want to put in detailed analyses, consider using appendixes or backup slides.
  
  
• Consider coordinating your presentation while it is still in draft form with key users, managers from the various groups being supported, or even other technical staff. It is much easier to make changes early on that when you are in the final design review.
  
  

Expansion Planning

I know of very few places where the computer processing requirements are stagnant. Technology marches on, prices continue to fall and users continue to want more. Many places double the power of their computer complex every couple of years. Some places experience almost meteoric growth and their computer staff is tasked to keep up with it. What I would argue here is that you should plan for growth as part of your basic plan for a system even if the users did not state it in their requirements to you. A few of my thoughts on the subject follow:

• As a rule of thumb, plan a system that can at least double in capacity for such things as disk storage, memory, and so on. The cost of having a few extra slots on the motherboard is small compared to the cost and labor involved with swapping out the entire box for a new one six months down the line.
  
  
• Consider purchasing computers that support multiple CPUs. Windows NT supports multiprocessor configurations. Although we have proven techniques to double disk storage and memory in a system, we usually wind up replacing the entire box when the processor capacity is exceeded. A system that can take a second processor chip is a good expansion alternative for NT.
  
  
• In the PC world, purchase computers that allow you to replace the CPU with the newer, faster models that will be coming out. The Zero Insertion Force (ZIF) socket is a standard that allows you to easily change computer chips.
  
  
• Always consider banking requirements when planning out memory configurations. Electronics engineers usually design memory slots such that they are arranged in pairs that must contain chips of similar size and speed. Therefore, you may not be able to build a 24M configuration from three 8M memory modules. You may have to use two 8M modules and two 4M modules, which may take up all your memory slots. If you wanted to upgrade to 32M, you would have to throw out (or give to another user) the two 4M modules and replace them with two 8M modules.
  
  
• Consider building test configurations that match those of your users in terms of hardware and software. You can use these workstations to ensure that the configurations will support the new hardware and software that you plan on deploying in your organization.
  
  

Revisiting Your Plan

Plans do not last forever. With all of the new technologies and industry directions that are changing almost every day, it is impossible to construct a plan that will endure. It is useful then to actually put as part of your plan a step to review it in the future on a routine basis to make sure it is keeping up with requirements and technologies. This may not be acceptable in some organizations. Some managers may rather foolishly conclude that you are just not capable of planning properly and that is why you want to change your plan on a routine basis. Others however will understand that this is a evolutionary process and appreciate this step.

Perhaps it is not possible to present plan revisions as "changes." So sell your plan as a short term implementation to get to a given state. In Chapter 13, "NT Integration with Netware and UNIX," you explore performance tuning and how this is a continuous process where you keep up with demand. Perhaps that will be a more acceptable means of presenting the reality that computer needs change very rapidly.

Summary

This chapter was not designed to cover all the things that might affect you when planning out an NT installation. There are so many factors that are unique to your organization, and only you could guess what they are. Also, it cannot be a single product checklist because these products are changing at a rapid pace and you need to make your analysis based on the current information. I recommend that you get Web access, because the Web is one of the most useful tools that I have come across to get current information about the computer industry.

This chapter presented some overall considerations based on my experience. Although my points may be obvious to some of you who have experienced planning out systems, I find that there are a lot of people who get thrust into the role of planning a system who have never done this task before. Few get formal training on this process in universities or on the job.