Previous Page TOC Next Page



— 5 —
Administrative Concepts


by Ron M. Sonntag and Raymond W. Sundstrom

The Microsoft Administrator's Guide is a two-volume set of approximately 700 pages (in its early released form) of detailed descriptions of functions mostly accessible through the Microsoft Exchange Server Administrator program. Although this reference might functionally address the specific actions required to manage an enterprise Exchange installation, wading through it is quite intimidating. It discourages the beneficial approach of using forethought and planning in even modestly sized Exchange roll-outs. In this chapter, you learn concepts outside simply using the Exchange Server or its administration program. The issues approach the installation of Exchange as a full-fledged enterprise-wide project.

For purposes of this chapter, administration of Microsoft Exchange Server and clients (the Exchange environment) is the process of identifying and organizing the human resources, information, and equipment required to install and maintain the system. The Exchange environment touches on all aspects of an organization's computer system infrastructure, including the following:

Because many of the preceding areas can be exceedingly complex, especially in large national or global enterprises, using the model shown in Figure 5.1 as the context within which you can address each item is useful. The modeled enterprise can be characterized as a small to medium business with about 300 employees. The numbers are not that significant other than to necessitate the use of multiple Exchange servers and to include one remote site.

Figure 5.1. Sample Davy Crockett organizational model.

In Figure 5.1, the main features presented are two domains (AMERICA and MEXICO), three sites (TENNESSEE and KENTUCKY on a local LAN and TEXAS at a remote location), three Exchange Servers also serving as two primary domain controllers (or PDCs, MEMPHIS and ALAMO) and one backup domain controller (or BDC, BOONEVILLE), one high-speed site connector, and one dynamic RAS site connector.

The following sections present approaches to defining administrator roles, creating a task overview, meeting user's needs, establishing policies and procedures, and implementing disaster recovery. In all cases, the sections do not present an exhaustive list of administrator program functions, but rather an ordering and presentation of those tasks and functions that you will most likely need to address to ensure a successful Exchange implementation for an organization like Davy Crockett.

Administrator Roles


The Exchange environment must be managed through two stages (installation and maintenance) and from two different perspectives (site and enterprise). Depending on the size of the enterprise, further role definitions might be needed within each perspective. In the sample enterprise model shown in Figure 5.1, the significant system features to consider for an Exchange implementation are as follow:

These questions are just a sampling of the most obvious issues facing administrators attempting to implement the Exchange environment for the Davy Crockett organization. In the following sections, you examine these questions in more detail from each administrative perspective.

Site Administrator


The site administrator is the person concerned with managing installation and maintenance of Exchange servers and clients at a physical location. Although many areas of responsibility overlap with those of the enterprise-wide administrator, the following are some clear-cut areas on which the site administrator should focus:

Each of these items, which has certain tasks associated with it, is explained in the following sections. The Davy Crockett organization has two site administrators: Davy Crockett has administrator security on the KENTUCKY and TENNESSEE sites, and Administrator has Administrator security at the TEXAS site.

Enterprise-Wide Administrator


The enterprise-wide administrator is concerned with global issues. How a particular workstation or server is configured is not important, as long as that configuration does not interfere with global communications and enterprise standards. Although many of the enterprise-wide administrator tasks overlap the site administrator tasks, the perspective is from a vision encompassing multiple sites and external connectivity. The following are the areas on which the enterprise-wide administrator should focus:

Because many of these areas overlap the areas of concern for the site administrator, one of the primary tasks of the enterprise-wide administrator is to meet regularly with site administrators to coordinate issues that are in common between sites and to resolve conflicting requirements.

Task Overview


The following sections present specific tasks associated with the planning, implementation, user management, and ongoing maintenance of Exchange. The Davy Crockett organization is used as the sample Exchange environment; it was actually implemented as shown in Figure 5.1. The tasks expand, where appropriate, on the areas of concern presented in the preceding sections and from the enterprise and site perspectives.

Enterprise-Wide Planning


An enterprise implementation of Exchange affects nearly every aspect of an enterprise's information environment. A significant undertaking, it has an impact on the users, the network environment, security, support, and maintenance. In all but the most trivial cases, such implementation requires a significant commitment of resources and potentially a significant expense.



Setting up the "little" Davy Crockett organization example required about 40 hours, two exceptionally talented software engineers, five gallons of excellent Starbuck's coffee, and an attitude that resolved finicky modem problems with a hard whack on the table!

As with any project, management approval and buy-in are two of the most important success factors. The most important success factor is using a project management approach that incorporates up-front planning before taking any action. The following sections present the significant enterprise-wide planning tasks.

Network Topology

You must examine and understand the current enterprise network environment from the standpoint of accessibility and traffic volumes. Figure 5.1 serves to identify the major components of the network. Next, you should indicate the kind of connections between servers. If they are on a LAN, then indicate the speed (for example, 10 MB/s or 100 MB/s), or if BOONEVILLE and MEMPHIS were actually connected over a network bridge or router, then the effective communication speed might be only 56 KB/s. Finally, you need to specify access requirements. An Exchange site connector works, for example, only if the router connecting BOONEVILLE and MEMPHIS permits the required packets to be exchanged between the two LANs.

Here is how network topology can influence where public folders are kept, or whether public folders should be replicated to a distant site. In the Davy Crockett organization, if the KENTUCKY site has 125 users, the TENNESSEE site has 125 users, and the TEXAS site has 50 users, you would need to consider topology in the following ways:

You can apply the following general principles when planning the configuration of multiple Exchange Servers within a site.

