MS BackOffice Unleashed

• Design Integration Goals
• Implications for NT of Microsoft Mail
• Implications for NT of Exchange Server
• Implications for NT of SQL Server
• Implications for NT of Internet Information Server
• Implications for NT of Systems Management Server
• Implications for NT of SNA Server
• Working to Keep the Environment Integrated
• Summary

— 14 —

BackOffice and Windows NT

Now that you have learned several of the topics related to the Windows NT Server operating system, let's link this to the other BackOffice products. This chapter takes the operating system's point of view. Specifically, what are the other BackOffice servers demanding of the operating system and what problems are they causing? The remaining sections of this book cover the individual BackOffice servers and will take their point of view when they discuss what the NT operating system is providing to them.

Design Integration Goals

This is a good place to review the integration goals that are part of the BackOffice design. This will set the stage for the discussions on the impacts that the various BackOffice components have on the NT operating system and its servers. The following is my short list of NT design features and goals that are important in the context of this chapter:

• Built-in networking
  
  
• File and printer sharing
  
  
• Application server support
  
  
• Common security model
  
  
• Client server architecture
  
  
• Common administrative tools
  
  
• Common monitoring tools
  
  
• Cooperation between applications.
  
  

The first of these topics is the built-in networking. The Windows NT operating system provides networking utilities as a basic part of its functionality (see Figure 14.1). It is a rich networking environment that provides connectivity to a wide range of Microsoft and non-Microsoft computing environments. This permits a high degree of integration in a variety of computer environments that is standardized as part of the operating systems. Applications can take advantage of these networking services through standard interfaces without having to write their own networking interface code.

FIGURE 14.1. Built-in networking.

The second NT design feature that affects its applications is the built-in file and printer sharing services (see Figure 14.2). This goes beyond pure network communication and moves into the realm of higher-level networking services where you exchange information, not just communications signals. These standards allow applications to dispose print jobs to a standard location (a local print queue) and then have the operating system worry about how to get the actual printing accomplished. The file sharing standards provide a standard interface to determine all the files that are available to the user, both those on the network and on local storage devices. This frees the applications from worrying about the details of file systems, network transports, etc. The Universal Naming Convention (UNC) provides a standard means for referencing files in the format of \\server_name\share_name .

FIGURE 14.2. Built-in file and printer sharing services.

The third function provided by Windows NT that is used by applications that are designed for this environment is the ability to act as an efficient application server. Although many earlier PC server operating systems were designed almost entirely to perform the file and print server roles, Windows NT is actually an efficient place to run applications. For applications to run properly in the Windows NT environment, they must be designed for the Windows 32-bit application programming interface (API). In addition, there are a number of additional APIs that Microsoft has come out with to enhance this programming environment. Many of the BackOffice applications have their own APIs (MAPI, for example, that allows programs to send electronic mail to Exchange Server).

The next feature of BackOffice that is designed to be common is the security model. This model features a single login ID and password for use at both the operating system level and within applications. The operating system provides capabilities for applications to verify the security privileges assigned to a users. The key to this environment though is that applications use the basic security features of the operating system, providing extensions if needed, as opposed to implementing their own security systems.

A common set of administrative tools is another key element of the BackOffice environment. The basic tool set has been designed to be extended for individual application needs through a series of APIs. This alleviates the needs for each application to build its own administrative screens. It also guarantees that administrators only have to learn one way of doing business, that can save them a lot of time.

The common set of performance monitoring tools is another hallmark of the Windows NT and BackOffice environments. The Performance Monitor tool provides a very flexible and graphical means of viewing performance data from both the operating system and the application levels. All your applications have to be designed to do is track and report counters that are applicable to their internal processing to the Performance Monitor interface. You no longer have to worry about designing the graphs or reports because that is provided by Performance Monitor.

A final design feature that marks the BackOffice family is that each member has the capability to work with one another. This goes against many designers first instincts in that they could, for example, write a database management system that is more optimized to their particular needs. What this would mean though is that there would be additional database administrative work and that administrators would have to learn a new set of tools and have a separate entity to maintain. It also means that a lot of the programming resources would be devoted to rebuilding these common functions as opposed to focusing on the main functions of the application on that they are working. BackOffice has taken the position of using other components in the BackOffice architecture when it makes sense.

The integration of components to work together should continue in the future. Many of the new BackOffice server such as the Merchant Server will probably be dependent on both the Internet Information Server and SQL Server products. With the ISAPI interface, databases and IIS will continue to be more tightly integrated as Web sites add dynamic, database-driven content to their current static Web pages. There are a number of complex applications that are coming down the road and they will need the services of the existing foundation components.

