Understanding Exchange Server 2007 Organizations

The root of an Exchange environment is an organization. It's the starting point for the Exchange hierarchy, and its boundaries define the boundaries of any Exchange environment. Exchange Server 2007 organizations are quite different from Exchange Server 2003 organizations.

When you install Exchange Server 2007, you are not given the opportunity to join an existing organization or create a new organization. Instead, in a domain, you install the Exchange server within the organizational context of the domain in which the server is a member. The physical site boundaries and subnets defined for Active Directory are the same as those used by Exchange Server 2007, and the site details are determined according to the IP address assigned to the server.

Unlike Exchange Server 2003, Exchange Server 2007 uses Active Directory site-based routing instead of routing groups and configuration containers instead of administrative groups. The use of site-based routing and configuration containers substantially changes the way you configure and manage Exchange Server 2007.

Using Site-Based Routing Instead of Routing Groups

With Exchange Server 2007, site-based routing is possible because Exchange servers can determine their own Active Directory site membership and the Active Directory site membership of other servers by querying Active Directory. Using Active Directory for routing eliminates the need for Exchange to have its own routing infrastructure.

How Site-Based Routing Works

Mailbox and Unified Messaging servers use site membership information to determine which Hub Transport servers are located in the same site. This allows the Mailbox or Unified Messaging server to submit messages for routing and transport to a Hub Transport server that has the same site membership.

When a Client Access server receives a user connection request, it queries Active Directory to determine which Mailbox server is hosting the user's mailbox. The Client Access server then retrieves the site membership of that Mailbox server. If the Client Access server is not in the same site as the user's Mailbox server, the connection is redirected to a Client Access server in the same site as the Mailbox server.

Hub Transport servers retrieve information from Active Directory to determine how they should transport mail inside the organization. When a user sends a message, the Categorizer running on the Hub Transport server uses the header information about the message to query Active Directory for information about where the server must deliver the message. If the recipient's mailbox is located on a Mailbox server in the same site as the Hub Transport server, the server delivers the message directly to that mailbox. If the recipient's mailbox is located on a Mailbox server in a different site, the message is transferred to a Hub Transport server in that site and then that server delivers the message to the mailbox.

Exchange servers determine site membership by matching their assigned IP address to a subnet that is defined in Active Directory Sites And Services and associated with an Active Directory site. The Exchange server then uses this information to determine which domain controllers, Global Catalog servers, and other Exchange servers exist in that site and communicate with those directory servers for authentication, authorization, and messaging purposes. Exchange 2007 always tries to retrieve information about recipients from directory servers that are in the same site as the Exchange 2007 server.

Tip 

In Active Directory, you can associate a site with one or more IP subnets. Each subnet that is part of a site should be connected over reliable, high-speed links. You should configure any business locations connected over slow or unreliable links as part of separate sites. Because of this, individual sites typically represent well-connected local area networks (LANs) within an organization, and wide area network (WAN) links between business locations typically mark the boundaries of these sites. Sites cannot have overlapping subnet configurations. If subnets overlap, replication and message routing will not work correctly.

How IP Site Links Are Used

As Figure 5-1 shows, Active Directory sites are connected through IP site links. An IP site link can connect two or more sites. Each site link has a specific schedule, interval, and cost. The schedule and interval determine the frequency of Active Directory replication. The cost value determines the cost of using the link relative to other links that may be available. Active Directory replication uses the link with the lowest cost when multiple paths exist to a destination. The cost of a route is determined by adding together the cost of all site links in a transmission path. Administrators assign the cost value to a link based on relative network speed, available bandwidth, and reliability compared to other available connections. By default, IP site links always allow traffic to flow into or out of a site.

Figure 5-1: Message traffic between sites is routed over IP site links.

In large enterprises, message traffic may have to travel through multiple sites to get from the source site to a destination site. When transferring messages from one site to another site through other sites, a Hub Transport server always tries to connect directly to a Hub Transport server in the destination site. Because of this, messages are not relayed through each Hub Transport server in each site in the link path. Instead, they go directly from the Hub Transport server in the originating site across the link to the Hub Transport server in the destination site. If the originating server cannot Connect directly to a Hub Transport server in the destination site, the originating Hub Transport server uses the link cost to determine the closest site at which to queue the message. This new feature is called queue at point of failure.