To ensure the best possible response times, do the following:

To provide the highest possible fault tolerance, do the following:


Transport Protocols

Because Exchange runs on the NT Server platform, the most common transports available are NetBEUI, TCP/IP, and NWLink IPX/SPX. Although NT is capable of using all three of these protocols, many Exchange services require a specific protocol. Table 5.1 lists some of these required protocols and services. Note that connecting two Exchange servers within the same site requires only a LAN connection. That is, if the NT servers can see each other, then the Exchange servers can also see each other and automatically perform directory replication.

If two Exchange servers are in different Exchange sites, however, like BOONEVILLE and MEMPHIS, then you must use a site connector to provide directory replication. In all cases, replication between sites involves the transfer of Exchange messages. This provides the flexibility to use a messaging transport to connect two sites. The messaging transport can use the Internet, dial-up asynchronous connections, public X.400, or even X.25. In all cases, the success of providing directory replication between sites can be determined by the success of being able to send an Exchange message from one site to another.

Table 5.1. Exchange services and their required network transport protocols.

Exchange Service

Required Protocols or Service

Internet site connector

TCP/IP, SMTP, DNS

X.400 site connector

X.25, TCP/IP, TP4/CLNP

MS Mail connector

LAN, Async, X.25

Directory Replication

LAN, Dynamic RAS, Internet site connector, X.400 site connector

Internet Gateway

TCP/IP, SMTP, DNS

X.400 Gateway

X.25, TCP/IP, TP4/CLNP



NT Domains and Trust Relationships

Using the NT nomenclature, the trusted domain contains users, and the trusting domain contains resources (printers, files, applications, and so on). In the Davy Crockett organization, a two-way trust has been established between the AMERICA and MEXICO domains. The reason that you need a two-way trust might not be immediately obvious. Technically, users in the AMERICA domain do not need to log in to the TEXAS Exchange site because the TEXAS site is being replicated through the dynamic RAS connector. Likewise, users in the MEXICO domain are logging in to the TEXAS site only because the TENNESSEE and KENTUCKY sites have also been replicated through the dynamic RAS connector. The trust needs to be two-way because the service accounts for each site need to log in to each other's Exchange servers.



All Exchange servers within the same site use the same service account. After you configure the first Exchange server for that site, the service account is created and used for subsequent Exchange server installations within that site.

Figures 5.2 and 5.3 show that in the installation of the TENNESSEE site's first (and only) Exchange server, the account crockett in the AMERICA domain was granted Log On As A Service rights on the TENNESSEE site.

Figure 5.2. Exchange Server Setup screen showing that this server is the first to be installed at the TENNESSEE site.

Figure 5.3. Information message confirming that the currently logged-in account has also been set up as an Exchange service account.

A similar sequence of screens and dialog boxes appeared during installation of Exchange Server at the TEXAS site, except that the Exchange service account name was administrator. Because the KENTUCKY site is within the same domain (AMERICA) as the TENNESSEE site, the same Exchange service account for that Exchange server installation can be designated as for the TENNESSEE site, namely crockett. Figure 5.4 shows that this is the case by displaying the permissions from the Permissions tab of the Kentucky Site Properties dialog box.

Figure 5.4. Exchange service account permission associated with the AMERICA\crockett account. The other two accounts are not germane to this discussion.

NT User Accounts and Groups

For the most part, adding Exchange to an enterprise running NT does not change the way in which users have been assigned accounts and groups because people's work habits and work assignments dictate their needs for access to information stores and application programs. Exchange Server, however, does impose an additional information management structure in the same sense as a database server environment such as SQL Server does. More mechanisms simply are available for managing information within Exchange than are provided for within the NT operating system. Exchange, for example, utilizes the concept of a Manager user account, which in a real sense has certain authorities over a group of Exchange mailboxes.



NT accounts, such as the Administrator, are frequently used throughout Exchange and specifically listed in the Permissions tab of Exchange container objects. If an employee who has complex and essential security permissions leaves, do not delete his or her NT account. Instead, simply change the name of the account and any other descriptive personal information to that of a new employee. The reason for this approach is that under NT, when you delete an account, the account's Security ID (SID) is permanently lost. This loss invalidates all the security entries you might have created with that SID. Changing the account name, however, does not change the SID.

Individual accounts can be grouped together into local or global groups. A local group is a list of selected accounts from the local domain plus any accounts from a trusted domain plus any global groups from the local or trusted domains. It cannot contain any other local groups. A global group is a list of selected accounts from within the local domain. It cannot contain any accounts outside its domain.

By using NT local and global groups, the enterprise-wide manager can more easily assign different levels of security access to groups of users. One of the more common examples of assigning group permissions is to give certain groups access to specific Exchange public folders. All users in the Accounting department, for example, belong to the global group Accounting, so the Exchange public folder Accounting Notes has permissions granted to the Accounting group. You need to define only one permission versus having to enter each user's account individually.



The account designated as the Exchange service account can access any folder or user mailbox. This account is also usually the Administrator account that was logged in during the Exchange installation. If security of individuals' mailbox content is important, make sure that this service account is given a secure password and that the individual entrusted with this account is aware of the responsibility to protect users' privacy.


Connectivity to Foreign Systems

Planning for connection to foreign systems involves the following:

By far, the most common foreign connection is an Internet mail gateway using SMTP.



Exchange version 4.0a and 4.1 will add POP3 connectivity. With this capability, you will be able to use Exchange as a general SMTP/POP3 Internet Gateway so that you can use a third-party product, such as Eudora, as your main Internet mail application.

