Most e-mail engineers regard the flexibility of administration in messaging servers and clients as the most important feature in any product. Rarely do they have to interface with the installation process, and system design tools are normally used only
throughout the planning stage of an install. Administration and troubleshooting are daily tasks, which can become mundane at times. User mailboxes need to be deleted and created, distribution lists must be updated, mail delivery problems must be
researched, global address lists must be kept up-to-date, system outages must be fixed, and many other routine tasks must be done to keep the system healthy.
Mail systems range from the small workgroup post office to thousands of messaging servers for an entire enterprise—each with different needs for administration and maintenance. As an administrator, you might be responsible for only a few servers
with less than a hundred users, or a member of a large group of administrators responsible for keeping tens of thousands of users' mail running smoothly for an entire organization. Messaging systems are very dynamic in nature as the needs and structure of
an organization grow. Each messaging system is as unique as the company that uses it, but a common set of basic tasks are needed to provide messaging services.
This chapter takes you through the different administrative features of exchange and explains how they can be utilized to keep the system running smoothly. It discusses how the Exchange tools can manage users, servers, distribution lists, connectors,
MTAs, public folders, and Groupware applications. It also explores how to set up and use the disaster prevention and recovery tools available throughout the system. Because these systems are built by man, and broken by man, there is a section on what tools
are available to troubleshoot system problems. Maintaining secure access to messaging resources is at the top of everyone’s list, and this chapter provides the details of how security fits into Exchange administration.
As you read through this chapter, keep this very important thought in mind: there is rarely only one way to perform a specific task or use a feature in Exchange. I will try to point out the different methods available where possible, but you will
routinely come up with new methods of your own. This flexibility in choosing the way to get your job done only accentuates the robustness inherent within Exchange Server.
The heart of managing any messaging system is the administrative software. It should provide a single view of the messaging resources for your entire organization and enable those resources to be managed from any location. Because it is estimated that
over 72 percent of the cost of implementing a client-server messaging system comes from keeping it running, the administrative applications must be robust enough to reduce the time and costs of administration. Exchange Server includes a single-view
graphical administrative application that enables you to manage all the various components of Exchange Server from a single interface. From this view, you can manage the following components and objects:
The Exchange administration program is started from the icon located in the Microsoft Exchange program group for any Windows NT server or workstation on which it has been installed. The path and filename for the program are
<drive>:\exchsrvr\bin\admin.exe if you accepted the defaults for the installation procedure. Remember that Exchange supports various hardware platforms, so don’t try to run the alpha version of the application on an Intel machine and vice-versa.
The layout of the administration program is simple, but highly informational. When you connect to an Exchange Server at either program startup or by selecting Open from the File menu, a window is opened that displays all the directory information that
server is aware of. The leftmost frame contains an organizational view of the Exchange directory hierarchy with the root-level organization, the public folders, the global address list, and each of the Exchange sites that have been replicated, including
the local site. The frame on the right contains specific information on the directory object that is selected in the left frame. See Figure 22.1 for an example of the Exchange Administrator user interface.
FIGURE 22.1. The Exchange Administrator program user interface.
Selecting objects from the left frame exposes the objects relating to the selection in the right frame. If you click on a site object in the left frame, for example, you see the configuration object and all the recipient containers for that site. You
can also expand the branch of any object in the left frame that has a plus sign attached to it and see the objects within that branch connected with a dotted line. The local site of the server you are connected to will show up in bold, and replicated sites
will be in normal lettering. This method of displaying the Exchange directory enables one to easily traverse the hierarchy to "drill-down" to an object that needs to be managed. Changes can only be made to the site corresponding to the server you
have connected to, so you might want to have connections to many servers at once.
Across the top of the interface are the menu selections used to perform various tasks. These menus can be used in combination with a selection of a directory object or used to performs tasks that are not specific to any directory object. Many of the
menu selections have associated hotkeys that can be used if you prefer not to use the mouse. Although I do not suggest that you learn how to operate this program totally by the keyboard, you might find that many of the keyboard shortcuts are much
easier than the corresponding series of mouse clicks. You might be faced with a situation where the mouse has stopped functioning on a server, and you would not want to disconnect hundreds of users from the system just so you can reboot to restore mouse
functionality.
For the majority of daily administrative tasks, you use the File menu selection. It includes selections for connecting to Exchange Servers, creating new mailboxes, creating new custom recipients, creating distribution lists, creating other (connector,
dirsync etc) objects, displaying the properties for a selected object, and exiting the program. See Figure 22.2 for the File menu selections available.
FIGURE 22.2. File menu selections.
There is an extra menu selection available from the File menu: the raw properties selection. You can enable this option by adding the /R option to the command line for starting the program. This option enables you to edit the X.500 directory schema directly, modifying object properties not available in the standard interfaces. Because this is a very advanced feature, use it only if instructed by technical support or a well-written technical article. When editing the raw properties of any object, there is a possibility of damaging that object, which would require restoration of the entire directory database.
The Edit pull-down menu is used for the various editing features that can be done on certain objects. These objects include recipient containers, recipients, distribution lists, transport stacks, MTAs, and other objects that are not permanent to the
administration program. The View pull-down menu is used to change the appearance of the left and right panes, and can be used to expand or contract a single branch or the entire list. This can be very useful for collapsing many branches if you have been
searching the tree for a specific object.
Very often overlooked, but very important to keeping the system running, is the Tools menu. It contains the utilities for extracting user accounts, importing and exporting recipients, managing electronic forms, moving or creating mailboxes, and setting
program options. As you proceed with a migration or need to change a user’s proxy-address, these menu selections will be used very often. See Figure 22.3 for the menu selections available under the Tools menu.
FIGURE 22.3. Selections available from the Tools menu.
The drop-down menus for Window and Help operate just like any standard windows CUA menus. The Window menu enables you to tile, cascade, move, and resize the windows opened for each server connection. The Help menu is designed to give both
context-sensitive help and topic search capabilities. The online books for Exchange are used for the help topics and as replacement for the printed manuals.
The first time you start the administration program, the default values are set for many very important options. You should customize the interface immediately to your needs and make sure that certain custom defaults are configured. To customize the interface, select the Tools root menu, then click on the Options selection. From this page, you configure the default mailbox naming conventions, the Windows NT domain to use for creating new accounts, the different tabs that can be displayed (such as Permissions), and whether NT accounts are deleted when a mailbox is removed. A few minutes should be taken with every new install of the Administration program to make sure these settings are consistent and meet your requirements. There is nothing more aggravating then to find out that another administrator is creating nonstandard display names or is not able to see the permissions tabs for objects.
How quickly and easily can you create new user mailboxes in your current system? After you create those names, how long does it take for the new account to make it to all the appropriate address lists to enable current users to mail to that person? It
takes a considerable amount of your time to perform these tasks, even if you have been doing it for years. Many of the older messaging systems were not designed to handle the fast pace of most company’s business needs. Messaging systems must make
speedy mailbox implementation and propagation their primary focus to be able to support the demands of enterprise-level systems.
The user mailbox is the core messaging object that exists in the Exchange directory schema. Exchange has four ways to create user mailboxes and three ways to modify and delete them. The administration program is used for two of the methods, and the NT
user manager for domains is the other option. User accounts can also be created using the migration and extraction tools, but they cannot be modified or deleted using these tools. The following examples take you through the best way to use each of these
methods.
Let's first examine the most common scenario for creating a new user mailbox. Your company, CRC Enterprises, hires a new employee for the Tampa office in the southeast division. You receive an internal form instructing you to create the appropriate
accounts needed for this new user to work, and the form indicates that Bud Johnson will start today. Your company uses both Windows NT and Novell 3.x servers, with a Master domain named CRC_MUD for user accounts and DSMN for managing Novell
accounts. You are located in the company’s headquarters in Atlanta, which is connected to Tampa by a 256K frame relay connection.
Because you are working from a Windows NT Workstation that does not have the NT Server administration tools installed, you will use the Exchange administrator program to create the account. You first connect to the server in Tampa, and then expand the
site for Tampa named NA_FL_TPA_724. Next, select the recipient container named "Recipients" from under the site, and click on Create New Mailbox from the File menu. This brings up the Mailbox properties sheet, as seen in Figure 22.4.
FIGURE 22.4. Mailbox General properties sheet.
As you enter his first, middle, and last names, the display name and alias are automatically created as you type. The method used to create the display name and alias is configured under the options selection from the Tools menu. You then can enter the
appropriate extended information, such as address and departmental data. After entering the information for the mailbox names and extended information, click on the Primary NT Account button to set the NT account for his mailbox. Because in this example
you do not have account management capabilities, you should select to use an existing account that was created by one of the NT account operators previously. Browse the window to find his appropriate NT account, and click on Add, then on OK to finish your
selection.
You might not want to get carpal tunnel syndrome from typing all the extended information for every mailbox—so why not use a template. To set a template for accounts created at a specific site, expand the recipient container in that site, and create a mailbox named something like "Template". Fill in the appropriate values for any of the common fields, and make any other selections on the other properties pages. You can choose to make this mailbox hidden from the directory on the Advanced page so users will not mail to it. Use this hidden mailbox as the template account for migrations or bulk imports.
To continue to set up Bud’s mailbox, you proceed to the Organization Properties page. Here, you select who his manager is and who are the people who directly report to Bud. This information can be used in Groupware applications or to help create an
instant view of the organizational chart. You can choose only people who directly report to Bud from the local site, but you can assign Bud as the manager to a user in another site. See Figure 22.5 for Bud’s Organization Properties page.
FIGURE 22.5. Organization Properties page for a mailbox.
The tab for Phone/Notes is used to enter additional information for Bud, such as his phone, beeper, fax, and cellular phone numbers, and any additional notes for this mailbox. These properties can be very useful for an organization as a replacement for
company phone lists. Because Bud has requested that his cellular and beeper numbers not be published, we will leave those fields blank. See Figure 22.6 for Bud’s Phone/Notes Properties page.
FIGURE 22.6. Phone/Notes Properties page for a mailbox.
If you checked the "Show Permissions" box in the Options selection from the Tools menu, you will see a Permissions tab for his mailbox. From this page, you can see that the NT account for Bud already has user permissions to his mailbox, and
other accounts can administrate his mailbox. Here, you can assign other accounts to have Send as or User permissions, but this should be used with caution. If you want another user to be able to send on Bud’s behalf or read his mail, use the Delivery
Options tab. See Figure 22.7 for an example of the Permissions page for Bud’s mailbox.
FIGURE 22.7. Permissions page for a mailbox.
Next, you click on the page titled Distribution Lists to add Bud to the lists he requires. From this page, you can only add Bud to existing distribution lists, so make sure to create them before adding any mailboxes. It is probably easier to add the
users to distribution lists as they are created, but this will enable you to add new users to multiple pre-existing lists. See Figure 22.8 for an example of the lists of which Bud will be a member.
FIGURE 22.8. Distribution Lists Properties page for a mailbox.
The Delivery Restrictions page is normally not used for individual mailboxes, unless that mailbox needs to interact only with certain recipients, such as for an application. Because Bud does not need any restrictions on his mailbox, you accept the
defaults for this page. This Properties page might also be used to restrict who can send mail to the CEO or CFO so it can be screened through their assistant’s mailboxes. See Figure 22.9 for the Delivery Restrictions page for Bud's mailbox.
FIGURE 22.9. Delivery Restrictions page for a mailbox.
The Delivery Options page is going to be helpful for Bud, because it will enable his assistant to attend to his mail while he is on the road. You click on the Modify button to select his assistant’s mailbox for Send on Behalf of permission. This
enables his assistant to send mail for Bud—for example, if he wants to send a message to his team but cannot get to his laptop until the evening. This example does not use the alternate recipient option for Bud’s mailbox, but it would be useful
if he wanted his assistant to get copies of all the mail sent to him. See Figure 22.10 for the Delivery Options page for Bud’s mailbox.
FIGURE 22.10. Delivery Options page for a mailbox.
The Security tab is only available if you are using the Key Server service for advanced security, and it is covered in the section "Key Management Server" in more detail. The Custom Attributes page is only useful if you have decided to add
additional data fields to the Exchange schema. This could contain company-specific information and is customized under the DS site Configuration Custom Properties page. CRC Enterprises has decided to use a few custom attributes to contain employee-specific
data to enable cross-referencing to the human resources database. Figure 22.11 is an example of the Custom attributes for Bud’s mailbox.
FIGURE 22.11. Custom Attributes page for a mailbox.
The custom attribute fields can be modified only by the Exchange service account and the account that was used for the exchange install. For this reason, install Exchange Server from an account named E-Mail Administrator or something equivalent, and never remove that account. Even though this can be seen as a limitation, it is useful in keeping the custom attribute fields the same throughout the organization. The custom attributes should not be different at each site, because it will confuse users with information that does not seem to belong in a certain custom field.
The Advanced Properties page is very useful in controlling various mailbox capabilities. From here, you can set limits on the size of messages this mailbox can send or receive, as well as override the amount of storage space allocated to this mailbox.
You can also control whether this account is replicated to other locations by trust level, or hide the recipient from the address book. Because Bud will be a remote user that will only access his mailbox a few times a week, you increase the amount of space
he has on the server and add that he is a remote user to the Administrative Note field. See Figure 22.12 for the Advanced Properties page for Bud’s Mailbox.
FIGURE 22.12. Advanced Properties page for a user mailbox.
Since you are finished entering the information for Bud’s mailbox, click the OK button to save the information and return to the contents window. As you are going through the various tabs when creating a user mailbox, click on the Apply button to
save the current data before you go to the next tab. Bud’s new mailbox is now ready for him to use, and it instantly showed up on the global address list for the local site. The account information will be replicated to all the other sites based on
the replication interval configured at the site, so others in the organization will be able to mail to him as soon as possible. The information in his mailbox can be modified by this method at any time by opening the properties for his mailbox. This can be
done by double-clicking on his mailbox or clicking once on his mailbox and pressing the Alt+Enter keys. This concludes this method for creating a new user account.
This method differs in that you are on a workstation that has the NT Server administrative tools and the Exchange administration program installed. You also have account administrator rights, and you are responsible for creating his NT user account.
This procedure is helpful for those administrators already familiar with adding NT user accounts with the user manager, and who might forget to create a mailbox for that user. Remember to install the Exchange administrative program on all machines that
will be used for administration, and configure the application options the same. This installs the application extension, MAILUMX.DLL, which adds Exchange functionality to the User Manager for Domains application.
To begin, open the User Manager for Domains application and add an NT user account for Bud with the information required for your company. When you click on the Add button, you are prompted for the exchange server to connect to and then see the same
Mailbox General Properties page, as in Figure 22.4. From here, use the same procedures outlined previously to enter information for Bud’s new mailbox. You will also notice in Figure 22.13 that a new pull-down menu item, Exchange, is available in the
user manager interface. This can be used to modify the properties for a mailbox associated with the NT account you have selected.
FIGURE 22.13. Creating a mailbox from the User Manager for Domains.
In both of the previous methods, you can delete any user account or associated mailbox from the application interface. If you delete an NT user account from User Manager for Domains, you are prompted to also remove the associated mailbox. If you set the
option in the Exchange administration program for removing NT accounts when mailboxes are deleted, you are also prompted for removal of the NT user account when deleting mailboxes. As you can see from the previous examples, these two methods are not useful
if you have a large number of users that need new mailboxes.
To create, modify, or delete a large number of users at an exchange site, you will use the directory import feature found on the Tools menu. This method works with standard comma-delimited files that can be created from many sources, such as your human
resources database or one of the Exchange source extraction tools. To create a sample of this type of file, export a few users into an export file from the administrator program. A list of all the key words used in the header of the file is located in the
on-line help.
For this example, assume that Bud is a member of a large group of new employees that were just hired, and they are currently going through an orientation training class. You need to create accounts and mailboxes for over thirty individuals, making sure
that all required fields are filled in for each user. You get a comma-delimited file with information on each of the new employees from the human resources department, but it does not contain data for all the fields you need. The following procedure can be
used to get the file imported into Exchange:
FIGURE 22.14. Directory Import dialog box.
Because you received a very well-populated file from HR, and you used a template account with the other default values filled in, you are now ready to leave early for home with the knowledge that the new users will be able to access their e-mail
tomorrow. You can also follow these procedures to modify existing fields within the directory database or delete accounts in batch mode. A good example of modifying current accounts is using this procedure to add values to the Secondary Proxy Addresses
field to create aliases for SMTP mail delivery.
If you use Microsoft Excel to manipulate your import and export files, beware of the 256-character limitation for any field. If any of your fields have more than 256 characters (the E-Mail Addresses field, for example), use another program to edit it. Microsoft access or many third-party editors are better choices because they will not have the same limitation.
In the previous example, you could have also created the import file from other sources. Your current messaging system or NOS already has lots of data that can be used to create Exchange mailboxes. The Exchange administrative program has extractors on
the Tools menu to build import files from current NT domains or NetWare servers. The migration directory on the Exchange Server CD also contains source extractors for the most popular messaging systems. You can also create your own source extractors to get
information out of your current messaging system, or create the import file from databases that contain the information you need.
The Exchange Server might be the most modified directory object in the schema, after user mailboxes and distribution lists. Servers consist of a set of core services that can be individually configured to override any settings for the site. Each server
in the site has the following core components:
This section discusses the options available for managing the services and resources available at each Exchange Server. Most of the configuration of the services for each server is done from the Exchange administration program, but management of the
services is done through either the server manager or the services icon in Control Panel. Server administration can be broken down into four areas:
The other two areas for administration of Exchange Servers, the directory service and message transfer agents, are discussed later in this chapter.
Because Exchange Server runs exclusively on the Windows NT Server platform, it is composed of various services. Each installation of Exchange Server has the same services installed, even if they are not configured or running on that machine. These
services store many of their runtime parameters in the Windows NT registry, and they store any directory-related information in the directory database. See Figure 22.15 for the services installed on every Exchange Server.
FIGURE 22.15. Exchange Server services.
These services are managed normally from the server manager application, but they can also be accessed through the services icon in control panel. Each service is configured to logon using the service account defined in the server installation. The
default startup parameters are for the system attendant, information store, MTA, and directory service to start automatically, with the other services defaulting to manual startup. As you configure each of the services, you need to change the default
startup option to allow the service to start automatically, such as the IMC or Directory Replication services. Always check the Event Viewer for messages from these services, depending on the diagnostic level specified for each service.
Some of the services have keys in the Windows NT registry that control the behavior of that service. Modification of these keys should be done with extreme caution, and you should create a emergency recovery disk before you modify anything in the
registry. Many of these key values can affect the performance of the services or change the behavior of certain features. Normally, you add or modify these registry values only if instructed by product support or a well-written tech note. You might want to
take some time to familiarize yourself with the various values, and they can be found at HKLM\SYSTEM\CurrentControlSet\Services\MSExchange*, where * represents a specific service name.
The server link and service monitors are very powerful proactive troubleshooting tools; every Exchange Server should have at least one of each configured for each server. The Monitors container can be found under the configuration container for a site,
and it can be used to monitor one or more servers within that site. You need a machine with the Exchange administration program installed to run the monitors from, and it should be running at all times.
The following procedure sets up a link monitor at a site:
The following procedure can be used to set up a server monitor for a site:
For each of the monitors you create, give them descriptive directory names that describe what they are monitoring. Create only one or two server monitors in a site, depending on the site topology and network bandwidth available. It is also a good
practice to create one link monitor for each link you want to test, to give you more flexibility in the notification process. Although you can overlap monitors from various sites to monitor each other, this can become confusing as your system expands.
Each server within a site has a properties page that can be accessed by clicking on the server and then selecting the Properties option from the File menu (or by pressing Alt+Enter). The properties for each server are Services, Locales, Database Paths,
IS Maintenance, and Diagnostic Logging. These options are specific to each server and do not have corresponding global site equivalents.
The server Services page lists all the services running on that server and which of those services will be monitored through a server monitor. Any services installed on the server can be added to the list of monitored services, but you should limit your
selections to services that are pertinent to Exchange. You might want to add a service such as RAS or RPC to the list of services to monitor, but would not want a service such as "DDE Server" to be monitored.
The Locales page controls how date, currency, and time values are displayed for the various international languages. Other system settings, such as sort order and language support, are affected by the locales installed. Locales should be installed and
configured for all languages the client programs will be using. For instance, if your server will be servicing both US English and Spanish clients, both locales should be installed and configured.
The Database Paths Properties page lists the locations of the various databases and transaction logs for the Exchange components. Although this page enables you to make changes to the locations, you should always use the Exchange Optimizer application
to make such a change. If you feel real adventurous and have a confident backup of your system, stop all services before making any changes here.
The IS Maintenance page enables you to determine at what times database maintenance functions will be executed. Because IS maintenance slows systems performance, it should be scheduled for a time when no users or backup processes will be using the
server. If you are a 24-hour shop, select an appropriate time outside your backup window that the system can run a little slower. Do make sure that this is configured to run at least once daily, or your Information Stores may get "dirty" over
time.
The Diagnostics Logging page for the server enables you to set logging levels for all the components that make up Exchange Server. These logging values can be found on the properties page for each of the individual components, but this is the one place
where you can find them all together. If you are troubleshooting the system, this is the first place you should go to control the amount of detail you will see in the Event Viewer.
Each Exchange Server has a private message store and a public message store, regardless of the resources configured for the server. Many of the options available for configuration of these components have site-based configuration properties, such as the
message store limits and public folder configurations. These properties pages enable further granularity in configuration of these values for each server. This enables you to set up servers differently, such as a dedicated public folder server or an entire
server for the finance group.
The private message store properties control the user’s private mailbox configurations and enable administrators to easily view the current resource usage at a particular server. Storage limits can be established to issue warnings to users when
they reach a certain mailbox size, and prohibit that users send capabilities when they reach a larger value. These settings can be overridden at the individual mailbox level, and override the values established at the site level.
The public folder server page enables an administrator to specify where all the top-level public folders are created for users on this server, enabling the separation of the public and private stores to different servers. This is useful for servers that
have a large number of users and need to optimize public folder access for the site.
The Logon and Mailbox Resources Properties pages are useful in seeing how many users are connected to the server in real time and how much space each of the are occupying on the server. This is helpful for troubleshooting user connection problems,
because the logon page can be customized for the columns that are displayed. You will probably go to the Mailbox Resources page just before cleaning any user mailboxes to find out who your "worst" users are. These pages can be useful to your
tuning process, because it gives real-time data.
The server and mailboxes are the most frequently modified directory objects, but the connectors and MTAs are the objects that most frequently modify other objects. The MTAs are the backbone of message transfer within the site, and between sites. The
connectors are the "translators" that move messages between Exchange and external systems, or between configured Exchange sites. These components are very dynamic in nature, constantly monitoring the routing tables and message delivery statistics
to guarantee the shortest message transfer times.
The connector options available within exchange are designed to connect sites for message transfer and directory replication. The capability of performing directory replication between sites and transferring exchange native messages is what separates
connectors from standard gateways. Each of the connectors relies on messaging transports to support its services, as well as an MTA to control the flow of those messages. This section describes the administrative interfaces to the various transports, MTAs,
and connectors.
Because the Message Transfer Agents are used in intrasite and external communications, there are many places to configure the various parameters that control how they operate. Each MTA has a properties page to control messaging parameters for that
individual MTA instance. Each server has a properties page that controls parameters for the MTAs running on that server. Each Exchange site has configuration parameters that will affect any of the MTAs within that site.
The site MTA configuration properties are obtained through the MTA Site Configuration object in the configuration container within a site. The general page has properties for setting enabling message tracking for the site. If you enable message
tracking, the MTAs for the site record every message they transfer in the daily tracking logs, enabling administrators to track messages within the site. See Figure 22.16 for an example of the General Properties page for the MTA Site Configuration object.
FIGURE 22.16. MTA Site Configuration General Properties page.
The Messaging Defaults page of the MTA Site Configuration object control the parameters for messaging time-outs for the site. These values include the Return To Sender (RTS) parameters that control how long the MTA tries to send messages. There are also
transport-specific values for connection retry and transfer time-outs, to enable some tuning of message transfer within the site. See Figure 22.17 for an example of the Messaging Defaults Properties page for the MTA Site configuration.
FIGURE 22.17. Messaging Defaults parameters page for MTA Site Configuration.
The Server MTA Properties pages control how the MTA on a specific server operates. There is a General, Queues, and Diagnostics Logging Properties page for this object. The General Properties page enables the administrator to set the MTA name, password,
and maximum message size when the routing tables are calculated. See Figure 22.18 for the parameters available on the General Properties page.
FIGURE 22.18. General Properties page for the Server MTA.
The MTA Queues Properties page is a valuable tool for troubleshooting message delivery. If you suspect that messages are not getting out of the site, check here to make sure the messages are not still in the MTA queues. From the Queues Properties page,
you can view detailed information on messages, change the priority of any message, and delete messages destined for any external site or connector. See Figure 22.19 for an example of the Queues Properties page for a server’s MTA. The Diagnostics
Logging Properties page is a common page for any object and controls the detail level of MTA message logging.
FIGURE 22.19. Server MTA Queues Properties page.
Each MTA for a connector will have properties pages specific to the type of message transport for that connector. These administrative pages are described with the associated connector because each has properties specific to the connector.
Exchange has four message transport connectors and one directory transport connector available in the enterprise edition of the server. The message transport connectors can be used to connect exchange sites or link to other messaging systems. The
directory transport connector is used exclusively for replicating directory schema information between connected sites. The following are the four message transport connectors:
The MS-Mail connector is discussed in Chapter 24, "Interfacing with Other Mail Systems," because it is related to interfacing with MS-Mail-based systems. The MS-Mail connector cannot be used to connect two exchange
sites, as is customary with the limitations of the MS-Mail protocols.
The Site Connector is created by choosing the File, New Other, Site Connector option. You will be prompted for the name of the site you want to connect to, and the name of any server in that site. You must have rights to the servers in the other site to
enable you to configure both sites during the setup. Once created, the Site Connector has four Properties pages for General, Target Servers, Address Space, and Override options.
The General Properties page has the display name and directory name of the Site Connector, which defaults to Site Connector (site name). The target site for this connector is displayed for read-only, but you can modify the cost associated for this
connection. You can also specify the messaging bridgehead server in the local site. If you use a local messaging bridgehead server, any messages destined for the remote site will be sent only by the server you name as the bridgehead, which can be helpful
in controlling message traffic. See Figure 22.20 for an example of the General Properties page for the Site Connector.
FIGURE 22.20. General Properties page for the Site Connector.
The Target Servers Properties page is used to specify which servers in the remote site can be connected to for message delivery. The server you specified when you set up the Site Connector will already be in the Target Servers list with a cost of one.
Other servers in the site can be added to the Target Servers list by clicking on the server name and clicking on the Add button. See Figure 22.21 for an example of the Target Servers Properties page.
FIGURE 22.21. Target Servers Properties page for the Site Connector.
The Address Space Properties page is used to specify address spaces with costs for message routing to the remote site. The X.400 address space is automatically entered when you configure the Site Connector, and is assigned a cost of one. When entering
an address space, you need to enter only enough of the address to distinguish which messages will be routed to the remote site. The Address Space Properties page is common to all the connectors, so Figure 22.22 is a standard properties page. The override
page is used to specify an NT user account to connect to the other site, and is available in other connectors.
FIGURE 22.22. Address Space Properties page for the Site Connector.
The Dynamic RAS Connector is created by choosing the File, New Other, Dynamic RAS Connector selection. Before you create a Dynamic RAS Connector, you must create a RAS transport stack. You will be prompted for the name of a server in the remote site,
the remote site name, and the RAS phone book entry to use for connection. You should set up and test the RAS phone book entry before setting up this connector, or use the RAS override feature. It is also advisable to set a maximum message size to keep
extremely large messages from tying up the connector. See Figure 22.23 for an example of the General Properties page for the RAS Connector.
FIGURE 22.23. General Properties page for the RAS Connector.
The Permissions and Schedule Properties pages are the same as the others used throughout the other connectors. The Permissions page controls what accounts have associated permissions to the RAS Connector. The Schedule Properties page is used to specify
at what times the RAS Connector will make connections, and it can be set for hourly or fifteen-minute intervals. The RAS override page can be used to specify the NT security information and phone numbers to override any values in the RAS phone book entry.
See Figure 22.24 for the RAS Override Properties page. The MTA Override Properties page is the same as depicted in Figure 22.17.
FIGURE 22.24. RAS Override Properties page.
The Delivery Restrictions Properties page for the RAS Connector is the same as in Figure 22.9., and it is not normally used. The Address Space page is used to create routes for message types and associate the appropriate costs. For the RAS Connector,
use high costs unless it is the only connection to a site. The Address Space page is the same as depicted in Figure 22.22. The Connected Sites page is common to the RAS, X.400, and Internet Mail Connector, and is used to ensure that directory replication
can take place (see Figure 22.25).
FIGURE 22.25. Common Connected Sites Properties page.
Before you can create an X.400 Connector, you must first create an MTA transport stack. To create an MTA transport stack, select File, New Other, MTA Transport Stack and select the appropriate type. You can create MTA transport stacks on X.25, TP4, and
TCP/IP, but normally you use TCP/IP. You can optionally also configure the OSI TSP information, if needed for legacy system connections. See Figure 22.26 for an example of the General Properties page for an MTA transport stack.
FIGURE 22.26. General Properties page for an MTA transport stack.
Once you configure the appropriate MTA transport stack, you can create an X.400 Connector by selecting File, New Other, X.400 Connector. You will be prompted for the MTA transport stack to use. Start at the General Properties page, which has information
on the display and directory name of the connector, the remote MTA name and password, and an option for word-wrap and remote client MAPI support. See Figure 22.27 for an example of the General Properties page for the X.400 Connector.
FIGURE 22.27. General Properties page for the X.400 Connector.
The Schedule Properties page is used to specify the times the X.400 Connector can make connections to the remote MTA, and it allows a remote initiated transfer if both MTAs are configured for the two-way alternate option. The Stack Properties page is
similar to the MTA Transport Stack general page, except that you must specify the address or name of the remote MTA. This differs depending on the MTA transport stack, but will normally be the TCP/IP address of the machine that is running the remote MTA.
The Override, Connected Sites, Address Space, and Delivery Restrictions Properties pages are identical to those of previous examples, except that the Override page has the capability of specifying a local MTA name and password. You should refer to
previous figures for examples of these pages, because they are configured in the same manner.
The Advanced Properties page for the X.400 Connector has the most critical configuration values for connecting to legacy systems. It enables you to specify the MTA conformance mode, the X.400 link options, message size limitations, the X.400 bodypart to
use for message text, and whether to use GDI information from site addressing or specific values. If you are using the X.400 Connector to connect two exchange sites, you will not need to modify these values. If you are connecting to an X.400 legacy system,
you will probably have to modify these values. See Figure 22.28 for an example of the Advanced Properties page for the X.400 Connector.
FIGURE 22.28. Advanced Properties page for the X.400 Connector.
The Internet Mail Connector already exists in the connections container for the site, and is configured by opening its properties. The first time you open the properties for the IMC, you will see the Internet Mail Properties page as seen in Figure
22.29. Before you can continue, you must select the mailbox to send notifications to by clicking on the Notifications button. From this page you also select the default encoding method for message content and the interoperability options, as seen in Figure
22.30. You can also specify the message content and interoperability options per e-mail domain by clicking on the E-Mail domain button. This page also has the option of changing the character set translations for MIME and non-MIME attachments.
Set the default message content to UUENCODE with the rich-text option in interoperability set to Never. This enables your system to interoperate with the majority of systems on the Internet, creating less attachment-related problems. You can put e-mail domains that use MIME or that are rich-text-capable in the exception list by specifying Options by e-mail domain. When your list in the e-mail domain gets large, reverse the defaults to make MIME and rich-text the default content types.
FIGURE 22.29. Internet Mail Properties page for the IMC.
FIGURE 22.30. Interoperability options for message transfer.
The Connections Properties page enables you to set the IMC transfer mode to handle either inbound, outbound, inbound and outbound, or the "none" transfer mode. This enables you to load balance with multiple IMCs for your enterprise and control
where messages flow to your Internet connections. This page also defines whether the IMC uses DNS or forwards all mail to another sendmail host. This is useful if you have a firewall or an existing UNIX sendmail server that needs to handle your message
transfer. From this page, you can also specify whether mail is accepted or rejected by the host, the connector retry interval, and message time-out values. See Figure 22.31 for an example of the Connections Properties page for the IMC.
FIGURE 22.31. Connections Properties page for the Internet Mail Connector.
The pages for Connected Sites, Address Space, Delivery Restrictions, Diagnostic Logging, General, and Queues are similar to the same pages in the other connectors. Because these have already been described and have appropriate figures, please refer to
those examples for information on how the IMC will use the similar properties. The Advanced Properties page enables you to set the message parameters for delivery, the maximum transfer times for different priorities of messages, and the message transfer
quota size. You can see these parameters in Figure 22.32. The MIME Types Properties page is used to add new MIME content types and extensions to enable proper extension conversion. Refer to Figure 22.33 for an example of the MIME Types Properties page.
FIGURE 22.32. Advanced Properties page for the Internet Mail Connector.
FIGURE 22.33. MIME types Properties page for the Internet Mail Connector.
The MTA relies on the Gateway Address Resolution Table (GWART) to determine the least cost for message routing and the connectors that provide routing for appropriate name spaces. The accuracy of the GWART is dependent on the data from the different
connectors and replicated data from other sites. The Directory Replication Connector is responsible for getting that data from other sites to make sure that the MTAs and users have accurate information. The Knowledge Consistency Checker (KCC) is the
process that detects new sites and configures replication links to those new sites. This enables one configured directory replication link to gather information about an entire organization without additional administrator intervention.
Setting up a Replication Connector is a simple process, once you have a connector configured to the other site. Make sure to have the Connected Sites page properly configured at each site to facilitate the directory replication. Test the link first by
sending a test message to make sure the directory replication messages will make it through.
To set up a Directory Replication Connector, select the File pull-down menu, then New other, then Directory Replication Connector. You will then be prompted to select which site to set this Replication Connector to. Remember that you only need to
replicate to another site replication bridgehead server that has other information for the entire site. The KCC will create replication links to the other sites automatically. Before you set up how your directory is replicated, your planning stage should
have identified whether you will use the hub or the cascading routing topology. This will determine which connectors need to have Directory Replication Connector created.
As you can see the connectors have numerous properties for configuration, but they are very straightforward in the information needed to get them running. As you spend time configuring and managing the connectors within Exchange, you will get more
familiar with the locations of the properties you use most. Pretty soon, administration of Exchange Server components will become second nature, and you will wonder how you ever managed your messaging system without them. With such a strong set of
administrative tools, the extensibility of the system can only get better in future releases.
Microsoft Exchange Server is the e-mail system with integrated Groupware, as Microsoft explains the product. The administration of the Groupware functions built into Exchange involves both the client and administrator programs. Public folders are
created and managed from the client desktop, and the administration program is used to replicate the folders throughout the enterprise. Electronic forms are only as good as the ability of users to access them, so you should create forms libraries to use
the most common forms. Applications are created and modified within the Electronic Forms designer and placed within public folders through the client application. This section describes the methods used to administrate public folders, electronic forms, and
applications.
Public folders are created from the client interface by simply selecting the New Folder option from the File menu when selecting the place you want the folder created. They can also be created by copying an existing folder or by using the folder design
cue cards available from the Application Design option from the Tools menu. Folders can be created at the root folder level for the organization, or nested within current folders. Once a folder is created at the client, the properties of that folder need
to be set to allow proper access and functionality. This involves setting rules for processing messages, setting views for organizing the display fields, setting access privileges, and adding custom forms. The folder properties can be set using the folder
design dialog box as pictured in Figure 22.34.
FIGURE 22.34. Folder design dialog box.
To set the appropriate permissions on the folder from the client interface, the folder owner can use the dialog box in Figure 22.35 to set the user roles and permissions in Table 22.1.
| Role | Permissions |
| Owner | Read items, create items, create subfolders, folder owner, folder contact, edit items (All), delete items (All) |
| Publishing Author | Read items, create items, create subfolders, edit items (Own), delete items (Own) |
| Publishing Editor | Read items, create items, create subfolders, edit items (All), delete items (All) |
| Author | Read items, create items, edit items (Own), delete items (Own) |
| Reviewer | Read items, edit items (None), delete items (None) |
| Contributor | create items, edit items (None), delete items (None) |
| None | Edit items (None), delete items (None) |
FIGURE 22.35. Folder roles and permissions.
To configure public folders from the Exchange administrator program, select the folder from the organization’s public folders container and bring up the folder’s properties. This will bring up pages for General, Replicas, Folder Replication
Status, Replication Schedule, Permissions, and Advanced. These pages are used to manage where the public folders are located and what servers they are replicated to. The General Properties page specifically enables you to change the folder’s name, the
alias name, age limits for replicas, and client permissions.
The Replicas Properties page enables the administrator to select which servers have copies of the folder. These servers can be in the same site or located in connected sites. As an administrator, you should take the time to map where certain folders are
replicated and how often they are updated. Folder replication can have a large impact on network bandwidth, so try to estimate the amount of data that will change for a folder before deciding where to replicate it. Figure 22.36 shows the Replicas
Properties page.
FIGURE 22.36. Replicas Properties page for a public folder.
The folder replication status page and the folder replication schedule page are used to monitor and control how the selected folder will replicate. The schedule will control how often the public message store will check this folder for updates and
defaults to the schedule set for the public message store for the server. To verify that the folder has been replicated, view the folder replication status page and you will see the status of the replicas of this folder.
The permissions page for the selected folder will only control the schema security access and has no effect on the user’s permissions on the folder. To set the specific folder properties, click on the Client Permissions button located on the
general page for the folder. The Advanced tab is used to control the trust level, replication message importance, storage limits, and whether the folder is hidden from the address book. Figure 22.37 is an example of the Advanced Properties page for the
public folder.
FIGURE 22.37. Advanced public folder Properties page.
A very important public folder configuration parameter is located in the Information Store Site Configuration Properties page, and it deals with public folder affinity. Public folder affinity is where values are assigned to replicas in other sites to
control which replicas of a public folder the local site clients attach to. Sites that do not have affinity will not have any connection attempts for folders from users in this site. When a user attempts to connect to a public folder that is not found in
the local site, the connected sites with affinity are searched from the lowest cost to the highest until the folder is found or the list is exhausted. Public folder affinity is useful to guarantee that users will still be able to get to folders if the
local public folder is down.
Exchange has a very nontraditional definition of an application, because it is made up of public folders and the electronic forms within them. Public folders have already been defined, but electronic forms are a somewhat different animal. Forms consist
of one or more fields that are used to submit and view information in various formats. Forms are associated with a public or private folder, and users compose new forms to enter information into the fields. The electronic forms designer is used to create
forms and place them within folders in the organization. An example of the Electronic Forms Designer application interface is seen in Figure 22.38.
FIGURE 22.38. Electronic Forms Designer user interface.
Forms are based on the Visual Basic 4.0 (VB4.0) language, and they can be modified outside the forms designer if needed. Once a form is created, it should be placed within a forms library. There are three types of forms libraries:
Organizational forms libraries are created from the Tools menu and are special folders that can be replicated throughout the entire organization. Public and private libraries are the folders that are created from the client program. Forms are installed
in the appropriate library with the Manage Forms button that is available from the client program and the Electronic Forms Designer. Forms are copied to the appropriate library and then made available to the users through the Compose menu or by submitting
messages to that folder. Figure 22.39 is an example of the Forms Manager dialog box.
Figure 22.39. Dialog box for managing forms.
The organizational forms libraries can be used for many of your send-type forms. Then you can have consistent forms access to users throughout the organization. One such use would be for Human Resources forms, such as vacation requests or time sheets. Make sure that any forms that are installed in an organizational library are the same as any forms installed within folders, or you may have inconsistent forms when users at different sites use them.
Disaster recovery is made possible through the regular backup of the Exchange directory service and information stores with the windows NT backup program. Exchange installs a new version of NTBACKUP.EXE that is aware of the exchange services and is able
to back up and restore these services. See Figure 22.40 for an example of the interface used to backup the Exchange resources.
FIGURE 22.40. Windows NT backup interface to Exchange resources.
Other third-party backup programs also have the capability of interfacing with Exchange and backing up the directories and information stores on the servers. Regular nightly backup is needed to assure that you can restore in the case of a catastrophic
failure. If you need to restore any part of the system, both the DS and the IS should be restored and a consistency check should be run. The DS/IS consistency check can be performed from the specific server’s properties page by clicking on the
appropriate button.
Because Exchange supports restoration only of the entire DS or IS, you need a separate restoration server to be able to retrieve individual mailboxes or folders. This server should have only a copy of Exchange installed and should not be configured to
participate in any of your sites within the organization. From this server, you can restore the last backup and then extract the user’s mailbox or public folder data to be copied to the production server. Future versions of exchange should enable the
restoration of individual mailboxes, folders, and directory information.
By default, the Exchange backup process is not capable of performing incremental or differential backups, because Exchange Server defaults to having circular logging enabled. This does not enable the logs transactions to be backed up before they are flushed. To disable circular logging, open the properties page for the server on which you want to enable incremental backups. Then uncheck the boxes for circular logging on the DS and the IS. This causes the database logs not to be flushed until the backup process runs, and it should give better performance for high-volume servers. Be sure to disable circular logging when the users are not on the system, because it will stop the directory service and information stores while the change is being made.
Troubleshooting a problem with Exchange Server is different for each situation, and this section is only an overview of the tools at your disposal. When looking for an answer to your problem, be sure to use all the resources at your disposal. Many
answers to common questions can be bound in Microsoft Technet, which is available on the Microsoft Web site and in CD-ROM format. The Exchange online books are also helpful in finding answers to common configuration and how-to type questions.
When you first determine that you are having a problem with Exchange Server, such as the information store service not starting, try to isolate the nature of the problem with the Event Viewer. All error messages for the Exchange services are placed in
the application event log and may have corresponding messages in the system log. The error messages are fairly descriptive and can help point you in the right direction. You may want to increase the level of diagnostics logging for a particular component
to give you additional information, and this is available on the Diagnostics Logging Properties page for the component in question.
Always try to stop and restart the service you are having problems with from the service control manager in Control Panel or Server Manager. The services have built-in diagnostic capabilities, and restarting the service will initiate these diagnostic
processes. If you are still not successful after trying these steps, take a full system backup of the server. You can then restore to the last-known-good database or configuration. This will correct the majority of system problems, but your specific
problem may warrant a call to product support services or a solution provider. Always check with the knowledge base on the Web site or Technet, because you probably do not want to pull your hair out over a problem that someone else has already found and
solved.
Secure access to messaging system resources is a top priority for any organization, and Exchange leverages the security built into Windows NT Server. Each object within the directory has both inherited and specific permissions, enabling granularity of
security throughout the system. Securing and encrypting messages is also available through the use of the Key Manager service.
The Exchange directory databases and information stores have pointers to Windows NT accounts and groups for establishing who has access to what objects. There are three main containers in the hierarchy from which lower objects inherit their permissions:
the Organization, the Site, and the configuration container. You can override or add additional permissions to any object from the Permissions Properties page for any object, assuming you have enabled this option from the Options selection under the Tools
menu. These permissions are used to grant or deny access to any directory object.
By default, the account used to install exchange and the service account have permissions admin level permissions to all objects to facilitate Exchange administration. Users get user level permissions to their mailboxes and any public folders they
create, and are able to assign the "send on behalf" permission to other users. The "send as" permission can be granted only from the administrator program, and it should be used with caution. Public folders assign access permissions to
user mailboxes, which then map to NT accounts. Refer to Figure 22.7 for an example of a Permissions Properties page for a directory object.
To enhance the security of your system, restrict the logon parameters for the Exchange service account. In User manager for domains, specify the allowed locations for logon under the profile option by entering each server on which this service runs. Use the user rights policy to restrict the capability of the service account logging on interactively, so no person can use the account from the NT user interface.
Encryption and digital signatures for messages are provided by the Key Management Server included with Exchange. This service is installed separately, and great care should be taken to keep the administration password safe for this service. Once
installed, you can use the Advanced Security Properties page for any user mailbox. This creates a security token for that user and a somewhat long and cumbersome password that must be given to the user in a secure manner. I suggest that you use
voice mail or an equivalent to get users their temporary passwords. They can now enable Advanced Security from the Tools menu Options selection in the client by clicking on the setup button and supplying the temporary password you gave to them.
Messages then can be encrypted with standard RSA encoding methods such as CAST-64, DES, or CAST-40 within North America. International versions differ in their encoding methods, governed by laws regarding encryption to other countries. Messages then can
be encrypted and signed to other users that are set up for advanced security. If users attempt to send secure messages to recipients that do not have advanced security enabled, they have the option of sending them unsecured or canceling the message.
Beyond the administration and performance optimizer programs, Exchange includes additional utilities for troubleshooting and performance monitoring. These utilities are installed with the server by default, but do not necessarily have icons created to
them.
In the Exchange Server program group created during phase three of the installation process, you will see many performance monitor icons. These are performance monitor charts that enable you to monitor different parts of the Exchange messaging system.
There are charts for server health, message queues, server load, number of logged-on users, and various connector status information. These are very helpful tools in analyzing and troubleshooting Exchange Server. You should have a machine running most of
these charts somewhere that anyone can check them, because they can be proactive indicators of problems, such as connectors being down or server overload.
The Exchange Server bin directory, \exchsrvr\bin, also contains a few applications that can be used for troubleshooting and testing. The following are the various programs and their usage:
Although this is not a complete list of the utilities available to help you support and troubleshoot an Exchange Server, these will be very useful for the majority of situations you might be in. There are other utilities, such as client setup editor and
loadsim included with Exchange; They are discussed in Chapters 23, "Mail Clients," and 25, "Exchange Server Performance Tuning and Scaling," respectively. I also suggest that you get a copy of the Windows NT Resource Kit, because it has
many utilities, such as PVIEWER.EXE for monitoring processes, that will assist you in diagnosing problems with Exchange. As you already know, utilities are only as good as the vendor that wrote them, and Microsoft has done an adequate job of including many
helpful utilities for your time of need. There is a large market for third-party utilities to fill in some of the gaps, so check out the Exchange newsgroups and shareware FTP sites for any additional utilities to add to your.
Because an organization’s messaging system is in constant flux, the administrative features must be able to manage this "structured chaos." Exchange Server has a robust administration client that gives you a single view of your entire
organization’s messaging resources. Managing the objects and resources for sites and servers is made easier with the hierarchical view of the Exchange directory, with properties pages for each object. Administrators just want to be able to do their
job quickly and keep their user’s messaging flowing to support business processes.
This chapter took you through a guided tour of the administration program used in Exchange and detailed the setup of the various components that make up the system. It explored administration of mailboxes, servers, connectors, MTAs, public folders, and
electronic forms and also outlined some disaster recovery options with basic troubleshooting procedures. Security options and other utilities were discussed, with an emphasis being put on how they are used.
The next chapter is on the Exchange client’s installation, support, and troubleshooting. Because this is the part you users will interface with daily, it takes special note of the features that will keep your "customers" happy. The client chapter is useful to both end-users and support professionals, because it covers topics important to both. It also assumes that you have an Exchange Server configured and operational, with all appropriate connectors and messaging components.