The Hub Transport server can also use the site link information to optimize routing of messages that users send to multiple recipients. Here, the Hub Transport server only expands a distribution list and creates multiple copies of a message when there are multiple paths in the routing topology. This new feature is called delayed fan-out.

Using Configuration Containers Instead of Administrative Groups

Exchange Server 2007 uses configuration containers instead of administrative groups to simplify the administrative model. As Figure 5-2 shows, you can view the logical structure of the Exchange organization in Exchange Management Console. Start Exchange Management Console by clicking Start, selecting All Programs, selecting Microsoft Exchange Server 2007, and selecting Exchange Management Console.

Figure 5-2: The configuration containers are used to manage the Exchange organization.

In Exchange Management Console, under the Microsoft Exchange node, you'll find three top-level containers:

• Organization Configuration Used to view and manage the global settings for all servers and recipients in an organization. Settings are organized based on server role and applied globally throughout the organization.

• Server Configuration Used to view and manage the configuration of individual servers in an organization. Servers are organized by role.

• Recipient Configuration Used to view and manage recipients in an organization. Recipients are organized by type, independent of the mailbox server on which they are stored.

The sections that follow discuss these Exchange components and explain how they fit into the overall organizational structure.

Working with the Organization Configuration Node

With Exchange Server 2007, the scope of the organization is the same as the scope of your Active Directory organization. Because of this, Organization Configuration settings apply to all Exchange servers and Exchange recipients in all domains of your Active Directory forest. When you select the Organization Configuration node, the results pane lists the identities that are currently configured as Exchange administrators, including the role and scope assigned, as shown in Figure 5-3.

Figure 5-3: Organization Configuration extends to administrator roles as well as other organization-wide settings.

You can specify additional Exchange administrators by right-clicking the Organization Configuration node and selecting Add Delegate. You can remove Exchange administrators by right-clicking the administrator entry and selecting Remove. Other tips and techniques for managing administrative roles are discussed in Chapter 10, "Implementing Exchange Server 2007 Security."

The subnodes under the Organization Configuration node provide access to the most common organization-level settings you'll work with:

• Mailbox Allows you to manage Mailbox Server role settings that apply to your entire Exchange 2007 organization. Mailbox Server role settings that you can manage include address lists, managed folders, mailbox policies, and offline address books. See Chapter 9, "Working with Groups, Lists, and Managed Folders" for more information.

• Client Access Allows you to manage Client Access Server role settings that apply to your entire Exchange 2007 organization. Client Access Server role settings allow you to create and manage Exchange ActiveSync Mailbox policies. See Chapter 16, "Managing Client Access Servers," for more information.

• Hub Transport Allows you to manage Hub Transport Server role settings that apply to your entire Exchange 2007 organization. Hub Transport Server role settings you can manage include remote and accepted domains, e-mail address policies, transport rules, journal rules, send connectors, and Edge subscriptions. See Chapter 15, "Managing Hub Transport and Edge Transport Servers," for more information.

• Unified Messaging Allows you to manage Unified Messaging Server role settings that apply to your entire Exchange 2007 organization. Unified Messaging Server role settings you can manage include dial plans, gateways, mailbox policies, and auto-attendants.

With Exchange Server 2007 organizations, all organization information is stored in Active Directory. When you start Exchange Management Console, the console obtains the Organization Configuration details from the authoritative domain controller to which your computer is currently connected. In some cases, such as when you need to work with recipients and objects in a specific site or domain, you may want to connect to a specific authoritative domain controller and obtain server and Organization Configuration details from this server.

You can specify the domain controller from which to obtain Organization Configuration details by completing the following steps:

1. Open the Exchange Management Console.

2. Right-click the Organization Configuration node, and then select Modify Configuration Domain Controller. The Configuration Domain Controller dialog box appears, shown in Figure 5-4.

3. In the Domain text box, click Browse, and then use the Select Domain dialog box to select the domain to use.

4. In the specified domain, by default, you are connected to the first authoritative domain controller that responds to your request. To specify a configuration domain controller to use, select the Configuration Domain Controller checkbox and then click Browse. Use the Select Domain Controller dialog box to select the domain controller to use according to its site membership in the previously specified domain.