To implement the Internet Mail Connector successfully, you must first establish a TCP/IP connection to an Internet Provider (IP). In most cases, having the IP also provide you with a Domain Name Service (DNS) is easiest. You also must establish an Internet Domain Name with the InterNIC that will be associated with the IP address of your Exchange Server running the Internet Mail Connector.



The Advantages of an On-Site DNS Server

The Domain Name Service (DNS) is the Internet device that allows a particular host on the Internet to be referred to by a descriptive name rather than its TCP/IP address. The TCP/IP address for Microsoft's home Web page, for example, is 198.105.232.7. You refer to it when using your Web browser, however, as www.microsoft.com. The DNS server performs the task of associating a name request with a specific TCP/IP address.

Many enterprises are hosting Web, Gopher, and FTP sites, as well as publishing information internally in what is called an intranet. The DNS allows the network administrator to create a logical group of domain names so that users can easily locate needed information. If the DNS is being provided by an outside IP, the process of updating the DNS name and address entries may become quite awkward. Fortunately, the next version of NT (4.0) will include a DNS so that making the choice to implement your own DNS will be considerably easier. Bear in mind, however, that DNSs are a cooperative group, and you will need to consult with your IP to determine the proper way to integrate your in-house DNS with the worldwide Internet crowd.


The other most likely foreign system connection would be through a public X.400 gateway. Here the key is in defining the address spaces correctly using the X.400 addressing conventions, which are described in more detail in Chapters 13, "Connecting to Other Mail Systems," and 14, "Connecting to Other Exchange Sites."

The next most likely foreign connection is with the MS Mail Gateway to provide connectivity to an existing Microsoft Mail environment. I think that unless you have a compelling reason to retain MS Mail, migrating to Exchange is far better. The migration process is straightforward, and the Exchange clients are available for DOS, Windows, Windows 95, and NT.

Security

You can analyze security from the following perspectives:


Enterprise Security

If the enterprise network (WAN) is not connected physically to any other outside information network, either by direct wire links or through dial-up modems, then the enterprise could be considered secure. Most corporate environments, however, include the possibility of individual workstations having modems and, more recently, having direct connections to the Internet.

Modem connections can breach security in several ways:



Even though NT is rated as the only C2-secure certified operating system, viruses that can be harmful in the NT environment do exist. Namely, any DOS virus is capable of doing harm while running under the NT DOS emulation window. Boot sector viruses, although not strictly running under NT, may still damage the hard disk boot sector to the point that NT may not be able to start up. You can find information on the latest NT viruses and virus scan products by performing a Web search on the Internet using InfoSeek, Lycos, Magellan, Yahoo, or any other search engine and entering the keywords [nt virus].


Workflow Automation

You can use many Exchange Server components to assist you in the development of a workflow automation strategy for the enterprise. The Internet Connector enables you to send and retrieve messages worldwide. Exchange forms provide the means to specify standard methods of communication regarding specific business functions. The Exchange API permits design of custom applications that can interface directly with the directory and information stores. The following are a few simple examples of workflow automation:

Undoubtedly, in the near future, full Web integration will be a prominent feature of Exchange. The challenge for the enterprise-wide administrator and for corporate management will be to broaden their vision to include the world-girdling scope of possibilities and to take the necessary time to map out a strategy.

Site-Specific Planning


Exchange sites usually consist of a group of Exchange Servers located on the same LAN segment. This setup also usually means that the servers and user workstations are physically located within a close geographic area. Exchange Server permits easy and efficient automatic replication of Exchange Servers located within the same site without any user intervention.

Consequently, site planning, which also involves the site administrator, is mostly concerned with local issues revolving around hardware, user needs, and administration. The following sections present these areas of concern for the site administrator.

Workstation Configuration

The most common question asked among administrators and management seems to be: "Well, what kind of PC do you think I need to get to run this stuff?" To "gear-heads," the obvious answer is the most blown-out machine money can buy. To management and the chief financial officer, the answer is the least expensive PC that can still do useful work, because they have to buy 500 of them.

Unfortunately, I cannot provide the answer in this book because that answer depends on nifty financial analysis that includes information such as cost of maintenance, amortization, risks and benefits, productivity gains, and so on. I can make a straightforward recommendation, however, based on knowledge of the applications out there, Exchange client requirements, and what users will be doing on their PCs.

Table 5.2 presents some recommended workstation configurations, given a type of usage pattern. These recommendations are based on my opinions and are not based on any rigorous Windows benchmarks. Also, I do not believe in buying employees "minimum required" workstations. Not only are you doing your employees a big disfavor, but you also set yourself up for a horrible depreciation scenario.

Table 5.2. Sample workstation configurations to support a specific mix of work.

Work Mix

Workstation Configuration

Administrative; front office. Use Exchange,

486/66 MHz or better, 16MB RAM or more, 500MB hard disk

MS Office


Technical support; uses custom application

Pentium/90 MHz or better, 16MB RAM or more, 1GB hard disk

Developer; has numerous compilers and tools

Pentium/130 MHz or better, 32MB RAM, 2GB hard disk



Server Configuration

The Exchange Server configuration is driven by the number of users it supports and, to some extent, by the number of ancillary tasks it may perform in addition to the regular mail deliveries and public folder management. An Exchange Server, for example, may act as a bridgehead for several other Exchange Servers. Or it may be the principal Internet Mail Gateway. Each of these Exchange roles or functions requires additional system resources in accordance to the demand placed on them. The Microsoft Internet Exchange Gateways, for example, currently handle over a million Internet messages per day. Microsoft's internal Exchange Servers are processing over three million messages per day. This work requires some serious horsepower.

