This post by David Papkin is about configuring Mailbox Servers in Microsoft Exchange 2013.
The key component of the Microsoft® Exchange Server 2013 infrastructure is the Mailbox server, which hosts mailbox databases and addresses books, handles message transport and routing, and provides unified messaging services. When you plan an Exchange Server 2013 deployment, it is very important to consider all aspects of your deployment that can affect the Mailbox server role design. In this post , we will talk about planning and configuring of the Mailbox server role.
The Mailbox Server Role in Exchange Server 2013 In Exchange Server 2013, the Mailbox server does much more than it did in Microsoft Exchange Server 2010. In Exchange Server 2010, the Mailbox server hosts databases and provides email storage. In Exchange Server 2013, the Mailbox server also hosts Client Access protocols, Transport service components, mailbox databases, and Unified Messaging components. Although clients never communicate directly with the Mailbox server, this server interacts actively with the Active Directory® Domain
Services (AD DS) components and Client Access server. It uses the Lightweight Directory Access Protocol (LDAP) to locate and access information about recipients, servers, and organization configuration information that is stored in AD DS.
The Mailbox server also participates in high-availability configurations through Database Availability Groups (DAGs). This concept provides high availability at a database level by implementing multiple copies on the same database over different mailbox servers. A DAG is a group of up to 16 Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases.
Most of the functionality for internal message transport and routing, previously hosted on the Hub Transport server, is now located on the Mailbox server role. The Hub Transport service, running on the Mailbox server role, handles all internal Simple Mail Transfer Protocol (SMTP) mail flow, and performs message categorization and content inspection. In addition to this service, there are two more transport services that run on the Mailbox server role: Mailbox Transport Submission and Mailbox Transport Delivery. These two services communicate with the Hub Transport service to send messages to other servers, and also with the mailbox database to retrieve or submit data to the database. The Unified Messaging server role, which previously existed as a separate server role, is now also integrated with the Mailbox server role.
Note: The Mailbox server role in Exchange Server 2013 also hosts public folder mailboxes.
Unlike in Exchange Server 2010, public folders do not use separate databases or a separate
replication mechanism.
The Mailbox server role in Exchange Server2013 includes the following new features:
• In an evolution of the Exchange Server 2010 DAG, the transaction log code has been refactored for fast failover, with deep checkpoints on passive database copies.
• Servers can be in different locations to support enhanced site resiliency.
• Exchange Server 2013 now hosts some Client Access components, including the transport
components and the Unified Messaging components.
• The Exchange store has been rewritten in managed code to improve performance in additional I/O reduction and reliability.
• Each Exchange Server 2013 database now runs under its own process.
How the Mailbox Server Role Interacts with Clients and the Client Access Server
In addition to its communication with AD DS, the Mailbox server role communicates intensively
with the Client Access server. This communication always takes the same paths, even when the Client Access server role is installed on the same server as the Mailbox server role.
How the Mailbox Server Role Interacts with Clients and the Client Access Server
Because the clients never communicate directly with the Mailbox server, the Client Access server accepts client requests and sends them to the Mailbox server. The Front End Transport service, which runs on the Client Access server, accepts and sends messages from the Internet, and then forwards them to the Hub Transport service running on the Mailbox server.
The Client Access server also returns the data (content of the client mailbox) from the Mailbox server to the clients. In addition, the Client Access server uses NETBIOS file sharing to access the offline address book (OAB) data from the Mailbox server role. This data is then served to the clients through the OAB virtual directory on the Client Access server. The Client Access server also sends messages, free/busy data, and client profile settings between the client server and the Mailbox server. In previous Exchange Server versions, such as Microsoft Exchange Server 2007 and Exchange Server 2010, internal clients had a direct Messaging Application Program Interface (MAPI) communication with the Mailbox Server role in some scenarios.
For example, when the client was accessing public folders in Exchange Server 2010, it was communicating directly with the Mailbox server role. In Exchange Server 2007, the internal clients were directly communicating with the Mailbox server role, by using MAPI, for all scenarios.
In Exchange Server 2013, clients no longer communicate directly with the Mailbox server role; therefore, both internal and external client communication is proxied through the Client Access server. The Client Access server uses LDAP or the Name Service Provider Interface (NSPI) to contact the Active Directory server and retrieve the user’s Active Directory information.
The Mailbox Store in Exchange Server 2013
In Exchange Server 2013, the primary component of the mailbox store is the mailbox database.
Unlike in previous Exchange server versions, in which public folder databases were also present, Exchange Server 2013 works only with the mailbox databases.
Mailbox Store in Exchange 2013
Mailbox databases contain the data, data definitions, indexes, checksums, flags, and other information that constitute mailboxes in Exchange Server 2013. Mailbox databases hold data that is private to an individual user, and contain mailbox folders generated when a mailbox is created for that user. The mailbox database can be hosted on a single server, or it can be distributed across multiple Mailbox servers if DAGs are deployed.
The mailbox database is stored in a database file, also known as an Exchange database (.edb) file. However, this is not the only file that is related to the mailbox database. Exchange Server 2013 uses a set of data files to host and maintain the mailbox database.
These files are:
• Mailbox database (.edb file). This is the main repository for mailbox data. This file is directly accessed by the Extensible Storage Engine (ESE). It has a B-tree structure that helps to provide quick access and enables users to access data on any page within just one input-output cycle.
• Transaction log (.log file). Each operation that should be performed on a database, such as sending or receiving a message, is recorded in the transaction log file. These operations are called transactions. Operations that are committed to the transaction log are later written to the database itself (in an .edb file). Until the transaction is committed to the mailbox database, the only existence of this data is in the RAM memory and in the transaction logs. All transactions, complete or incomplete, are logged to maintain data integrity in case of a service interruption. Each database has its own set of transaction logs.
• Checkpoint file (.chk). Checkpoint files store data that indicate when a transaction is successfully committed to the database. The purpose of the checkpoint file is to help the ESE to replay log files on an inconsistent database in case of database recovery. By using information from the checkpoint file, the ESE will start with the transaction that is present in the log file, but is not yet written to checkpoint file. Each database’s log prefix determines its checkpoint file name. For example, the checkpoint file name for a database with the prefix E00 would be E00.chk. This checkpoint file is several kilobytes in size and does not grow.
• Temporary file (Tmp.edb). This is a temporary location used for processing transactions. Tmp.edb contains temporary information that is deleted when all stores in the storage group are dismounted or the Exchange Information Store service is stopped. This file does not exceed 1 MB.
• Reserve log files (E##res0001.jrs – E##res000A.log per database, where ## is the log prefix). These files are used to reserve space for additional log files if the disk that stores log files becomes full.
Exchange Server 2013 only uses these files as emergency storage when the disk becomes full, and it cannot write new transactions to disk. When Exchange Server 2013 runs out of disk space, it writes the current transaction to disk, using up the space reserved by the 10 reserve transaction logs, and then dismounts the database. The reserved transaction logs ensure minimal loss of data that is in transit to the database. The reserved transaction logs are always 1 MB each. Although it is important to understand the purpose of each mailbox database file, you will interact directly with these files only rarely. Exchange Server automatically manages these files, so they do not require administrator intervention, except in cases of database backup and restore.
Database Log File Considerations
Each change that is performed on an Exchange Server mailbox database must be logged in a
transaction log file prior to modification of the database. After each transaction is logged to the
transaction log file, it can be written to the .edb file. To enhance performance, changes performed on the database are usually available to users right after they are recorded to the transaction log file.
Database Log Considerations
Exchange Server also caches transactions in RAM memory. This is done for both redundancy and performance reasons. If the database stops, or if the server crashes or experiences any other system outage, Exchange Server scans the log files and reconstructs and applies any changes not yet written to the database file. This process is referred to as replaying log files.
The transaction log is not just one file, but instead is a series of log files. Each transaction log file is exactly 1,024 KB in size. After a transaction log file becomes full, ESE closes it, renames it, and opens a new transaction log file.
The naming syntax for the transaction log file is Enn0000000x.log, where nn refers to a two-digit number known as the base name or log prefix, and x is the sequential number of the log file. It is important to know that log files are numbered in a hexadecimal system, not in a decimal system. For example, the log file that comes after E0000000009.log is not E0000000010.log, but E000000000A.log. Transaction log files are not deleted automatically. Usually, when a database is backed up, the backup software deletes the transaction log files. Because a mailbox database cannot be backed up in the way other files can, it is very important to have Exchange-aware backup software that will properly handle transaction log files when performing backup and restore operations. If the transaction log files are not deleted regularly, they can fill up the disk space, which can cause Exchange services to stop working. We do not recommend manually deleting transaction log files, because that approach can interfere with your regular backup procedure. You can configure Exchange Server to perform circular logging. When the circular logging option is enabled, transaction log files will be overwritten after the transactions from the log file are committed to the mailbox database. However, this approach is not recommended in a production environment, because it affects the ability to back up and restore to the mailbox database. For example, if you have circular logging enabled, you can recover data only up to the time when you performed the last full backup of your database.
If you do not use circular logging, then you are able to use incremental backups, and you
also have the ability to restore the database from the incremental backup. By default, circular logging is disabled.
To properly maintain transaction logs as well as the mailbox database, we recommend that you follow these guidelines:
• Regularly perform Exchange Server backups with Exchange-aware backup software.
• Move transaction logs to a dedicated drive that supports heavy write load.
• Place transaction log files on a redundant disk array, using redundant array of independent disks (RAID) technology. We recommend that you use a RAID 1 volume. However, if you protect your mailbox databases with a DAG, it might be unnecessary to use a dedicated storage for the transaction log files.
• Ensure that the volume that hosts the transaction log files has enough free disk space to store all files created between two backup cycles.
• Do not use compression on drives that store transaction log files.
• Do not use circular logging, except in a test environment.
How Are Mailbox Databases Updated?
Although database modification is an automated process, it is not directly visible to
the administrator or the end user. It is important that you understand how the database is being modified during normal operations.
how are Mailbox Databases Updated
The following process takes place when a Mailbox server receives a message:
1. The Mailbox server receives the message. This occurs when the Hub Transport service
on the Mailbox server accepts the message from the Front End Transport service that is
running on the Client Access server. After the Hub Transport service accepts the message, it is passed to the Mailbox Transport service.
2. Before the message is written to the databases, the Mailbox server writes the message to the current transaction log and the memory cache simultaneously.
3. The Mailbox server writes the transaction from the memory cache to the appropriate database.
4. The Mailbox server updates the checkpoint file to indicate that the transaction was committed successfully to the database.
5. Client Servers can access and read the message in the database.
Storage Options for the Exchange Server 2013 Mailbox Server Role
Exchange Server 2013 supports various hardware technologies for disk storage, including Serial
Advanced Technology Attachment (SATA), Solid-state drive (SSD), and Serial Attached small
computer system interface (SCSI), known as SAS (Serial Attached SCSI) or iSCSI drivers. When
selecting which storage solution to use, the goal is to ensure that the storage will provide the
performance that your environment requires. In Exchange Server 2013, disk I/O is further reduced compared to previous versions of Exchange Server. This enables you to use less expensive, slower disks and storage systems without any significant decrease in performance. When choosing a storage technology for Exchange Server, the most common choices are, DAS, SAN, or RAID.
DAS
Direct attached storage (DAS) is any disk system that is physically connected to your server. This includes hard disks inside the server or those that are connected by using an external enclosure. Some external enclosures include hardware-based RAID. For example, external disk enclosures can combine multiple disks in a RAID 5 set that appear to the server as a single large disk. In general, DAS provides good performance, but it provides limited scalability because of the unit’s physical size. You must manage direct attached storage on a server-by-server basis. Exchange Server 2013 performs well with the scalability and performance characteristics of DAS.
DAS provides the following benefits:
• Lower-cost Exchange Server solution. Direct attached storage usually provides a substantially lower purchase cost than other technologies.
• Easy implementation. Direct attached storage typically is easy to manage, and requires very little training.
• Distributed failure points. Each Exchange server has separate disk systems, so the failure of a single system does not affect the entire Exchange messaging system negatively, assuming that you configure your Exchange servers for high availability.
SAN
A storage area network (SAN) is a network dedicated to providing servers with access to storage
devices. A SAN provides advanced storage and management capabilities, such as data snapshots and high performance. SANs use either Fibre Channel switching or Internet SCSI (iSCSI) to provide fast and reliable connectivity between storage and applications. Fibre Channel switching or iSCSI allows many servers to connect to a single SAN.
Fibre Channel is a standard SAN architecture that runs on fiber optic cabling. Most SANs use it because Fibre Channel is used specifically for SANs, and it is the fastest architecture available.
SANs are complex and require specialized knowledge to design, operate, and maintain. Most SANs also are more expensive than DAS options.
SANs provide the following benefits:
• A large RAM cache that keeps disk access from becoming a bottleneck. The reduced I/O requirements of Exchange Server 2013 make it more likely that an iSCSI-based SAN will meet your requirements in small and medium-sized deployments. However, you should test all hardware configurations thoroughly before deployment to ensure that they meet your organization’s required performance characteristics.
• Highly scalable storage solutions. Messaging systems are growing continually and require larger storage over time. As your needs expand, a SAN allows you to add disks to your storage. Most SANs incorporate storage virtualization, which allows you to add disks and allocate the new disks to your Exchange server.
• Multiple servers attached to a single SAN. If you use a SAN, you can connect multiple computers that are running Exchange Server, and then divide the storage among them.
• Enhanced backup, recovery, and availability. SANs use volume-mirroring and snapshot backups. Because SANs allow multiple connections, you can connect high-performance backup devices to the SAN. SANs also allow you to designate different RAID levels to different storage partitions. For cost-conscious SAN implementations, iSCSI may be a viable option. An iSCSI network encapsulates SCSI commands in TCP/IP packets over standard Ethernet cabling and switches. You should implement this technology only on dedicated storage networks that are 1 gigabit per second (Gbps) or faster.
RAID
To provide redundancy on any storage options, you have to use RAID technology. RAID can be used to provide better disk performance or fault tolerance. The most common RAID options are:
• RAID 0 (striping). Increases read and write performance by spreading data across multiple disks. However, it offers no fault tolerance. Performance increases as you add more disks. You add fault tolerance by using multiple copies of the databases on separate RAID sets.
• RAID 1 (mirroring). Increases fault tolerance by placing redundant copies of data on two disks. Read performance is faster than a single disk, but write performance is slower than RAID 0. Half of the disks are used for data redundancy.
• RAID 5 (striping with parity). Increases fault tolerance by spreading data and parity information across three or more disks. If one disk fails, the missing data is calculated based on the remaining disks. Read and write performance for RAID 5 is slower than with RAID 0. At most, only one third of the disks are used to store parity information.
• RAID 0+1 (mirrored striped sets). Increases fault tolerance by mirroring two RAID 0 sets. This provides very fast read and write performance, and excellent fault tolerance.
• RAID 6 (striping with double parity). Increases fault tolerance by spreading data and parity information across four or more disks. If up to two disks fail, RAID 6 calculates the missing data based on data and parity information stored on the remaining disks. Read and write performance for RAID 6 typically is slower than RAID 0, and RAID 6 does not have a read penalty. The main benefit of RAID 6 is the ability to rebuild missing data if you have two failures per RAID group, and to reduce the impact of rebuilding the RAID set when a disk fails.
• RAID 1+0 or RAID 10 (mirrored sets in a striped set). Provides fault tolerance and improved
performance, but increases complexity. The difference between RAID 0+1 and RAID 1+0 is that RAID 1+0 creates a striped set from a series of mirrored drives. In a failed-disk situation, RAID 1+0 performs better and is more fault tolerant than RAID 0+1.
• Just a bunch of disks (JBOD). JBOD is a collection of disks that have no redundancy or fault tolerance. JBOD solutions are usually lower in cost than solutions that use RAID. JBOD adds fault tolerance by using multiple copies of the databases on separate disks, which you can use when you protect your databases with DAGs.
Importing and Exporting Data from a Mailbox Database
In some scenarios, you might want to export data from the user’s database or import data
to the user’s database. For example, because of compliance or legal reasons, you may be required to export mailbox content from a specific user to a personal storage file (.pst) file. For other purposes, you might want to perform a snapshot of a specific mailbox.
In yet another scenario, you might want to import data from a .pst file from a legacy application to a user’s mailbox on the Exchange Server. For example, if a user was using a Windows Mail
application, all of the user’s data was being stored in a .pst file. It is common to import data from the user’s .pst file to the user’s new mailbox on the Exchange Server, or to the user’s archive mailbox.
In Exchange Server 2013, you can use the New-MailboxImportRequest or NewMailboxExportRequest cmdlets to import or export data from the user’s mailbox. Requests for mailbox import or export must be executed from the Exchange Management Shell. After you run one of these cmdlets, the process is completed asynchronously by the Microsoft Exchange Mailbox Replication service. This service takes advantage of the queuing and throttling frameworks to optimize Exchange performance during import or export operations.
Note: To use the New-MailboxImportRequest or New-MailboxExportRequest cmdlets,
the “Mailbox Import Export” role must be assigned to you. By default, this role is unassigned.
Exchange Server 2013 includes a personal folders file (.pst) provider, so it can natively read and write .pst files. The .pst files can be stored locally or they can reside on a shared folder. However, if you are using share folders as a .pst location, you must ensure that you grant read/write permissions to the Exchange Trusted Subsystem group for the specific shared folder.
Exchange Server 2013 supports only Unicode files created by Office® Outlook 2007, Outlook 2010 and newer versions. Data from a .pst file can be imported to a user’s mailbox or to an online archive if it is enabled for a user’s mailbox. In addition, Exchange Server 2013 can import or export multiple .pst files at the same time, which can speed up the process. However, the import or export process can take several hours to complete, depending on the file size and network bandwidth. Note: The maximum supported size for a .pst file is 50 gigabytes (GB). If a mailbox that you want to export is larger than 50 GB, you can create multiple .pst files. You can use filters to specify selected folders for export instead of the entire mailbox. You can also include or exclude specific folders using the IncludeFolders or ExcludeFolders parameters.
When you import data from a .pst file, you must ensure that the mailbox exists prior to starting the import process. You can import data to a different user account than the one from which it was exported.
This concludes this post by David Papkin about configuring Mailbox Servers in Microsoft Exchange 2013.