With these design goals in mind, let's move on to how the various BackOffice components affect the Windows NT Server operating system. It is important for system administrators to understand these impacts to ensure that they have adequate resources to cover their needs. It also helps during performance monitoring and tuning to enable you to better understand the numbers that you see. Systems are really sensitive beasts. You can have a large amount of resources in your system- memory, CPU, disk drives. However, if you have just one component that is overloaded (for example, one of your many disk drives seems to receive almost all the data requests and cannot keep up with demand), system performance and user response time can degrade rapidly.

Implications for NT of Microsoft Mail

Microsoft Mail is the grandfather of the BackOffice family. This product evolved in the era where file and print sharing was about all you got from your servers. Therefore, it is not a sophisticated client server application that takes advantage of the advanced capabilities of the Windows NT platform as an application server. Instead, it merely uses the server as a place to store files that the users will need to access to exchange electronic mail.

Figure 14.3 is a graph for the Microsoft Mail product, showing the resource implications of the BackOffice products on the NT server. The various major server performance and processing components are shaded to show the relative demands of the various BackOffice components. Nonshaded areas show little or no load, and the two shades of gray show increasing loads.

FIGURE 14.3. Effect of Microsoft Mail on a server.

The typical Microsoft Mail installation has the following effect on a server:

• Disk storage capacity. The major impact of a larger mail installation is the disk usage for the message and perhaps schedule files that are stored on the server. One way to minimize this effect on the server is to have your users keep their personal folders on their local disk drive (an option under their MS Mail client). You also need to keep after people to read their mail frequently and delete mail that they do not need any longer. There are some people who would record their entire corporate history using saved copies of their electronic mail messages.
  
  
• Disk input/output capacity. Another factor that you have to deal with in Microsoft Mail is that all the data is stored on a single disk drive. That means that all the data transfer traffic is focused on that drive and you could overload the capacity of the drive. Solutions to this problem on busy mail servers include choosing a drive that has little activity other than the mail system and ensuring that you have one of your faster drives allocated to this purpose.
  
  
• CPU processing capacity. Microsoft Mail is a relatively insignificant load on the CPU. Again, it is designed for the relatively simple file sharing environment that was used several years ago and not the more demanding application server environment of today.
  
  
• Memory utilization. Again, because Microsoft Mail is based around simple file sharing, it uses very little system memory (one of the few products that you can find these days that can honestly make that claim).
  
  
• Network input/output capacity. Depending on the volume and size of the mail messages, Microsoft Mail can cause a reasonable amount of network loading. This is especially true if there are a large number of public folders that have large group documents in them for review. Otherwise though, its network load is usually quite moderate.
  
  

One of the features of mail system utilization that you commonly see is that it is subject to very strong peaks during the business day. The typical game plan is that everyone checks their e-mail first thing in the morning, just after lunch, and just before they go home. Surrounding these peaks are periods of relative calm. It does mean that you will have to design your server to provide adequate response times during the peak periods as opposed to using just a daily average loading in your design calculations.

Implications for NT of Exchange Server

The son of Microsoft Mail and the product that Microsoft plans to use in future versions of BackOffice is Exchange Server. It is a radically different design concept than that used in Microsoft Mail. It is designed specifically to take advantage of the application server capabilities of Windows NT in a client server environment. Actually, it strongly resembles a client server database management system in a number of ways (transaction logs, background processes servicing memory areas, and so forth). This was no accident. There were a number of design goals that required this type of architecture including:

• Capability of scaling up to support larger numbers of users on a single server
  
  
• Mechanisms to ensure that electronic mail transactions are recorded and can be recovered in the event of a disk or system failure
  
  
• Capability of supporting backups while the system is available for user processing
  
  
• Capability of being extended to support groupware (applications that facilitate communications among a group of users who are working in a common area)
  
  
• Capability of being extended to support forms-based applications that interface with electronic mail
  
  
• Capability of interfacing to a wide variety of external mail systems created by other vendors
  
  

Based on this different architecture compared with Microsoft Mail, you expect a somewhat different set of effects on your server. Figure 14.4 illustrates the effects of Exchange Server on Windows NT, which are as follows:

• Disk storage capacity. Disk storage can vary from moderate to heavy depending on the number and size of messages transmitted. As more people become comfortable with attaching documents and other materials to messages, the size of the average message will grow substantially. Because Exchange Server uses logging and some other transaction recording mechanisms for reliability and speed, there will be a moderate increase in the amount of disk storage needed when compared with Microsoft Mail. This can be offset by enforcing policies that users keep their personal folders on their local hard disk drives.
  
  
• Disk input/output capacity. This can vary from moderate to heavy, again depending on the number and size of messages transmitted. You may get a much heavier traffic volume if you set up your system to interface with Internet mail systems or implement the Newsgroup server technology in the next release of Exchange Server. The good news is that Exchange Server has automatic utilities that are designed to analyze your system configuration and determine the best locations for the Exchange Server files.
  
  
• CPU processing capacity. There will typically be a moderate load on the CPU by Exchange Server. The fact that there are multiple threads running in the background to service requests from the user and store data on the disk drives makes this much more of a load than Microsoft Mail while relied basically on file sharing. If you implement groupware applications, this load may tend to increase.
  
  
• Memory utilization. Exchange server puts a moderate load on memory as it runs. Memory equates to speed, so servers typically will use as much memory as is reasonable for a given server.
  
  
• Network input/output capacity. This will again vary according to the amount and size of traffic from this server. If you link to external mail systems, you may double the load for transmissions that are first received by Exchange Server and then are transmitted to the users.
  
  

FIGURE 14.4. Effect of Exchange Server on a server.

I want to leave you with a few final comments on the effects of Exchange Server on your system. First, much as in my discussion of Microsoft Mail, Exchange Server is often subject to high peak usage periods. Typical examples of these peak periods are first thing in the morning, after lunch and just before everyone goes home. This can be somewhat minimized if you have client workstations that have enough memory to enable you to run the Exchange clients minimized on the user's desktops at all times. People can easily send mail when they think up an idea and their recipients get the mail soon thereafter as opposed to whenever they next log in to the mail system.

Another subject that will soon come to the forefront is the Internet newsgroup server technology that will be a part of Exchange Server in the fall of 1996 or so. If you choose to allow your users to access Internet newsgroups from your server, you will have to pay special attention to system loading. First, there are an enormous number of newsgroups that are out there. Many of these newsgroups receive hundreds of messages per day. There are also newsgroups that contain large binary files (most often images, many of which you may not want to display in a professional office environment) that take up huge amounts of disk space. You have to select the newsgroups that you carry carefully to ensure that the load on your system is reasonable. This includes considering the transfer capacity of your network card (remember, many PC network cards are designed to be cost competitive and are therefore do not always have high transfer rates). It also includes considering how many files and how long you store these files. One feature that I have seen a number of Internet service providers have trouble keeping up with is the newsgroups (even on DEC Alpha servers)—just a word of caution to keep a close eye on things for a while as users try this new service and see how useful it can be.

In summary, Exchange Server is a very useful tool that can have a serious performance impact on your server computer. This comes from a combination of factors. First, it addresses one of the primary needs of users—to communicate ideas with each other. It adds to this the ability to attach a wide variety of documents and files, which means it serves as an effective transfer mechanism using an interface with which the users are already familiar (sending electronic mail). Finally, it does this all in a rather friendly manner for the users. This ease of use and powerful functionality means that users will use it. This is good, but also means that the server administrator has to keep an eye on disk space utilization, network transfer needs and server processing capabilities.

Implications for NT of SQL Server

SQL Server is the next member of the BackOffice family to consider here. Similar to Exchange Server, it is a true server application as opposed to merely being a database that allows users to share data files that are stored on a shared network directory (dBase or Microsoft Access files, for example). As with Exchange Server, SQL Server has extended the processing capabilities of early PC databases to provide the power and functionality of database management systems that have been developed for larger computer systems ranging from mainframes to UNIX servers. Along with this additional power comes additional loading for the server and that is what this section is all about.

The following are the additional functions that distinguish SQL Server from the smaller PC-based databases that many of you are familiar with. With SQL Server, you can do the following:

• Handle large numbers of users
  
  
• Coordinate data changes from multiple users
  
  
• Provide good performance and response times in a client server environment
  
  
• Integrate with the Windows NT operating system and its security features
  
  
• Provide flexibility in its configuration for differing hardware environments
  
  
• Provide strong recovery and security features for mission-critical databases
  
  
• Have the capability to distribute the processing load between the client and the server (for example, the capability to execute data processing routines on the server in the form of stored procedures)
  
  

To accomplish these additional tasks, SQL Server has a number of design features that are different from common PC-based applications. The following are some of the more important design consideration:

• SQL Server makes heavy use of shared memory areas to buffer transactions and data for rapid access by the users.
  
  
• SQL Server uses a number of background threads to service the memory areas in the form of writes to the data files and other clean up functions.
  
  
• SQL Server is tightly coupled with Windows NT networking to allow remote users to rapidly access the SQL Server data by using the installed networking protocols.
  
  
• SQL Server implements log files and temporary storage constructs that increase the amount of data storage and traffic, but provide that increased scalability and reliability.
  
  
• SQL Server provides the ability to store software in the database in the form of stored procedures. These procedures can be called by clients and are executed on the server. This can reduce network traffic (that is, the data does not have to be transmitted to the client, processed and then have the results transmitted back to the server). However, it increases the processing load on the server.
  
  

Based on this design, the effects on your server of this database management system are shown in Figure 14.5.

• Disk storage capacity. Database management systems can be the heaviest user of disk storage space on a server computer. Of course, the exact nature of the database will determine the storage space required. For example, a small accounting database will take up much less space than a large corporate data warehouse. SQL Server does implement some duplicative data storage mechanisms such as log files, but these are routinely cleaned out on a well-maintained system.
  
  
• Disk input/output capacity. Depending on the nature of your transactions and queries, you input/output systems can be strained. For example, if you have a query that requires most of the database be read to calculate a series of number, you will have to transfer most of the contents of that database from disk into memory. Query-intensive databases are good candidates for high-performance input/output systems such as those provided with fast/wide SCSI busses. Other databases, such as those designed to capture online transactions, may require only a small set of data be read or written per minute. These are good issues to explore when you are planning to put up a server designed to support a SQL Server database.
  
  
• CPU processing capacity. Once again, this depends on the nature of your database. If you have a large number of stored procedures, you will probably place a fair amount of strain on your CPU. If you perform a lot of calculations in the database (for example, you calculate sums of a series of purchase prices and return only the summation to the client workstation), then you will also experience a significant amount of CPU processing load. However, if all you do is enter data in and get it out in the exact format that it was put in, you will probably have a more moderate CPU utilization. Remember though that there are a number of background processes keeping the database management system running that will be adding to the CPU load in addition to those of your user interaction processes.
  
  
• Memory utilization. Database management systems thrive on memory. A programmer can access data that is in memory in a small fraction of the time that it takes to access data stored on a disk drive. Because one of the key criteria in selecting a database management system is speed and therefore processing volume, database management system designers have spent quite a bit of time working on ways to increase performance and this usually involves memory in one way or another. Bigger databases consume more memory, but they all consume much greater sections of memory than those of you who are used to simple file servers or PC-based applications will be used to. Expect the memory requirements for even moderate databases to be in the ten megabyte region (in addition to the space consumed by the operating system). I have seen databases consuming hundreds of megabytes of memory on servers with large transactions that support large numbers of users.
  
  
• Network input/output capacity. SQL Server is a client-server database management system. This means that very few users actually use the server console to run applications. Instead, everyone is using the network to communicate with the database. Depending on the nature of the transaction (do you want just a single summary number or do you really want to pull down thousands of complete records from the server to your workstation), the network loads can vary from moderate to quite heavy. Again, you should work to understand the nature of the data transfers when you are planning out your server so that you can ensure that you have adequate network transfer capacity.
  
  

FIGURE 14.5. Effect of SQL Server on a Server.

I can't leave this section without giving you a few parting remarks. The first is that you really need to take tuning to heart on SQL Server installations. Even if you are not overloading your system in large scale terms (for example, your CPU is at 100 percent capacity all day long), you can often do a lot to reduce user response times which helps them with their productivity. It can often be as simple as spreading out the various database files across several disk drives to balance the load more evenly.

The next item that you need to keep an eye on during the design process is the use of stored procedures. These can be wonderful tools to increase application performance. It is a time-consuming process to take the data from the server's disk drives, transfer it over the network and then process it on the remote workstation. It is much easier if you can eliminate a lot of the network traffic. Also, you have much greater control over software that is stored in a central, secure location compared with software that is distributed to every workstation in your organization. However, in most cases, there is more processing capacity and memory in the many user workstations than there is on the relatively few servers. If you are going to be asked to support a lot of stored procedures, make sure that you are given adequate processing capacity.

