The .edb File The .edb file is the main repository for the mailbox data.

The fundamental construct of the .edb file is the b-tree structure, which is only present in this file, and not in the .stm file. The b-tree is designed for quick access to many pages at once. The .edb file design permits a top level node and many child nodes. In a b-tree, each child node can have only a single parent. Although the typical b-tree allows unlimited depth, Microsoft restricts the depth of the b-trees in most of its applications to facilitate quick access by whatever engine happens to be working with it. By allowing for such a high spread and low tree depth, Exchange and ESE can guarantee that users can access any page of data, called a leaf node, within four I/Os. Tree depth has the greatest effect on performance. A uniform tree depth across the entire structure, where every leaf node or data page is equidistant from the root node, means database performance is consistent and predictable. In this way, the ESE 4 KB pages are arranged into tables that form a large database file containing Exchange data. The database is actually made up of multiple b-trees. These other ancillary trees hold indexing and views that work with the main tree. The .edb file is accessed by ESE directly. The .stm File The .stm or streaming media file is used in conjunction with the .edb file to comprise the Exchange database. Both files together make up the database, and as such, they should always be treated as a single entity. Typically, if you perform an action on the .edb file, such as with Exchange Server Database Utilities (Eseutil), the .stm file is automatically included. The purpose of the .stm file is to store streamed native Internet content. To understand what that means, you should first understand the way in which legacy Exchange products handled data with only a single file. In Exchange Server 5.5, for example, the Internet Mail Connector accepts inbound Multipurpose Internet Mail Extensions (MIME) messages and writes them to a disk queue where Exchange then converts them to the native MAPI content or MDBEF for use by the Information Store and MAPI clients. Then if an Internet API, such as Post Office Protocol version 3 (POP3) or IMAP4 requests the data, it is converted back again before being sent out. This back-and-forth conversion process can cause overhead and performance issues. The streaming media file helps to alleviate some of this conversion. Unlike the .edb file mentioned previously, the .stm file does not store data in a b-tree structure. When a message arrives through the Internet or Simple Mail Transfer Protocol (SMTP), it always arrives as a stream of bytes. In Exchange Server 2003 and Exchange 2000 Server, these messages are streamed directly to the .stm file where they are held until accessed by a MAPI client. So the content is not converted. That way, if

the end user is consistently accessing mail through POP3, the mail items are pulled directly from the .stm file and are already in the proper state for delivery. In the case that the message is accessed by a MAPI client, however, the message is moved over to the .edb file and converted to Exchange native form, and is never moved back to the .stm file. If the .stm file is missing or corrupt, it can be reconstructed. This may be a catastrophic loss, depending on the situation. If end users work in a non-MAPI environment, they may lose a great deal of data. To accomplish the reconstruction, you may use the /createstm switch of the Eseutil tool. Because the actual content is stored in the .stm file, but the pointers and header information for the messages are stored in the .edb file, the tool rebuilds the .stm file using that information, but without the content.

Summary The .edb and .stm files combine to make up the Exchange database. The .edb file stores all the data accessed by MAPI clients, and after a piece of data is moved to the .edb file and transformed into the Exchange native format, it stays that way. The .stm file houses all the content streamed over the Internet. Internet mail destined for review by a MAPI client first arrives through SMTP to the .stm file before it is promoted to the .edb file. If a message originates from another Exchange server, but is transported by SMTP, it is streamed into the STM and goes through an immediate promotion to the EDB. If the mail is never accessed by a MAPI client, it will stay in its native form in the .stm file. The splitting of these two files and the roles they play significantly reduce the hefty conversion overhead legacy Exchange products endured.