Because so many parameters can affect the selection of hardware, it is probably best to consider a minimum configuration requirement and to target that for the small- to medium-sized business environment that this book is geared toward. For the Davy Crockett organization, the following features would define a good starting point for any of the site servers in the AMERICA domain:

If the servers are performing any additional tasks, such as providing general file services or hosting an Internet Information Server Service, then the list should be altered to the following minimum features:

You can accomplish more specific tuning by using the various performance monitors described later in this book in Chapter 21, "Monitoring and Preventing Problems."



The PCs actually used for setting up the Davy Crockett organization examples were two 100 MHz 486s with 32MB RAM each and one dual Pentium 90 MHz with 40MB RAM. The two 486s were the machines in the AMERICA domain. Also note that I first attempted to set up with only 16MB RAM on the 486s. This did not work. The virtual disk thrashing was unmistakable and would have caused Exchange to fail under a real installation with several hundred users.


NT User Accounts and Groups

Identifying groups within an Exchange site is almost identical to establishing groups within an NT domain. You should establish your NT groups according to functional areas of the organization, such as accounting, sales, marketing, development, support, manufacturing, Q&A, and so on. You might also want to distinguish between management levels so that managers have access to more information across functional divisions.

Make sure that a site administrator account is defined, if it is different from the NT domain administrator, and that it is entered at the site and configuration levels of the Exchange object hierarchy as shown in Figure 5.4, where Davy Crockett has the Exchange service account permission at the site level.

One of the most common uses for user account groups is to provide different levels of access to Exchange public folders. A folder hierarchy or a group of folders can be dedicated to the Sales group, for example. You might use another group of folders for customer support or tracking individual calls and responses.

The actual creation and assignment of permissions is a bit convoluted in Exchange. A folder can be created only by an Exchange client; it cannot be created by the Exchange administrator program. On the other hand, only the Exchange administrator program can set up the replication schedule for that folder.

Because folders are such a powerful and useful Exchange feature, The section titled "One-Time Implementation Tasks" walks you through setting up the Sales public folder on the TENNESSEE site and how it is replicated through to the KENTUCKY site.

Site and User Security

Site security carries the same cautions regarding network and modem access as you learned for enterprise-wide security. In addition, you should take the following steps:

Probably the most important aspect of Exchange security is the deliberate attention paid to establishing good passwords and limiting the number of individuals entrusted with them. Chapter 17, "Exchange Message Security with Key Management Server," provides more details on implementing Exchange messaging security.

User-level security is not much different from that security needed for NT user accounts. Whatever policies have been established for users at the NT domain levels will probably be used as is. Exchange does provide for new areas where individual users may be given administrative control, or a group of users may be formed in support of certain Exchange functions.

A user, for example, might be given the responsibility to oversee the Sales public folder (you create this public folder later in this chapter). In this case, the Exchange administrator could set up that user with Owner rights to the folder to enable him or her to add, modify, and delete any message, or to create subfolders and move messages between folders. All other users whose job functions include sales support could be made part of the NT Sales group. This group could then be given Author permission to the Sales folder, which would enable the group to create, modify, and delete their own postings to that folder, but they could not modify or delete each other's messages.

The Exchange Key Management service may be implemented and used by the user clients. The important aspect of using the security keys is in providing the users with their security tokens, which are essentially unique passwords that permit messages from one user to be encrypted and/or authenticated as originating from that user. The Exchange Administrator obtains this token, and it is only as secure as the method used to transmit it to the user.

Workflow Automation

Workflow automation at the site level is usually just a more detailed view of workflow automation for the enterprise, as described previously. Depending on the organization, sites can have well-defined functional areas that are distinct from other sites. If this is the case, then it makes most sense to give each site the authority and mission to develop its own automation methods. After all, usually the people who are doing the actual work can best tell you what they need to make their work easier and more productive.

Again, the key Exchange features that permit development of workflow aids are forms design and management, custom field attributes, public folders, and the Exchange API.

Employee Training

Probably the most common mistake management makes when "rolling out" a new enterprise standard is never involving the employees in the process. It really is amazing how often a new "productivity" application is given to employees who then provide the immediate feedback that their lives were simpler before this newfangled tool was foisted upon them. It is also probably true that the new tool really is better than what they had, but because of lack of involvement in the roll-out process, they cannot appreciate how it is supposed to fit in to their work environment.

The following shows the steps in which employees should be involved for "rolling out" a new office tool:

  1. Establish the need.

  2. Determine the method used to fulfill the need.

  3. Present (market) these options to the employees to obtain a buy-in.

  4. Establish a training schedule to prepare employees for implementation of the new method.

  5. Coordinate the implementation of the method.

  6. Follow up to determine success in fulfilling the needs identified.

Looks like the entire life cycle of the tool, doesn't it?

Implementing Exchange should involve employees at every step. If you are converting from an existing MS Mail environment, then most of their training will center around the new Exchange features such as public folders or Internet Mail connectivity. If this is a first-time e-mail implementation, then you should conduct some internal seminars on corporate e-mail. Some of the more obvious areas to cover include the following:

This list is not exhaustive, but each of the items in the list can become quite complex, depending on the environment and the kind of work the employees are doing. A development group, for example, could use public folders and a structured Subject line to implement a bug-tracking system. Forwarding mail can be used to inform someone, or it can be part of a strict review process.