Another feature of most database systems is that you can have wide variances in the processing load. Often there are massive update jobs that can take up the entire processing capacity of the system. Some downloads may require that user are not permitted to access the system during the course of the download for consistency purposes. Finally, you have to be really careful about the queries that users issue. I have seen poorly formed queries that had to be terminated after an hour of processing that could be tuned to take less than 30 seconds. If you have developers writing new reports or users forming their own queries in ad-hoc reports, make sure that they are at least moderately qualified in the Structured Query Language (or are only using a controlled set of tables and views which are efficient). If they issue a demanding query, it can severely degrade performance for all the users for quite some time.

Finally, you will probably need to get into a real capacity planning mindset when you work with databases. I can think of only a handful of databases that I have run across that do not grow rapidly. When you first install the system, it may get a moderate amount of use. People are not familiar with the system capabilities and use it only when they have to. Soon however, if your application design is good, people will find new ways to use the system to look up information. Your usage will start to grow in both amount of processing and amount of information stored. Therefore, you need to keep an eye on usage trends (data storage, temporary storage, and so forth) over time so that you can identify when additional capacity is needed long before your system becomes overloaded. You may also want to ensure that your backup subsystem is up to storing this additional information according to your backup schedule.

Implications for NT of Internet Information Server

The Internet Information Server is a relatively new application in the BackOffice family. It started out as a downloadable add-on to NT 3.51 in the spring of 1996. It became a built-in feature with the release of Windows NT Server 4.0. It also represents the first real gateway for NT computers to the enormous world of computer users that is out there. Oh yes, Microsoft has been working for years to increase SQL Server's abilities to handle large numbers of users (hundreds). The domain architecture is designed to enable you to use a single security architecture for access to resources even if you have many thousands of users scattered across the world on your wide area network. These examples are small change compared with the millions of users who are out there on the Internet.

You may only want to use Internet Information Server for your local area network or perhaps your corporate network. That is OK. Internet Information Server will meet your needs and get the job done. From a performance standpoint, it will probably resemble a file server in terms of loading unless you implement a number of the ActiveServer components to shift processing load to your server. Remember, static HTML pages are really just another form of document. True, if you want to have a "good looking" Web page, you will probably include more graphics and art work than you would typically include in a business memorandum done on your word processor.

If you are a site on the Internet, however, your load can go straight through the roof. There are a number of search engines on the Internet that you can register with or one of your users can register you by themselves. Once you start appearing in these searches, any number of people can log into your site and start downloading your information. Perhaps, as in the case of a marketing-based Web page, this is good news for your company. However, it can be a significant problem for the system administrator. When you were designing the system, everyone told you that there would be some moderate usage level. Now that the equipment is in place, everyone wants to access your page. Therefore, you have to carefully consider the effect of number of users on your server and have some contingencies (for example, the capability to add another processor, upgrade the disk drives or network cards).

Although it is difficult to state the effects of Internet Information Server on its host computer given the wide variation in number of users and content, I decided to give you my best estimate in Figure 14.6. These effects break down as follows:

• Disk storage capacity. This is driven strictly by the content of your Web. If you have a large number of pages, or especially if you have a large number of graphics, you can consume quite a bit of disk space.
  
  
• Disk input/output capacity. This is driven by a combination of your content (simple pages or complex pieces of art, for example) and the number of visitors that you are servicing. Although this is typically not a big consideration except in the larger Web servers, you should at least consider its impact. You may, for example, want to place the Web and ftp pages on a drive that has little other activity. Try to avoid drives that support busy databases or other such tasks.
  
  
• CPU processing capacity. Processing Web and FTP queries is relatively simple for a computer. However, the latest extension and rage in the Internet world is active Web pages. Typically this involves executing applications (such as those written in the JAVA programming language) or running animations and other active controls. Although these are typically executed on the client, Microsoft has built a number of constructs into its server that enables you to run the applications on the server. Such things as security checks and certain application processing needs to be tightly controlled and this is much easier to do on the server. Therefore, if your developers are building a lot of Web applications that do things such as interface with your server databases or perform a lot of server-based processing, you will need to keep and eye on CPU utilization.
  
  
• Memory utilization. Typical Web and FTP servers are not really intense on the memory capabilities of a server. This, of course, grows as you add server-based Web applications or provide interfaces to databases located on your server.
  
  
• Network input/output capacity. This can be one of the more severe limitations for many servers asked to perform Internet services. Many PC network cards are not designed to meet the very high performance standards that an Internet connection may demand. This is especially true if you become a popular server. Microsoft, for example, had over 30,000 people download its new Internet Explorer 3.0 product during the first six hours that it was available. What makes that even more impressive is the fact that the file took almost an hour for most people with normal modems to download and that the product was not made available until midnight in the Pacific time zone of the United States (three in the morning, that is, for those of us in the east). Even Microsoft had difficulty handling this volume with multiple download servers scattered throughout several locations. Perhaps you will not achieve this level of popularity, but it does show that you can run into some severe peaks in usage, especially if you have great content.
  
  

