Whether you’re using Microsoft Exchange Server 2003 for the first time or honing your skills, you’ll need to master many key concepts to work effectively with Exchange Server. You’ll need to know the following:
How the Exchange environment is organized
How information is stored in Exchange Server
Which Microsoft Windows processes are used with Exchange Server
How Exchange Server works
You’ll also need to know how to use the Exchange System Manager. These topics are all covered in this chapter.
Exchange Server combines a fairly complex administrative model with an equally complex messaging architecture. Understanding how the administrative model and the messaging architecture are used and integrated isn’t easy, so let’s begin with a look at how Exchange environments are organized.
The root of an Exchange environment is an organization. It’s the starting point for the Exchange hierarchy. The boundaries of the Exchange organization define the boundaries of your Exchange environment. In other words, the Exchange information store doesn’t provide information on users or servers outside the organization—unless you specifically tell Exchange Server about these entities.
An Exchange organization can serve several offices and business functions. Typically, each office or business function that it supports has its own server that runs Exchange Server. For example, if your company has offices in Seattle, Portland, and San Francisco, you’ll probably have at least one server running Exchange Server at each location. To serve a large user base or high-volume messaging needs, you might also have separate servers providing Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP3), Hypertext Transfer Protocol (HTTP), and other messaging services. All these servers can be a part of the same Exchange organization.
When you installed Exchange Server, you were given the opportunity to join an existing organization or create a new organization. The organization name you assign or join is permanently associated with the Exchange server. Once designated, you cannot change it. As Figure 4-1 shows, you can view the current organization name in Exchange System Manager. Here, the organization name is First Organization.
Figure 4-1. The organization is the root of the Exchange environment, and you view it in Exchange System Manager.
Under the organization node you’ll find the key components that make up the organization. These components include the following:
Global Settings
Recipients
Administrative Groups (which can contain Servers, Routing Groups, and Folders)
Routing Groups
The following sections examine each of these Exchange components and explain how they fit into the organization. If you don’t see administrative groups or routing groups, don’t worry. We’ll discuss how you enable and use these features later in this chapter.
Global settings apply to all servers and recipients in an organization. The three most common global settings that you’ll work with are as follows:
Internet Message Formats. These global settings define the acceptable Internet message formats for the organization, as well as the way you can use message formats. The settings that you can define include default message encoding, default character sets, and default Multipurpose Internet Mail Extensions (MIME) extension mapping. MIME is the standard used for messages with several parts.
Message Delivery. These global settings define how and when messages are delivered. The settings that you can define include the default postmaster account name, the default quotas, and the default message filters. Message filters allow you to discard messages from specific senders and to redirect messages based on who the sender is.
Mobile Services. These global settings define the mobile services Exchange provides and whether wireless synchronization and browsing are permitted. Any wireless domains serviced by Exchange can also be defined here.
You’ll find detailed instruction on managing global settings in Chapter 13.
A recipient is an entity that can receive Exchange mail. Recipients include users, contacts, groups, and other resources. You refer to recipients as either mailbox-enabled or mail-enabled. Mailbox-enabled recipients (users) have mailboxes for sending and receiving e-mail messages. Mail-enabled recipients (contacts, groups, and public folders) have e-mail addresses but no mailboxes. Thus, mail-enabled recipients can receive messages but can’t send them.
In addition to users, contacts, groups, and public folders, Exchange Server 2003 adds two types of recipients: InetOrgPerson and query-based distribution groups. Basically, an InetOrgPerson represents a user account that was imported from non-Microsoft Lightweight Directory Access Protocol (LDAP) or X.500 directory services, and a query-based distribution group is a type of distribution group you can use to build a list of recipients whenever a mail addressed to the group is received rather than having a fixed member list. Like users, InetOrgPersons can be mailbox-enabled and because InetOrgPersons are essentially users, I won’t always differentiate between the two—I only do this when I am pointing out specific differences.
To manage recipients in your organization, you need to know these key concepts:
How recipient policies are used. Recipient policies define the technique Exchange uses to create addresses for SMTP, Exchange Server, X.400, and so forth. For example, you can set a policy for SMTP that creates e-mail addresses by combining an e-mail alias with @adatum.com. Thus, during setup of an account for William Stanek, the e-mail alias williams is combined with @adatum.com to create the e-mail address <[email protected]>.
How address lists are used. You use address lists to organize recipients and resources, making it easier to find recipients and resources that you want to use, along with their related information. During setup, Exchange creates a number of default address lists. The most commonly used default address list is the global address list, which lists all the recipients in the organization. You can create custom address lists as well.
How address templates are used. Templates define the appearance of recipient information in the address book. When you install Exchange Server, default templates are set up for users, groups, contacts, public folders, search dialog boxes, and the mailbox agent. By modifying the appropriate template, you can change the appearance of recipient information in the address book.
Administrative groups define the logical structure of an Exchange organization. You use administrative groups to help you organize directory objects and efficiently manage Exchange resources. Administrative groups are best suited to large organizations or those with offices in several locations. In a small- or medium-sized company, you might not need to use administrative groups at all.
Another way to think of administrative groups is as logical containers into which you can place directory objects and Exchange resources. For example, you could create administrative groups named Engineering, Marketing, and Administration. Within these groups, you could then define routing groups, policies, servers, public folder trees, and other objects for each department.
When you install Exchange Server, administrative group support is disabled by default. This is done primarily to simplify the Exchange management process. In System Manager, the lack of the Administrative Groups node tells you that administrative group support has been disabled. You can enable support for administrative groups by completing the following steps:
In System Manager, right-click the organization container, and then select Properties.
On the General tab of the Properties dialog box, select Display Administrative Groups.
When you click OK and then restart System Manager, Exchange Server enables administrative groups and configures them for the current operations mode.
How you manage administrative groups depends on the operations mode in use. Exchange Server has two operations modes:
Mixed mode. When operating in mixed mode, Exchange Server 2003 can support pre-Exchange Server 2000 installations.
Native mode. When operating in native mode, Exchange Server 2003 supports only Exchange 2000 Server and Exchange Server 2003 installations.
By default, when you install Exchange Server, the operations mode is set to mixed. The mixed-mode configuration provides for interoperability with Microsoft Exchange 5.0 and Microsoft Exchange 5.5 but limits the capabilities of Exchange Server 2003. These limitations directly affect the way administrative groups are used and effectively force Exchange Server 2003 to handle administrative groups in the same way that Exchange 5.5 handles sites.
When running in mixed-mode operations, Exchange Server operates as follows:
When Exchange Server 2003 coexists with Exchange 5.0 or Exchange 5.5, Exchange Server 2003 uses the site concept to define both administration and routing. This limitation means that each administrative group has only one functional routing group even if you create additional routing groups.
You can’t move mailboxes from a server in one administrative group to a server in another administrative group. This limitation reduces your flexibility in managing mailboxes.
Additional limitations apply if Exchange Server is installed in an Exchange 5.5 site. These additional limitations are as follows:
Some System Manager commands don’t apply to Exchange 5.5. Because of this, you can’t use these commands to manipulate an Exchange 5.5 server.
Exchange 5.5 directory service objects are replicated into Active Directory directory service with read-only properties. This means you can’t edit these properties through Active Directory. You need to use the Exchange Administrator tool for this, which can be installed with Exchange Server.
InetOrgPerson and query-based distribution groups are available only in Microsoft Windows Server 2003 domains and when Exchange is running in native mode. Further, to use query-based distribution groups all servers must be using at least Exchange 2000 with Service Pack 3.
When operating in native mode, Exchange Server isn’t subject to these limitations. You can enable routing group support and create additional routing groups as necessary. It also means that Exchange Server won’t be able to work with Exchange 5.0 or Exchange 5.5 sites that are part of the same organization, and it is as if the Exchange 5.0 and Exchange 5.5 servers no longer exist in the organization.
You can view and change the operations mode by completing the following steps:
In System Manager, right-click the Organization node, and then select Properties.
On the General tab of the Properties dialog box, the Operation Mode field displays the current operation mode as either Mixed Mode or Native Mode (see Figure 4-2).
To change the operation mode from mixed to native, click Change Mode. Confirm the action by clicking Yes. Once you change to native mode, you can’t change back to mixed mode.
You use routing groups in advanced Exchange installations to control message connectivity and communication channels for groups of Exchange servers. When you install the first Exchange server in an organization, the server is added to the default routing group. You have no control over this routing group in mixed-mode operations. Additional servers installed in the Exchange organization are added to this same routing group by default and the message connectivity and communication among these servers is configured automatically.
If you have a single group of servers that have no special communication needs, you don’t need to create additional routing groups. Normally, you use multiple routing groups when you need to connect branch offices or other geographically separated locations and when the following are true:
You don’t have high-bandwidth connections among these locations.
You have special connectivity requirements, such as the need to control precisely how and when Exchange data is transferred among these locations.
Once a server is connected to a particular routing group, you can’t move it to another routing group without reinstalling Exchange Server. Because of this, you should plan the messaging topology for your organization very carefully. Message transfer and communication within routing groups is handled directly with a target server. Message transfer and communication among routing groups is handled by a bridgehead server.
A bridgehead server is the point of entry and exit for all message traffic among routing groups. Bridgehead servers also handle the link state information, which is used to determine optimal routing paths. You must designate a bridgehead server in each routing group. To communicate, bridgehead servers use an Exchange Server Routing Group Connector, which provides the direct connection among routing groups. You use one Routing Group Connector to connect two routing groups.
You can enable support for routing groups by completing the following steps:
Exchange Server stores information in two places:
Active Directory data store
Exchange Server information store
The Active Directory data store contains all directory information for recipients as well as other important directory resources. Domain controllers maintain the data store in a file called Ntds.dit. The location of this file is set when Active Directory is installed and must be on an NTFS (NT file system) drive formatted for use with Windows Server 2003. You can also save directory data separately from the main data store. This is true for some public data, such as logon scripts.
Two key concepts to focus on when looking at Active Directory are multimaster replication and global catalog servers.
Domain controllers replicate most changes to the data store by using multimaster replication, which allows any domain controller to process directory changes and replicate those changes to other domain controllers. Replication is handled automatically for key data types, including the following:
Domain data. Contains information about objects within a domain, such as users, groups, and contacts.
Configuration data. Describes the topology of the directory and includes a list of important domain information.
Schema data. Describes all objects and data types that can be stored in the data store.
Active Directory information is also made available through global catalogs. You use global catalogs for information searches and in some cases domain logon. A domain controller designated as a global catalog stores a full replica of all objects in the data store (for its host domain).
By default, the first domain controller installed in a domain is designated as the global catalog. Consequently, if there is only one domain controller in the domain, the domain controller and the global catalog are on the same server. Otherwise, the global catalog is on the domain controller configured as such.
Information searches are one of the key uses of the global catalog. Searches in the global catalog are very efficient and can resolve most queries locally, thus reducing the network load and allowing for quicker responses. With Exchange, the global catalog can be used to execute LDAP queries for query-based distribution groups. Here, the members of the distribution group are based on the results of the query sent to the global catalog server rather than being fixed.
Why use LDAP queries instead of a fixed member list? The idea is to reduce administrative overheard by being able to dynamically determine what the members of a distribution group should be. Query-based distribution is most efficient when the member list is relatively small (fewer than 25 members). If there are potentially hundreds or thousands of members, however, query-based distribution is very inefficient and might require a great deal of processing to complete.
Here’s how distributed queries work:
When e-mail is received that is addressed to the group, the Exchange categorizer (a transport component) sends the predefined LDAP query to the global catalog server for the domain.
The global catalog server executes the query and returns the resulting address set.
The Exchange categorizer then uses the address list to generate the recipient list and deliver the message. If the categorizer is unable to generate the list for any reason, such as because the list is incomplete or an error was returned, the categorizer might start the process over from the beginning.
The Exchange information store contains mailbox and public folder data. To make the information store more manageable, Exchange Server 2003 allows you to organize the information store into multiple databases. You can then manage these databases individually or in logical groupings called storage groups.
Exchange Server uses transactions to control changes in storage groups. As with traditional databases, these transactions are recorded in a transaction log. Changes are then committed or rolled back based on the success of the transaction. In the case of failure, you can use the transaction log to restore the database. The facility that manages transactions is the Microsoft Exchange Information Store service (Store.exe).
When working with storage groups and Exchange Server 2003 Standard Edition, you should keep the following in mind:
Each Exchange server can have up to two storage groups (with one of the storage groups, called the recovery storage group, being reserved for database recovery operations).
A single storage group can have up to two databases with a maximum size per database of 16 gigabytes. Thus, the maximum number of databases that a single standard server can have is 4 (with 2 reserved for the recovery storage group).
When working with storage groups and Exchange Server 2003 Enterprise Edition, you should keep the following in mind:
Each Exchange server can have up to five storage groups (with one of the storage groups, called the recovery storage group, being reserved for database recovery operations).
A single storage group can have up to five databases with a maximum size per database of 16 terabytes (limited only by hardware). Thus, the maximum number of databases that a single enterprise server can have is 25 (with five reserved for the recovery storage group).
Key concepts to focus on when looking at the Exchange information store and storage groups are the following:
Exchange Database formats
Single-instance message storage
Files associated with storage groups
Exchange servers store databases in two files: a rich-text file with the .edb file extension and a streaming Internet content file with the .stm file extension. The .edb file contains message text and the .stm file contains attachments to these messages.
Because attachments are written in native format, there is no need to convert attachments to Exchange format (as was done in previous versions of Exchange). Exchange Server performs much better when reading and writing attachments in native format.
Two types of databases are available:
Private store databases contain mailboxes
Public store databases. Contain public folders
Exchange Server uses single-instance message storage on a per-database basis. With this technique, a message that’s sent to multiple mailboxes is
Stored once if all the mailboxes are in the same database.
Copied once to each database that contains a target mailbox.
Additionally, if the databases are in different storage groups, Exchange Server writes the message to each database as well as the transaction log set for each storage group. Thus, a message written to three databases that are in two different storage groups would use five times the disk space as a message written to a single database in a single storage group. To see this, consider the following example:
A 2-MB message is sent to all company employees. The mailboxes for these employees are in private stores A and B in storage group 1 and in private store C in storage group 2. Exchange Server writes the message to the transaction log in storage groups 1 and 2 and then writes to the private storage databases A, B, and C. Storing the original 2-MB messages thus requires 10 MB of disk space.
Each storage group on Exchange Server has several files associated with it. These files are as follows:
Edb.chk. A check file containing recovered file fragments
Edb.log. A transaction log file for the storage group
Res1.log. A reserved log file for the storage group
Res2.log. A reserved log file for the storage group
Tmp.edb. A temporary workspace for processing transactions
Dbname.edb. Rich-text database files for individual databases
Dbname.stm. Streaming Internet content files for individual databases
To create a new storage group with a private or public store, you’ll need about 50 MB of free disk space. The files required by the storage group use a minimum of 23 MB of disk space. Although the total disk space used is about 23 MB, you’ll need the extra space during creation and for read/write operations.
Each Exchange server in the organization relies on a set of services for routing messages, processing transactions, replicating data, and much more. To manage Exchange services, you’ll use the Services node in the Computer Management console, which you start by completing the following steps:
Choose Start, Programs or All Programs, Administrative Tools, and then select Computer Management. Or in the Administrative Tools folder, select Computer Management.
To connect to a remote exchange server, right-click the Computer Management entry in the console tree, and then select Connect To Another Computer from the shortcut menu. You can now choose the Exchange server for which you want to manage services.
Expand the Services And Applications node by clicking the plus sign (+) next to it, and then choose Services.
Figure 4-3 shows the Services view in the Computer Management console. The key fields of this window are used as follows:
Name. The name of the service.
Description. A short description of the service and its purpose.
Status. The status of the service as started, paused, or stopped. (Stopped is indicated by a blank entry.)
Startup Type. The startup setting for the service.
Log On As. The account the service logs on as. The default in most cases is the local system account.
Table 4-1 provides a summary of the services essential to normal Exchange operations. Note that the services that are available on a particular Exchange server depend on its configuration. Still, there is a core set of services that you’ll find on most Exchange servers.
Table 4-1. Core Exchange Server Services
Name | Description |
|---|---|
ASP.NET State Service | Provides services for managing client sessions when using HTTP and remote procedure call (RPC) over HTTP, and other Internet Information Services (IIS) functions. |
Distributed Transaction Coordinator | Coordinates transactions that are distributed across multiple databases, message queues, and file systems. |
Event Log | Logs event informational, warning, and error messages issued by Exchange Server and other applications. |
HTTP SSL | Provides services for secure transfer of data using HTTP and RPC over HTTP. |
IIS Admin Service | Allows you to administer the Exchange HTTP virtual server in the IIS snap-in. |
Microsoft Exchange Event | Monitors folders and generates events for Exchange 5.5 applications. |
Microsoft Exchange IMAP4 | Provides Microsoft Exchange services for Internet Message Access Protocol (IMAP4). |
Microsoft Exchange Information Store | Manages Microsoft Exchange information storage. |
Microsoft Exchange Management | Provides Windows Management Instrumentation (WMI) information for Exchange. |
Microsoft Exchange MTA Stacks | Provides Microsoft Exchange X.400 services using Message Transfer Agent (MTA) stacks. |
Microsoft Exchange POP3 | Provides Microsoft Exchange POP3 services. |
Microsoft Exchange Routing Engine | Processes Microsoft Exchange message routing and link state information. |
Microsoft Exchange Site Replication Service | Replicates Exchange information within the organization. |
Microsoft Exchange System Attendant | Monitors Microsoft Exchange and provides essential services. |
Network News Transfer Protocol (NNTP) | Transports newsgroup messages across the network. |
Simple Mail Transfer Protocol (SMTP) | Transports e-mail across the network. |
World Wide Web Publishing Service | Provides HTTP services for Microsoft Exchange Server and IIS. |
Security Alert
It is important to note that on a new Exchange Server 2003 installation, some services are disabled initially for security reasons. Specifically, you’ll find that the Microsoft Exchange POP3, Microsoft Exchange IMAP4, Microsoft Exchange Site Replication Service and Network News Transfer Protocol services are disabled. If you use these services with Exchange, you’ll need to enable them for automatic startup and then start them using the techniques discussed in the section of this chapter entitled, "Using and Managing Exchange Server Services."
As an administrator, you’ll often have to start, stop, or pause Exchange services. You manage Exchange services through the Computer Management console or through System Manager.
To start, stop, or pause services in the Computer Management console, follow these steps:
To connect to a remote exchange server, right-click the Computer Management entry in the console tree, and then select Connect To Another Computer from the shortcut menu. You can now choose the Exchange server for which you want to manage services.
Expand the Services And Applications node by clicking the plus sign (+) next to it, and then choose Services.
Right-click the service you want to manipulate, and then select Start, Stop, or Pause as appropriate. You can also choose Restart to have Windows stop and then start the service after a brief pause. Also, if you pause a service, you can use the Resume option to resume normal operation.
Tip
When services that are set to start automatically fail, the status is listed as blank and you’ll usually receive notification in a pop-up window. Service failures can also be logged to the system’s event logs. In Windows Server 2003, you can configure actions to handle service failure automatically. For example, you could have Windows Server 2003 attempt to restart the service for you. See the section of this chapter entitled "Configuring Service Recovery" for details.
Several of the Exchange services are used to manage the Exchange virtual servers. These services are as follows:
Microsoft Exchange IMAP4 for the IMAP4 virtual server
Microsoft Exchange POP3 for the POP3 virtual server
Network News Transfer Protocol (NNTP) for the NNTP virtual server
Simple Mail Transfer Protocol (SMTP) for the SMTP virtual server
If you start, stop, or pause these services in the Computer Management console, you’re managing the related virtual server as well. You can also use System Manager to perform these tasks. To do that, complete the following steps:
In System Manager, access the Servers node within the administrative or routing group you want to manage. Typically, you would expand Administrative Groups, First Administrative Group, and then the Servers node.
In the console tree, select the Exchange server you want to manage, and then double-click Protocols. You should now see a list of protocols installed on the server.
The Protocol folder stores related virtual servers. For example, the IMAP4 folder stores the Default IMAP4 virtual server and any other IMAP4 virtual servers you’ve created.
Right-click the virtual server you want to start, stop, or pause, and then select Start, Stop, or Pause as appropriate from the shortcut menu.
Essential Exchange services are configured to start automatically and normally shouldn’t be configured with another startup option. That said, if you’re troubleshooting a problem, you might want a service to start manually. You might also want to disable a service so that its related virtual servers don’t start. For example, if you move the POP3 virtual servers to a new server for load balancing, you might want to disable the Microsoft Exchange POP3 service on the original Exchange server. In this way, the POP3 service isn’t used, but it could be turned on if necessary (without having to reinstall POP3 support).
You configure service startup by completing the following steps:
In the Computer Management console, connect to the Exchange server for which you want to manage services.
Expand the Services And Applications node by clicking the plus sign (+) next to it, and then choose Services.
Right-click the service you want to configure, and then choose Properties.
On the General tab, use the Startup Type selection list to choose a startup option, as shown in Figure 4-4. Select Automatic to start services at bootup. Select Manual to allow services to be started manually. Select Disabled to turn off services.
Click OK.
You can configure Windows services to take specific actions when a service fails. For example, you could attempt to restart the service or reboot the server. To configure recovery options for a service, follow these steps:
In the Computer Management console, connect to the computer for which you want to manage services.
Expand the Services And Applications node by clicking the plus sign (+) next to it, and then choose Services.
Right-click the service you want to configure, and then choose Properties.
Select the Recovery tab, as shown in Figure 4-5. You can now configure recovery options for the first, second, and subsequent recovery attempts. The available options are as follows:
Take No Action
Restart The Service
Run A File
Restart The Computer
Configure other options based on your previously selected recovery options. If you elected to restart the service, you’ll need to specify the restart delay. After stopping the service, Windows Server 2003 waits for the specified delay period before trying to start the service. In most cases a delay of one to two minutes should be sufficient.
Click OK.
When you configure recovery options for critical services, you might want to try to restart the service on the first and second attempts and then reboot the server on the third attempt.