The great thing about e-mail is that its use is infinitely varied. What is placed in a message is only limited by the imagination of the participants. Good and thorough training is the key to unlocking this potential within each employee.

One-Time Implementation Tasks


The following list summarizes the most common one-time implementation tasks for setting up an Exchange organization. Most of the items are taken from the Davy Crockett organization example:

  1. Design your enterprise domain and network strategy indicating what Exchange Servers will be used and in what NT domains they will be placed (see Figure 5.1).

  2. Install or update to NT Server 3.51, Service Pack 4 or later, on all PCs to receive Exchange Server. Make sure that all needed services (such as RAS) and protocols (such as TCP/IP) are available.

  3. Establish the necessary domain TRUST relationships.

  4. Establish the necessary administrative and Exchange services accounts.

  5. Install Exchange Servers at each site. Verify that the organization and site names are correct for each server.

  6. Create the user mailboxes at each site. Test that messages can be sent between mailboxes within each site.

  7. Create the public folder hierarchy for each site or for the organization.

  8. Establish the directory replication scheme between sites. First test that messages can be sent to recipients between sites. Then implement the directory replication services.

  9. Confirm that all recipients are visible between replicated sites (see "Directory Replication over Dynamic RAS" later in this chapter).

  10. Establish the public folder replication scheme (see "Folder Creation and Replication" later in this chapter).

  11. Establish the offline address book.

  12. Implement Exchange Key Management Server if advanced security is required.

  13. Set up foreign system connectors, such as the Internet Connector. This step also requires the establishment and use of name spaces.

  14. Make the Exchange client available from an NT network share (preferable), or create a set of install disks.

The following sections provide some actual examples for the more complicated steps presented here, using the Davy Crockett organization.

Directory Replication over Dynamic RAS

In the Davy Crockett example, the TEXAS site users need to be able to send and receive messages from the KENTUCKY and TENNESSEE sites. Because the only connection available to TEXAS is via modem, a dynamic RAS connector had to be used to enable directory replication. The following sequence shows how this connector was set up at the TENNESSEE site on the MEMPHIS server. The same steps were then followed at the TEXAS site on the ALAMO Server. To follow along, complete these steps:

  1. You need to install a RAS MTA transport stack. Choose File | New Other | MTA Transport stack. You must install and configure RAS on this server before you can install the RAS MTA transport stack. Figure 5.5 shows the available transport stacks that you can install. For this example, choose RAS MTA. The server shown in the figure is BOONEVILLE, but the RAS MTA transport was actually installed on MEMPHIS. Figure 5.6 shows the added Server object representing the RAS connector on MEMPHIS. Figures 5.7 and 5.8 show the configuration screen. Note that the Connectors tab of the Properties dialog box, shown in Figure 5.8, is empty when the RAS MTA is first installed because no connectors have been defined yet.

  2. Figure 5.5. Available choices when installing a new MTA transport stack.

    Figure 5.6. The highlighted object in the right window pane shows the newly added RAS MTA transport stack for the MEMPHIS server.

    Figure 5.7. The General tab of the RAS MTA transport stack configuration.

    Figure 5.8. The Connectors tab of the RAS MTA transport stack configuration.

  3. Now you can install a dynamic RAS connector. If you try to install the dynamic RAS connector before installing the RAS MTA transport stack, you get the error message shown in Figure 5.9.

    Getting this message is not a big deal. Simply go back to step 1. To install the dynamic RAS connector, select the Connections object and then choose File | New Other | Dynamic RAS Connector. You then see the configuration dialog boxes shown in Figures 5.10 through 5.16.

    These figures show what it took to successfully configure a dynamic RAS connection between the TENNESSEE and TEXAS sites (assuming that the same set of configurations were performed on the ALAMO server). Some questions, however, remain as to the difference between the Connected Sites Routing Address and the Address Space entries and their configurations.

  4. Figure 5.9. Error message that results when you attempt to install the dynamic RAS connector before the RAS MTA transport stack has been installed.

    Figure 5.10. The General tab of the dynamic RAS connector on MEMPHIS computer. Note that the Phone book entry, RONHP, is a prior defined RAS entry that contains the phone number of the TEXAS site ALAMO server modem.

    Figure 5.11. The RAS Override tab of the dynamic RAS connector on the MEMPHIS computer. The Connect as fields are specified because the default Exchange services account is different at the TEXAS site than at the TENNESSEE site.

    Figure 5.12. The Connected Sites tab of the dynamic RAS connector on the MEMPHIS computer. This tab explicitly lists the external sites that are connected to this computer (the MEMPHIS server).

    Figure 5.13. The General tab of the TEXAS site, viewed by clicking the Edit button shown in Figure 5.12.

    Figure 5.14. The Routing Address tab of the TEXAS site, viewed by clicking the Edit button shown in Figure 5.12.

    Figure 5.15. The Address Space tab of the dynamic RAS connector on the MEMPHIS server.

    Figure 5.16. The General tab for configuring an X.400 address space, viewed by clicking the Edit button shown in Figure 5.15.

  5. At this point, you should test the dynamic RAS connection before attempting to configure directory replication. Sending a message from TENNESSEE to a valid recipient at the TEXAS site accomplishes this test. Because the sites have not been replicated, no valid TEXAS site recipient exists at the TENNESSEE site. How do you tell the system to send a message to, say, Daniel Boon? Use the X.400 addressing method to specify Boon's mail address. In this case, enter the following into the To: field of the e-mail message:

    x400:g=Daniel;s=Boon;o=TEXAS;p=Davy Crockett;a= ;c=us

    Sending this message causes the dynamic RAS connector to dial out, connecting to the ALAMO server via modem, and then, if everything is configured as above, deliver the message to Daniel Boon.

  6. Now configure the Directory Replication Connector by selecting the Directory Replication container and choosing File | New Other | Directory Replication. Figure 5.17 shows the Directory Replication container with two configured connectors. Figures 5.18 and 5.19 show the various property tabs associated with the Directory Replication Connector on the MEMPHIS server configured to replicate with the TEXAS site.