5. When you click OK, the Exchange Management Console retrieves the topology information for the specified domain and site.

Figure 5-4: Specify the domain and domain controller to use.

Working with the Server Configuration Node

Unlike Exchange Server 2003, all servers running Exchange Server 2007 have one or more server roles. You can deploy the Mailbox, Client Access, Hub Transport, and Unified Messaging Server roles together. You can also manage these roles together using the Server Configuration node in Exchange Management Console. When you select the Server Configuration node in Exchange Management Console, all Exchange servers in your Exchange Server 2007 organization are listed in the results pane by name, Exchange Server 2007 roles installed, and Exchange Server version, as shown in Figure 5-5.

Figure 5-5: Server Configuration settings apply to individual servers according to their role.

You can work with the individual server entries in several ways:

• If you right-click a server entry, you'll see a shortcut menu with options for managing each configured role. Selecting one of those options opens the corresponding subnode under Server Configuration and is the same as selecting the subnode and then selecting the server with which you want to work.

• If you right-click a server entry, and then select Properties, you'll see the Properties dialog box, shown in Figure 5-6. The General tab provides additional summary details on the server configuration, including the Exchange Server 2007 edition the server is running, the domain controllers being used by Exchange, and the Global Catalog servers being used by Exchange. Other server-specific configuration details are discussed elsewhere in this book.

Figure 5-6: General properties provide additional configuration details for the selected server.

The subnodes under the Server Configuration node provide access to the most common settings you'll work with for individual servers according to their role:

• Mailbox Allows you to manage the Mailbox configuration of a selected server. In the top pane, servers are listed by name, role, and Exchange version. If you select a server in the top pane, the related databases are listed according to the related storage groups and database file paths. See Chapter 11, "Managing Microsoft Exchange Data and Storage Groups," for more information.

• Client Access Allows you to manage the Client Access configuration of a selected server. In the top pane, servers are listed by name, role, Exchange version, and Outlook Anywhere state. If you select a server in the top pane, you can view the Web sites and Uniform Resource Locators (URLs) used with Outlook Web Access, Exchange ActiveSync, and Offline Address Book Distribution. See Chapter 16, "Managing Client Access Servers," for more information.

• Hub Transport Allows you to manage the Hub Transport configuration of a selected server. In the top pane, servers are listed by name, role, Exchange version, external postmaster address, and message tracking state. If you select a server in the top pane, you can view the Receive Connectors and their status. See Chapter 15 for more information.

• Unified Messaging Allows you to manage the Unified Messaging configuration of a selected server. In the top pane, servers are listed by name, role, Exchange version, unified messaging status, and associated dial plans. If you select a server in the top pane, you can view the dial plans, IP gateways, mailbox policies, and auto-attendants for that server.

As with organization-level configuration details, the configuration details for individual servers are stored in Active Directory. You can specify the domain controller from which to obtain Server Configuration details by completing the following steps:

1. Open the Exchange Management Console.

2. Right-click the Server Configuration node, and then select Modify Configuration Domain Controller. The Configuration Domain Controller dialog box appears, shown previously in Figure 5-4.

3. Follow steps 3–5 under "Working with the Organization Configuration Node."

Working with the Recipient Configuration Node

A recipient is an entity that can receive Exchange mail. Recipients include users, contacts, distribution groups, public folders, and resources. Types of resources used with Exchange include rooms and equipment used for scheduling.