FIGURE 14.6. Effect of Internet Information Server on a server.

Another effect that you should consider when implementing an Internet/intranet server is the security effect. Although it is true that Web server can only access files in a given directory tree (unless you build server-side Web applications that do otherwise), the access is pretty much there for all. You have to go out of your way to implement some form of security and this is really a relatively new discipline. Therefore, you should carefully consider your content before you make it available on a Web server, especially one that is accessible from the Internet (where all your competitors are located).

Another point to consider is that your usage patterns for an Internet-based server are controlled by the outside world and not your organization's normal work hours. If you have a site that appeals to regular consumers, much of your activity may occur during the evening hours when people are home to surf the Web. In other cases, you may even be subject to traffic at all hours of the day (that is, your site becomes popular around the world). This can have effects on other system activities such as shutting databases down in the middle of the night for backup. Night in your time zone is the middle of the business day somewhere in the world.

A good impact issue to address here is how do you handle the situation where your server faces overloading from the millions of people on the Internet who are anxious to see what you have got? You could just unplug the Internet connection when you see the server load going through the ceiling. However, that would form a bad impression. You could just stop the Web server service, but again that would lead to a bad impression. One of the easiest to deal with techniques that I have run across on the Web is swapping the pages around to control load. Remember a Web page is nothing more than an ASCII file written in HTML format. If the Web page has a hot spot that lets you download a file, then the user can perform that action. However, if the page does not contain these high load features, then the users will not be able to put as much of a load on the system. You could design a multimillion-dollar system that swaps in less demanding Web pages in place of those that are overloading your system. Of course, you could also just type up a quick batch file that uses the DOS copy command to move files from a staging directory of content to the actual Web server directory. I am not much for elegance, so I tend to choose the old batch file route. You can even put a message on these less capable pages as to when the download services will be available.

Finally, a Web/FTP server can become quite a maintenance task. As you will learn in the next section, it is blissfully simple to set up the Internet Information Server product. A child can do it with ease. However, that is just the beginning of the maintenance process. Web pages are getting to be a form of art. They are a combination of text, graphics, software programs, and other active components that are used to make an impression on your visitors. As such, people from the CEO on down will have opinions as to the message that you are trying to get across with your Web site. These opinions turn into a lot of work—updating the pages and building active controls and miniature applications. Perhaps this is the responsibility of someone else. If it is not, it could turn into quite a task. Major vendors in the computer industry such as Microsoft and Oracle redesign the look, feel and content of their Web pages every couple of days. They even do major look-and-feel changes every couple of months. Make sure you clarify who is going to do this work before you get involved with having a Web server on your computer.

Implications for NT of Systems Management Server

Another newcomer to the BackOffice family is the Systems Management Server. This is a powerful tool for managing that vast sea of computers that are sitting on your user's desks. It can also help keep all your servers up to date and functioning at maximum efficiency. As with every wonderful thing that computers can do, there is also an effect on the computers themselves.

To quickly review, here are some of the major functions of the Systems Management Server:

• Automated client computer hardware and software inventory collection and storage
  
  
• Automated client computer software installation
  
  
• General help desk support functions
  
  

The help desk support functions are important and interesting, but usually have little effect on the server. The other two functions, on the other hand, can have a substantial impact on your server as shown in Figure 14.7. These effects include the following:

• Disk storage capacity. The impact of Systems Management Server on your disk storage capacity can vary from a little to a lot, depending on how you are using the system. If you are just keeping an inventory of the equipment on your network, the impact on disk storage is not too high. If you are performing automated software installations and you are one of the many shops that supports almost every computer software package known to mankind, then you may have to allocate a bit more storage for the applications that you will be distributing.
  
  
• Disk input/output capacity. If you are performing a mass upgrade of a number of computer systems out on your network, the disk input/output capacity of your system could be a significant factor. In these cases, it would be wise to invest in a higher transfer capacity disk storage system (fast/wide SCSI, for example) to improve your transfer capabilities.
  
  
• CPU processing capacity. The scripts associated with Systems Management Server will require some processing, but this is not typically the most significant impact of this system.
  
  
• Memory utilization. This is similar to the CPU processing capacity in that it is not typically the most significant impact of Systems Management Server. However, because you will also have a SQL Server database running to support many Systems Management Server functions, you could have significant memory utilization from the SQL Server services.
  
  
• Network input/output capacity. This can be a significant impact of Systems Management Server, especially if you are using it to distribute large updates to a number of client computers. Again, if you see this as a significant function of your server, you may want to invest in a higher-capacity network interface card to prevent this from becoming a bottleneck in your software distribution process. You may also want to consider linking your servers with a higher capacity network (such as a 100Mbps Ethernet backbone) to improve transmission capabilities.
  
  