Figure 5.17. The contents of the Directory Replication container on the MEMPHIS server. Two Directory Replication Connectors are configured, one to replicate to the KENTUCKY site and one to replicate to the TEXAS site.

Figure 5.18. The General tab of the TEXAS site Directory Replication Connector. Note that MEMPHIS and ALAMO are also functioning as bridgehead servers.

Figure 5.19. The Sites tab of the TEXAS Site Directory Replication Connector. TEXAS is the inbound site from the TENNESSEE site's perspective.

Setting up directory replication between sites on the same LAN, as between KENTUCKY and TENNESSEE, is similar to the preceding steps, but much simpler because all the configurations for RAS aren't needed. After you configure all the directory replicators, simply wait 15 to 30 minutes, and all the Exchange directory information, as shown in Figure 5.17, will become visible at all servers at all sites.

Folder Creation and Replication

The following principles govern the creation and use of public Exchange folders:

Setting up a public folder hierarchy is probably something you want to spend some time thinking about. You need to consider enterprise-wide and site-specific issues. Even in a small organization, public folders can be used to contain information about transitory events, such as projects. Think about creating a folder hierarchy that provides some stability at the highest levels but allows a manager the freedom to create additional folders at the lower levels as needed. You do so by giving certain users (managers) permission to create folder hierarchies.

The following steps were used to create the Sales public folder on the TENNESSEE site and replicate it to the KENTUCKY site. Here's how you can set up a folder like the one in the example:

  1. Using the Exchange client, create a folder at the TENNESSEE site on the MEMPHIS Server by choosing File | New Folder (See Figure 5.20). When you press OK, the Sales Properties dialog box appears with the General tab information visible (see Figure 5.21).

  2. Figure 5.20. New Folder dialog box shown creating the public folder Sales.

    Figure 5.21. Part of the dialog box sequence for creating the public folder Sales. The General tab is at the forefront.

  3. Add groups and/or user accounts to the Permissions list of the Sales public folder. In the case shown in Figure 5.22, Fess Parker, a BOONEVILLE user in the KENTUCKY site, is given Author permission.

  4. Figure 5.22. Part of the Sales Properties dialog box showing the information on the Permissions Tab.

  5. Create a message as a posting to the Sales folder using the Exchange client in the TENNESSEE site, as shown in Figure 5.23.

  6. Figure 5.23. Message posted to the Exchange public folder called Sales on the MEMPHIS server.

  7. Figure 5.24 shows how the public folder hierarchy appears in the KENTUCKY site on the BOONEVILLE server. The directory store shows the folder, but the information store does not yet contain the posted message because the folder has not been replicated, as indicated by the message in Figure 5.25.

  8. Figure 5.24. KENTUCKY Exchange site object hierarchy. Note that the public folder Sales is visible.

    Figure 5.25. Error message that appeared when user Fess Parker double-clicked on the public folder Sales using the Exchange client.

  9. To replicate the Sales public folder properly, add the BOONEVILLE server in the KENTUCKY site to the Sales folder Replicate Folders To list, as shown in Figure 5.26. Note that you must do this from an Exchange administrator program connected to the TENNESSEE site and with appropriate user access permissions.

  10. Figure 5.26. The entry Kentucky\BOONEVILLE shows that the Sales folder will be replicated to that site. The MEMPHIS entry was provided as a default when the folder was created.

  11. Figures 5.27 and 5.28 show that the message, originally posted on the MEMPHIS server, is replicated across the site connector to the BOONEVILLE server.

  12. Figure 5.27. This time the Exchange client for Fess Parker shows a posting in the Sales public folder.

    Figure 5.28. Double-clicking on the posting from Davy Crockett shows the details of the posting. They really had great service in those days!


The preceding sequence of steps is fundamental to the creation of any public folder hierarchy that includes public folder replication to another site. In fact, each public folder must be configured individually, in terms of its replication to other sites. This is both a plus and a minus. It is a plus in that Microsoft has provided complete flexibility for every aspect of public folder management. The minus is that setting up a large number of public folders can be quite tedious. A more complete description of the public folder configuration options is given in Chapters 10, "Configuring Basic Server Operations," and 20, "Maintaining Exchange."



When you configure public folder replication between sites, make sure that you wait long enough for replication to take place. The shortest time frame for replication is when you choose Always on the Replication Schedule tab of the Sales Folder Properties dialog box. Replication usually requires about 15 minutes. If you check for postings before replication takes place, you might think that it didn't work. To be sure, check the Folder Replication Status tab to see when the last replication to your site actually happened. In Figure 5.29, the Folder Replication Status tab shows that information was replicated to this folder from the MEMPHIS Server on 6/11/96 at 4:20 PM.

Figure 5.29. The Exchange Administrator Properties dialog box for the Sales folder in the KENTUCKY site.

Ongoing Maintenance-Related Tasks