You refer to recipients as either mailbox-enabled or mail-enabled. Mailbox-enabled recipients (users and resources) have mailboxes for sending and receiving e-mail messages. Mail-enabled recipients (contacts, distribution 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, resources, and public folders, Exchange Server 2007 has three unique types of recipients: linked mailboxes and dynamic distribution groups. Basically, a linked mailbox represents a mailbox that is accessed by a user in a separate, trusted forest. A dynamic distribution group is a type of distribution group that you can use to build a list of recipients whenever mail addressed to the group is received rather than having a fixed member list.

To manage recipients in your organization, you need to know these key concepts:

• How e-mail policies are used E-mail address policies define the technique Exchange uses to create e-mail addresses for users, resources, contacts, and mail-enabled groups. For example, you can set a policy for users with Exchange mailboxes that creates e-mail addresses by combining an e-mail alias with @cpandl.com. Thus, during setup of an account for William Stanek, the e-mail alias williams is combined with @cpandl.com to create the e-mail address [e-mail].

• How address lists are used You use address lists to organize recipients and resources, making it easier to find the ones 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 managed folders are used Every recipient has a default set of managed folders that are displayed in Outlook and related views of Outlook, such as Outlook Web Access. These folders include Inbox, Contacts, Drafts, Deleted Items, Junk E-mail, Outbox, and Sent Items. To the default folders, you can add custom managed folders. For example, if managers need to approve certain types of messages before the messages are sent, you could create a Pending Approval folder.

In Exchange Management Console, Recipient Configuration settings apply to individual recipients in all domains of your Active Directory forest according to their type. The subnodes under the Recipient Configuration node provide access to recipients according to their type or state:

• Mailbox Allows you to view and manage user mailboxes, room mailboxes, equipment mailboxes, and linked mailboxes. See Chapter 8, "Mailbox Administration," for more details.

• Distribution Group Allows you to view and manage standard and dynamic distribution groups. See Chapter 9 for more details.

• Mail Contact Allows you to view and manage mail contacts. See Chapter 7 for more details.

• Disconnected Mailbox Allows you to view and manage disconnected mail-boxes. A disconnected mailbox is a mailbox that is not associated with an Active Directory user account because it has been removed and marked for deletion. By default, when you remove a mailbox, it remains as a disconnected mailbox in Exchange for 30 days. At the end of the 30-day period, the mailbox is permanently removed. See Chapter 12, "Mailbox and Public Database Store Administration," for more information.

When you select the Recipient Configuration node in Exchange Management Console, or any related subnodes, Exchange recipients for your logon domain are listed in the results pane, as shown in Figure 5-7. Recipients are scoped to the logon domain by default rather than to all domains in the Active Directory forest, because an enterprise can have many thousands of recipients and you typically will not want to work with all recipients in all domains simultaneously.

Figure 5-7: Recipient Configuration settings apply to individual recipients according to their type.

You can, however, configure the recipient scope so that you can:

• View all recipients in your Active Directory forest.

• View all recipients in a domain other than your logon (default) domain.

• View all recipients in a specific organizational unit (OU).

You can set the scope for recipient configuration by completing the following steps:

1. Open the Exchange Management Console.

2. Right-click the Recipient Configuration node, and then select Modify Recipient Scope. The Recipient Scope dialog box appears, shown in Figure 5-8.

3. If you want to view all recipients in your Active Directory forest, select View All Recipients In Forest. Information about recipients for the forest is retrieved from the Global Catalog. If you'd like to specify a specific Global Catalog server to use, select the Global Catalog check box, click Browse, and then use the Select Global Catalog dialog box to select the Global Catalog server to use according to its site membership in the forest.

4. If you want to view all recipients in a specific domain or organizational unit, select View All Recipients In Specified Organizational Unit. Information about recipients for the domain or organizational unit is retrieved from a domain controller in the domain or OU. If you'd like to specify a domain controller to use, select the Recipient Domain Controller check box, click Browse, and then use the Select Domain Controller dialog box to select the domain controller to use according to its site membership in the related domain.

5. When you click OK, the recipient information for the specified forest, domain, or OU is retrieved.

Figure 5-8: Specify the scope for recipient configuration.

When you select the Recipient Configuration node in Exchange Management Console, or any related subnodes, the maximum number of Exchange recipients you can view at any time is limited by default to 1,000. You can change the maximum number of recipients to display by completing the following steps:

1. Open the Exchange Management Console.

2. Select the Recipient Configuration node or the subnode you want to work with, and then in the Actions pane, click Modify The Maximum Number Of Recipients To Display. This displays the Maximum Number Of Recipients To Display dialog box shown in Figure 5-9.

3. In the text box provided, type the maximum number of recipients to display.

4. When you click OK, the recipient display is refreshed using the specified maximum number of recipients.

Figure 5-9: Specify the number of recipients to display.

Understanding Data Storage in Exchange Server 2007

Depending on its role, Exchange Server stores information in several locations, including:

• Active Directory data store

• Exchange Server information store

• Exchange Server queues

Working with the Active Directory Data Store

The Active Directory data store contains all directory information for Exchange Server 2007 configuration and Exchange Server 2007 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 Microsoft 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.

Using Multimaster Replication

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.

Using Global Catalogs

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 server 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 server. 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 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 Lightweight Directory Access Protocol (LDAP) queries for dynamic 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, dynamic distribution can be inefficient and might require a great deal of processing to complete.

Here's how dynamic distribution works:

1. 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.

2. The Global Catalog server executes the query and returns the resulting address set.

3. 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, for instance if the list is incomplete or an error was returned, the Categorizer might start the process over from the beginning.

Note 

To make the process more efficient, large organizations can use a dedicated expansion server. Here, LDAP queries are routed to the expansion server. The expansion server processes the query and returns the results.

Working with the Exchange Server Information Store

The Exchange information store contains mailbox and public folder data. To make the information store more manageable, Exchange Server 2007 allows you to organize it 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. Exchange Server then commits or rolls back changes 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 2007 Standard Edition, you should keep the following in mind:

• Each Exchange server can have up to ten storage groups (with one of the storage groups, called the recovery storage group (RSG), reserved for database recovery operations).

• A single storage group can have up to five databases, with a maximum size per database of 16 gigabytes (GB). Thus, the maximum number of databases that a single Standard server can have is 50 (with up to five reserved for the recovery storage group).

When working with storage groups and Exchange Server 2007 Enterprise Edition, you should keep the following in mind:

• Each Exchange server can have up to 50 storage groups (with one of the storage groups, the RSG, reserved for database recovery operations).

• A single storage group can have up to five databases, with a maximum size per database of 16 terabytes (TB)-limited only by hardware. However, the maximum number of databases that a single Enterprise server can have is 50 (with up to five reserved for the recovery storage group).

To create a new storage group with a mailbox or public folder database, you'll need about 50 megabytes (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.

The Exchange information store uses Extensible Storage Engine (ESE) databases for message storage. ESE is a revised and updated architecture for the JET database previously used with the Windows operating systems. Key concepts to focus on when working with the Exchange information store and storage groups are the following:

• What Exchange server data files are used

• How data is stored in Exchange database files

• What files are associated with storage groups

• How single-instance storage is used

What Exchange Server Data Files Are Used?

With Exchange Server 2007, Mailbox servers have a single database file for each mail-box or public folder database. Unlike Exchange Server 2003, Exchange Server 2007 does not use a streaming Internet content file with the .stm file extension. Although the .stm file was previously used to store message attachments, Exchange Server 2007 now stores attachments along with messages in the primary data file.

Because attachments are encapsulated and written in binary format, there is no need to convert them to Exchange format. Exchange Server uses a link table within the data-base to reference the storage location of attachments within it.

Two types of databases are available:

Mailbox databases Contain mailboxes

Public Folder databases Contain public folders

What Files Are Associated with Storage Groups?

As Figure 5-10 shows, each storage group has primary data files for each associated database and several other types of shared working files and transaction logs.

Figure 5-10: The Exchange data store has primary data files for each database as well as working files for the storage group.

These files are used as follows:

Primary data file (Database.edb) Physical database file that holds the contents of the data store. The name of the data file is the same as the name of the associated data store with .edb file extension added.

Checkpoint file (E##.chk) Checkpoint file that tracks the point up to which the transactions in the log file have been committed to databases in the storage group. Generally, the name of the checkpoint file for the first storage group is E00.chk, the name of the checkpoint file for the second storage group is E01.chk, and so on.

Temporary data (Tmp.edb) Temporary workspace for processing transactions.

Primary log file (E##.log) Primary log file that contains a record of all changes that have yet to be committed to the database in the storage group. Generally, the name of the log file for the first storage group is E00.log, the name of the log file for the second storage group is E01.log, and so on.

Secondary log files (E##00000001.log, E##00000002.log, …) Additional log files that are used as needed. Up to a billion unique log files can be created per storage group.

Reserve log files (E##Res0000jrs, E##Res0000jrs, …) Files that are used to reserve space for additional log files if the primary log file becomes full.

By default, the primary data file, working files, and transaction logs are all stored in the same location. On a Mailbox server, you'll find these files in a per-storage group sub-folder of the %SystemRoot%∖Program Files∖Microsoft∖Exchange Server∖Mailbox folder. Although these are the only files used for the data store, Exchange Server uses other files, depending on the roles for which you have configured the server.

How Is Data Stored in Exchange Database Files?

Exchange uses object-based storage. The primary data file contains several indexed tables, including a data table that contains a record for each object in the data store. Each referenced object can include object containers, such as mailboxes, and any other type of data that is stored in the data store.

Think of the data table as having rows and columns; the intersection of a row and a column is a field. The table's rows correspond to individual instances of an object. The table's columns correspond to folders. The table's fields are populated only if a folder has stored data. The data stored in fields can be a fixed or a variable length.

Records in the data table are stored in data pages that have a fixed size of 8 kilobytes (KB, or 8,192 bytes). The 8-KB page file size represents a change from the 4-KB data pages used with Exchange Server 2003. This change was made to improve performance.

In an Exchange database, each data page has a page header, data rows, and free space that can contain row offsets. The page header uses the first 96 bytes of each page, leaving 8,096 bytes for data and row offsets. Row offsets indicate the logical order of rows on a page, which means that offset 0 refers to the first row in the index, offset 1 refers to the second row, and so on. If a row contains long, variable-length data, the data may not be stored with the rest of the data for that row. Instead, Exchange can store an 8-byte pointer to the actual data, which is stored in a collection of 8-KB pages that aren't necessarily written contiguously. In this way, an object and all its stored values can be much larger than 8 KB.

The primary log file has a fixed size of 1 MB. The 1-MB log file size represents a change from the 5-MB log files used with Exchange Server 2003. This change was made so that Exchange Server 2007 could support continuous replication. When this log file fills up, Exchange creates additional (secondary) log files as necessary. The secondary log files are also limited to a fixed size of 1 MB. Exchange uses the reserve log files to reserve disk space for log files that it may need to create. As several reserve files are already created, this speeds up the transactional logging process when additional logs are needed.

How Is Single-Instance Storage Used?

Like previous versions, Exchange Server 2007 continues to use 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.

In addition, if the databases are in different storage groups, Exchange Server writes the message to each database as well as to 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 better understand this, consider the following example:

A 2-MB message is sent to all company employees. The mailboxes for these employees are in mailbox databases A and B in storage group 1 and in mailbox database 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 mailbox databases A, B, and C. Storing the original 2-MB messages thus requires 10 MB of disk space.

Note 

Needing 10 MB of disk space to store a 2-MB message might sound like an awful lot of space, but remember the hidden savings. That 2-MB message might have been sent to 1,000 employees, and without single-instance message storage, Exchange Server would use a whopping 2 GB of disk space.

Working with the Exchange Server Message Queues

Exchange Server message queues are temporary holding locations for messages that are waiting to be processed. Two general types of queues are used:

• Persistent Persistent queues are always available even if there are no messages waiting to be processed.

• Nonpersistent Nonpersistent queues are only available when there are messages waiting to be processed.

With Exchange Server 2007, both Hub Transport and Edge Transport servers store messages waiting to be processed in persistent and nonpersistent queues. Table 5-1 provides an overview of the queues used.

Table 5-1: Queues Used with Transport Servers
Open table as spreadsheet

Queue Name	Server Role	Number of Queues	Queue Type
Mailbox delivery	Hub Transport	One for each unique destination Mailbox server	Nonpersistent
Poison message	Hub Transport, Edge Transport	1	Persistent
Remote delivery	Hub Transport	One for each unique remote Active Directory site	Nonpersistent
Remote delivery	Edge Transport	One for each unique destination Simple Mail Transfer Protocol (SMTP) domain and smart host	Nonpersistent
Submission	Hub Transport, Edge Transport	One	Persistent
Unreachable	Hub Transport, Edge Transport	One	Persistent

As Figure 5-11 shows, the various message queues are all stored in a single database. Like the Exchange information store, the message queues database uses the ESE for message storage as well as for data pages that have a fixed size of 8 KB.

Figure 5-11: The Exchange message queues are all stored in a single database.

The database has a single data file associated with it and several other types of working files and transaction logs. These files are used as follows:

Primary data file (Mail.que) Physical database file that holds the contents of all message queues.

Checkpoint file (Trn.chk) Checkpoint file that tracks the point up to which the transactions in the log file have been committed to the database.

Temporary data (Tmp.edb) Temporary workspace for processing transactions.

Primary log file (Trn.log) Primary log file that contains a record of all changes that have yet to be committed to the database.

Secondary log files (TRN00001.log, TRN00002.log, …) Additional log files that are used as needed.

Reserve log files (TRNRes00001.jrs, TRNRes00002.jrs, …) Files that are used to reserve space for additional log files if the primary log file becomes full.

The facility that manages queuing transactions is the Microsoft Exchange Transport service (MSExchangeTransport.exe). Because logs used with message queues are not continuously replicated, these log files have a fixed size of 5 MB. When the primary log file for message queues fills up, Exchange creates additional (secondary) log files as necessary. Exchange uses the reserve log files to reserve disk space for log files that may need to be created. As several reserve files are already created, this speeds up the transactional logging process when additional logs are needed.

By default, the data file, working files, and transaction logs are all stored in the same location. On a Hub Transport or Edge Transport server, you'll find these files in the %System-Root%∖Program Files∖Microsoft∖Exchange Server∖TransportRoles∖data∖Queue folder.

Using and Managing Exchange Server Services

Each Exchange server in the organization relies on a set of services for routing messages, processing transactions, replicating data, and much more. Table 1-1 in Chapter 1, "Microsoft Exchange Server 2003 Administration Overview," lists these services. To manage Exchange services, you'll use the Services node in the Computer Management console, which you start by completing the following steps:

1. Choose Start, point to Programs or All Programs, point to Administrative Tools, and then select Computer Management. Or, in the Administrative Tools folder, select Computer Management.

2. 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.

3. Expand the Services And Applications node and then select Services.

Figure 5-12 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.

  Note 

  Automatic services are started when the computer is started. Manual services are started by users or other services. Disabled services are turned off and can't be started.

• Log On As The account the service logs on as. The default, in most cases, is the local system account.

Figure 5-12: Use the Services node of the Computer Management console to manage Exchange Server services.

Security It is important to note that on a new Exchange Server 2007 installation, some services are configured for a manual start for security reasons. Specifically, you'll find that the Microsoft Exchange Post Office Protocol version 3 (POP3), Microsoft Exchange Internet Messaging Access Protocol 4 (IMAP4), and Microsoft Search (Exchange) services are configured to start manually. If you use these services with Exchange, you'll need to configure 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."

Starting, Stopping, and Pausing 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 the Services console.

To start, stop, or pause services in the Computer Management console, follow these steps:

1. If necessary, connect to the remote Exchange server for which you want to manage services.

2. Expand the Services And Applications node, and then select Services.

3. 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.

Configuring Service Startup

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, or you might want to temporarily disable a service.

You configure service startup by completing the following steps:

1. In the Computer Management console, connect to the Exchange server for which you want to manage services.

2. Expand the Services And Applications node, and then select Services.

3. Right-click the service you want to configure, and then select Properties.

4. On the General tab, use the Startup Type drop-down list to choose a startup option, as shown in Figure 5-13. Select Automatic to start a service when the computer starts. Select Manual to allow services to be started manually. Select Disabled to disable the service. Click OK.

   Note 

   The Disabled option doesn't stop the service if it's currently running. It just prevents the service from starting the next time you start the server. To stop the service, you must click Stop.

Figure 5-13: For troubleshooting, you might want to change the service startup option in the Properties dialog box.

Configuring Service Recovery

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:

1. In the Computer Management console, connect to the computer for which you want to manage services.

2. Expand the Services And Applications node, and then select Services.

3. Right-click the service you want to configure, and then select Properties.

4. On the Recovery tab, shown in Figure 5-14, you can configure recovery options for the first, second, and subsequent recovery attempts. The available options are as follows:

   • q Take No Action

   • q Restart The Service

   • q Run A File

   • q Restart The Computer

5. 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.

Figure 5-14: By using the Recovery tab in the Properties dialog box, you can configure services to automatically recover in case of failure.

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.