FIGURE 14.7. Effect of Systems Management Server on a server.

One of the interesting design features built into Systems Management Server is the capability of distributing software in a hierarchical fashion as shown in Figure 14.8. This scheme is especially useful in limiting network transmissions in a network that includes some form of routing (for example, there are network devices that transmit signals from one side to the other if the signals are intended for a computer on the other side thereby eliminating unnecessary signals from your network segment). In this scheme, your master server sends out the changes and orders to a number of other servers. These servers then send the upgrades to their clients. You could implement a number of such tiers to control upgrades for a large organization.

FIGURE 14.8. Hierarchical software distribution scheme.

One of the keys to controlling the effect of Systems Management Server on your systems is scheduling. These transfers can be large and may tie up the client computers while they are receiving their upgrades. A large upgrade can cause a large amount of network traffic that can interfere with other processing activities. It is usually best to schedule upgrades to occur automatically during off hours (at night, for example). This will require you to train your people to leave their PCs powered on and logged off at night. It may also mean a few headaches for you in that you will probably want to check how things are going during the time that you would normally be sleeping or surfing the Internet.

A final effect that is positive that Systems Management Server provides for your network is license security. Many companies are worried about violating software licensing agreements. There are so many computers out there and many have replaced previous computers that had software licenses that you think were transferred to the new machine. There probably have also been a number of upgrades to previous licenses, etc. Systems Management Server provides a central database to help keep track of the licenses. The best feature is the one that lets you audit your network to see what is actually in use. This task would take up quite a bit of time if you had to send someone out to find every computer on your network and look at the applications.

Implications for NT of SNA Server

The SNA Server is not designed to perform a lot of local area network processing. Instead, it is designed to act as a gateway from the local area network to the IBM mainframe and AS/400 world. Mainframe types might be comfortable with this type of connection. They feel comfortable with terms such as channel attached and the like. Those from the PC world might find some of these terms to be a bit alien. There should also be a healthy amount of concern when you attach your server to a computer that is as big as most mainframes. Mainframes are designed to process huge volumes of information and spit the data out in the form of enormous reports and data files. The client server world is designed to have the user ask a specific question and receive a response on an as-needed basis. Most networks were not designed to handle large batch jobs that produce thousand page printouts (in which a user might look up a few numbers of interest). If not controlled properly, users could saturate your server and network with jobs that were never intended for the local area network environment.

Here are the potential effects of SNA Server (see Figure 14.9):

• Disk storage capacity. There is nothing about SNA Server itself that places any significant disk loads on your NT Server. However, many mainframe users are used to running big batch jobs that produce big flat files with data in them. They tend to like to leave these jobs out on the network so that they can be quickly accessed when needed. If they choose to transfer these data files down to a shared drive on your server, it could start to take up a lot of disk space in a hurry.
  
  
• Disk input/output capacity. Typically, SNA server is not disk intensive unless your users transfer a lot of data between the mainframe and your server.
  
  
• CPU processing capacity. This is typically relatively moderate for computers running SNA server. There is some translation and routing work to be done, but the majority of the work is done on the mainframe (such as running batch jobs) and the workstations (providing the user interface).
  
  
• Memory utilization. This is also relatively moderate for computers running SNA Server.
  
  
• Network input/output capacity. This is an area where you could run into problems depending on how your users plan to use their SNA Server connection. Although the typical mainframe terminal has a very low speed connection to the mainframe itself, there are a large number of them. Also, data files on the mainframe can get quite large and this can be a large network burden if your users need to send and receive a lot of files with the mainframe. This data also tends to come all at one time, typically at the end of a batch job.
  
  

FIGURE 14.9. Effect of SNA Server on a server.

One of the most important variables in the load placed on your NT server by SNA Server is the type of connection used to communicate with the IBM mainframe or AS/400. There are a number of means of hooking into the mainframe that vary from extremely high speeds (right into the main communications bus, for example) to relatively slow speeds (that are used for common mainframe terminals, for example). The data transfer needs of your users need to be coordinated with the mainframe systems staff to ensure that you have an adequate transfer capability based on the number of users and the size of the data transfers. This will affect your choice of interface technologies in your server. These options are discussed in more detail in the SNA Server section.