For the small- to medium-sized installation, maintenance should be fairly minimal. Feedback from users indicates whether performance is within the expected boundaries. The primary maintenance tasks you should be concerned with are as follow:

These issues are explored in more detail in Chapters 21, "Monitoring and Preventing Problems," and 22, "Diagnosing the Cause of a Problem."

Meeting Users' Needs


The Exchange client is a much simpler tool than any of the components associated with Exchange Server administration. Most of the issues surrounding Exchange clients include the following:

If users are migrating from Microsoft Mail, then your training effort should be minimal. Otherwise, be prepared to address each of the preceding issues in detail, or designate some network support people to meet the need. Most importantly, you should be responsive to the inevitable frustrations expressed by these first-time users. Remember when you had to figure out the correct parameters to use with the DOS backup command? Well, you now have several dozen more parameters than before. You may not run into them for 80 percent of all e-mail traffic, but with 50 or more employees, someone somewhere will be trying to send a MIME-coded Word document to a system that recognizes only UUENCODE. Or someone might be trying to send a 1600 x 1220 x 256 bitmap of the singer Sting to a friend down the hall who is running Windows 3.1 on a 4MB machine, and that person may wonder why every time he or she clicks on this mail message, the PC crashes.

Establishing Policies and Procedures


Exchange has the potential for participating in so many facets of a business that it is not possible to enumerate all policies and procedures that could be implemented. The areas discussed in the following sections are most likely to benefit from the creation of some standards.

E-Mail Subject Lines


Exchange enables you to apply rules to any incoming message. These rules may operate on many components of a message, as shown in Figure 5.30.

Figure 5.30. The Exchange inbox assistant. Shown are the various filters and actions that you can impose on an incoming message.

By specifying, for example, a policy that all e-mail messages for the consulting project "Acme Nose Tweezers" begin with "Acme Nose Tweezers:", a user could create a message folder into which all messages pertaining to the Acme Nose Tweezers project get placed. Similarly, in a matrix organization, an employee can have all e-mail messages from his or her various "bosses" placed in their respective folders by defining a routing rule based on the message originator's name.

Because all elements of the e-mail message are open to rule application, no limits are placed on how an organization might structure e-mail messages to take advantage of this automatic message processing.

Public Folders


As mentioned previously, public folders provide one of the most powerful means of establishing common communication forums within an organization. The policies and procedures governing public folders are established by the purpose of those folders. A bug-tracking folder might be managed by the testing manager, who establishes the format of Subject lines and maybe even establishes a public form for reporting bugs. Another public folder may simply store all Internet Provider-related messages for read-only access.

E-Mail Attachments


With e-mail attachments, the subject gets a bit more sticky. One of the primary benefits of Exchange is its ability to use Microsoft's Active-X technology for including in the body of a message objects such as Word documents, Excel spreadsheets, and any other native format application documents that adhere to the Active-X standard. This is great! A network administrator may say, for example, "Where am I going to get all the disk space to store these messages containing the latest images from the Hubble Space Telescope that have been forwarded to all 300 employees?"

Here, the initial parameters for the information store come into play. You can set limits for the size of any message and for the total disk space occupied by any mailbox. Establishing these standards requires a careful review of employee work habits and matching work-related information sharing requirements with available and affordable hardware. Chapter 10, "Configuring Basic Server Operations," presents examples on how you can specify these file size limits for the message store and public folders.

E-Mail Etiquette


You can find quite a few books and Web references on the topic of e-mail etiquette. The following list summarizes some main points:

In general, treat e-mail just like you would treat a letter delivered on your company's stationery.

Disaster Recovery


As with any mission-critical resource, the key to disaster recovery is having a procedure for creating reliable offline backup of important information and a procedure for accessing and restoring it when needed. How often should you create backups? The answer is as often as it takes you to reduce the risk of non-recoverable data loss to an acceptable level.

How do you determine what is acceptable? Here is one example: You work at a consulting company with 50 employees who bill out at $125 per hour. You think you can skimp on backup hardware and the cost of tapes, so you run full backups just once a week, on Friday. The main company development server fails when the disk head decides it's time to dig trenches on one of the disk platters. At 6000 rpm, the magnetic head meets the oxide layer at about 62 mph. The resulting wreckage damages the rest of the disk so that no information is recoverable. So what does your loss cost the company? A whole week of billing is gone: 50 people working 8 hours per day for 4 days. That's about $200,000 of lost billing—all because someone didn't want to pay maybe $5,000 more for tapes and equipment that could perform backups on a daily basis. Let me put it another way: You must create frequent tape (or other reliable offline storage medium) backups of all important databases. Otherwise, you deserve what you get.

I hope that the preceding scenario will raise the hairs on the backs of some necks and get people asking themselves when exactly was the last system backup run. Is the preceding scenario the worst case? Not even close. Losses due to poor backup procedures can easily exceed millions of dollars. To protect against data losses, as an example, my company, by most measures a small business, has invested well over $15,000 in an offline tape backup system to ensure recoverability under all circumstances. This system includes being prepared for the following:

The preceding capabilities are applicable to all system software and data components. The method you use may vary because of certain application-specific requirements. Microsoft SQL and Exchange Servers, for example, need to use a special backup program to back up live database files. Having a special backup program, however, does not change the fact that you need a procedure in place to run these backup jobs.

Although this book is not intended to be a backup primer, the following concepts may aid in the discussion of how backups and disaster recovery in general are handled with Exchange:

Hardware Compression: Works just like software compression except that the backup hardware performs the data compression. See the sidebar "A Warning About Compression."



A Warning About Compression

Most backup software presents users with a choice of selection: No Compression, Software Compression, or Hardware Compression. Although compression is advantageous in that it allows more information to fit on a given tape format (usually about a 2:1 factor), you may run into some pitfalls.

Think about the fact that a disaster recovery plan will be in place for years and that the procedures and equipment to support it will need to be effective over many years. If you use software compression, then your backup data can be read only by the software that created it. If you use hardware compression, then your data can be read only by the hardware that created it. For example, the 8mm tape backup unit you bought two years ago failed, and you have to restore some important client database information now. That particular drive is no longer manufactured. You can get other 8mm drives in, but because you used hardware compression, which was proprietary to your drive, you won't be able to read the information with any of the new 8mm replacement units. If you had used software compression, or no compression, you would not have this problem.

Here's one recommendation: Do not use hardware compression unless you can afford to buy enough extra units to ensure that one will always be available if the other units fail. There is one exception to this rule. If you buy a Digital Linear Tape (DLT) unit, go ahead and use hardware compression because only one manufacturer in the world currently produces DLT units.


Finally, with regards to performing tape backups, whatever hardware or software system you use, it must be reliable and simple to use. If the tape backup software requires a "gearhead" to run it, don't buy it. If it is not easy to run, people will avoid using it.

Exchange Server Backups


This section gives a brief overview of the Exchange backup and recovery environment. You can find more specific details in Chapter 20, "Maintaining Exchange."

Exchange Server uses a modified version of the Jet Database as its information store. Microsoft has implemented a logging feature that records all information store or directory events and transactions in special log files. If the system performs an abnormal shutdown—for example, a power failure or system General Protection Fault (GPF)—Exchange detects it and, when the system is restarted, attempts to recover from the log files. The log files essentially serve as a record of all the transactions and events related to the directory and information stores.

The following is a breakdown of the important components of each backup type:

Differential Backup: The LOG files are backed up but not changed in any other way since the last full backup.

The Exchange Database can be very large. Changes to that database are recorded to the LOG files. Rather than be forced to back up the entire database during daily backups (as most normal DOS backups would require), just the changes, as recorded in the LOG files, are backed up.

These backups and restores are accomplished by a special version of the NT Backup software, which is installed during the Exchange Server installation process. In fact, this version has been designed to be able to recognize all Exchange Server sites and to be able to back up and restore to them remotely. Figure 5.31 shows the organizational hierarchy when selecting the Exchange Organization window.

Figure 5.31. The Microsoft Exchange window available from the special version of Backup that is installed with Exchange. This view was obtained from running Backup on the BOONEVILLE server.

Notice that all three sites in the Davy Crockett organization show up in this window as possible backup options. The specific site selected also indicates that the directory and information store are available to be selected for an operation.



The Microsoft Exchange Reference indicates that incremental and differential backups cannot be run when circular logging is enabled. Unfortunately, this is not strictly true. As Figure 5.32 shows, you can run an incremental backup.

Microsoft is really saying that you shouldn't run incremental or differential backups when using circular logging (which is the default). The reason is that circular logging overwrites the log files every week. If you are relying on incremental or differential backups for recovery, then you could find yourself without recourse because circular logging just overwrote the last week's worth of changes to the data and information stores. Just be sure to uncheck the boxes shown in Figure 5.33 if you plan to use incremental or differential backups as part of your regular backup cycles.


Figure 5.32. This window shows that an incremental backup is about to be run even though circular logging is currently enabled.

Figure 5.33. The Advanced tab under the BOONEVILLE Properties showing that circular logging is the default.

Safety Through Replication


At least some of Exchange's information may be protected through replication to another server or site. Public folders, for example, are prime candidates for safety through redundancy. Microsoft's reference states that when a replicated server is brought back online, its information is updated from the current information on the replication servers. I have only performed perfunctory tests to see if it really works. The initial results were encouraging, but systematic tests are needed to completely validate this as a reliable safety net.

Having a Written Plan


Many more aspects are involved in being prepared for disaster and recovery than just using the tape backups. None of these measures, however, will do any good if the methods and procedures used for recovery are stored in one individual's brain. Include the Exchange backup plan, general server backup plans, and all other business-related aspects of disaster recovery, such as insurance, emergency phone numbers and contacts, financial systems records, client notification procedures, and so on, in a written disaster recovery plan that is kept both on-site and in a secure location (like a safety deposit box) off-site.

Summary


This chapter has provided a framework for organizing an Exchange Server implementation strategy. The most important fact to keep in mind is that Exchange is a tool that will be used by people. That is why some of this chapter has been devoted to organizational principals surrounding people. The installation and maintenance tasks are presented from the perspective of the enterprise-wide administrator and the site administrator. These tasks touch on networking, workstation and server configuration, managing user accounts, connectivity to foreign systems, security, workflow automation, and training.

The examples use the Davy Crockett organization (Figure 5.1) as a typical small- to medium-sized business with a few hundred employees. We have walked through specific cases for configuring the Exchange Servers and the domains and trusts needed for proper messaging and replication, the creation of public folder and public folder replication, and have given hints on what to expect in terms of performance, security, and remote connection through dynamic RAS. Thus, the scope covered is large and necessarily at a high level. The remainder of this book revisits each of the concepts presented in this chapter from a more detailed and functional view. In most cases, the initial installation of Exchange Server may very well only require the information presented in this chapter. However, to truly use the rich feature set incorporated into Exchange Server in the best way possible for your organization, read on and enjoy!

Previous Page TOC Next Page