Working to Keep the Environment Integrated

One of the most impressive features of BackOffice is the tight integration between the products. They are good at using the standard security and administrative features provided by the Windows NT operating system. This integration (see Figure 14.10) reduces the administrative burdens, improves security, and reduces the number of interfaces that you have to learn. You have the opportunity to mess things up and slip back into old habits, however, so let's look at how you can keep the Windows NT and BackOffice environment working together.

FIGURE 14.10. Integrated BackOffice environment.

The first challenge to your integrated environment will often come from your local application developers. They have grown up using operating systems that had little or no security. What security and administrative features the operating system did provide were not accessible to developers. Therefore, most developers are used to developing their own security systems and administrative systems for every application. Although this may work, they typically do not have enough control over the functions of the operating system to have a fully bullet proof security system. It also means that you have to go through a number of additional administrative steps (such as creating user IDs and passwords for the operating system and the database management system).

There is no easy way to enforce this. Your developers and management may feel it necessary to use a commercial product that cannot interface with the NT security and administrative system. However, if you do have a choice, always recommend a product that can interface with the operating system utilities. You should lobby with local application developers to use the operating system tools rather than build their own.

The registry is a specific operating system feature that you should use for locally developed applications. This is a centralized repository where all the initialization data is stored. Earlier versions of the Windows operating system used a number of ini files to store this information. They were scattered all over the hard disk (some in the applications directory, others in the Windows directory). The registry enables you to store the data in a system "database" of information that has values both for individual users and the system as a whole. This is much easier to troubleshoot and maintain than the scattered collection of files so at least try to lobby for its use with your developers.

A final subject to consider is keeping up with all the new tools and features that come out for Windows NT. There are some environments where the vendors tell you not to apply a patch unless you absolutely need it (if your system has crashed, for example). One common flavor of UNIX had hundreds of patches out there including almost one major patch to the operating system kernel itself on an almost weekly basis. In this environment, you never were sure where you stood or whether you could run a new product on your system.

Windows NT and BackOffice are somewhat different. It is a good idea in this case to keep up with the service packs and upgrades to these products. Because these products are so tightly coupled with one another, you may often find that you need to have the latest service pack for the operating system installed in order to load a new version of a BackOffice component. A nice feature of the service packs is that a later service pack includes all the changes of the earlier service pack plus the new changes. This makes it easy to keep up to date. Best of all, most of these upgrades can be found on the Microsoft Web page making it very easy to keep up to date (you no longer have the excuse that the vendor never sent you the upgrade disks).

Summary

This chapter has covered a lot of ground. My goal was to cover how the various components of BackOffice affected the Windows NT operating system and computer systems on which they are running. These interactions often depend on the exact uses to which you are putting the components in your particular environment. You have to be careful, therefore, when planning out a new server to ensure that you have adequate capacity.

The effects of the BackOffice components on your server can be generalized as follows:

• Microsoft Mail tends to be a relatively light load on the server for a given number of users. Designed for file server environments, its major impact is on the disk storage and network transmission systems.
  
  
• Exchange Server is a more complicated environment in that it is a true server application. It benefits from its use of server memory and processing capabilities. It also uses additional disk storage to record log files to increase reliability. It could be an extremely heavy disk storage space user if you implement the newsgroup server technologies that are being integrated into this product.
  
  
• SQL Server is another true server application that provides the full spectrum of relational database management system services to your environment. As such, it can be a heavy user of disk storage, disk data transfer, CPU and even network transmission capabilities on your server.
  
  
• Internet Information Server typically affects the network transmission and disk storage capacities of the server. If you implement some of the Active Server or dynamic Web page technologies that Microsoft makes available, you could put a significant processing and memory loads on your system.
  
  
• Systems Management Server typically affects the disk storage and network transmission capabilities of your system. However, because it is based on SQL Server, you could get significant memory and CPU usage if you perform a large number of transactions and queries.
  
  
• SNA Server typically affects the network transmission capabilities of the server. This depends on the type of network connection that you implement into the mainframe environment.
  
  

This chapter ended with a few words on keeping the BackOffice environment integrated. There are a number of benefits for administrators and users alike that are derived from the integrated environment. You must remain vigilant however when integrating new products to try to use the operating system services as opposed to application specific tools. This is especially true of locally developed applications where you have (you hope!) some input into the development process.