Exploring Exchange 2000's ExIFS

Find out about the little-known Exchange 2000 Server Installable File System.

I'm often asked about Exchange 2000 Server's little-known Exchange Installable File System (ExIFS) component. Just what is this little piece of Exchange 2000, what does it do, and what does it mean to you as an Exchange administrator?

ExIFS's inclusion in Exchange 2000 is largely the "fault" of Internet clients—clients that access Exchange through POP3, IMAP4, SMTP, or Network News Transfer Protocol (NNTP). Regardless of the type of client, Exchange Server 5.5 converts Information Store (IS) content to Exchange's native format (i.e., rich text, or Transport Neutral Encapsulation Format—TNEF). This resource-intensive conversion process is called IMAIL. Exchange 5.5 then stores all message content (i.e., body and attachments) in the database (i.e., the property store, or .edb file).

In Exchange 2000, Microsoft decided to rearchitect the way Exchange handles message content from Internet clients. Exchange 2000 writes Internet clients' content directly to the streaming store (the .stm file that Microsoft added to the database in Exchange 2000). Microsoft could have had the Extensible Storage Engine (ESE) manage the streaming store file. However, this approach would have required quite a bit of server overhead and would have been architecturally difficult. Instead, Microsoft chose to implement an Installable File System (IFS) for Exchange 2000—ExIFS—to manage access to the streaming store file. When ESE needs to access the streaming store content, it does so through ExIFS. Likewise, Microsoft IIS (which hosts Internet protocols for Exchange 2000) directly interacts with ExIFS to write native Internet content to the Exchange Store. Thus, ExIFS handles all Internet content in the Exchange 2000 Store.

For ExIFS to keep up with the demands that the ESE and IIS place on it, it must be very efficient and high performing. Therefore, Microsoft implemented ExIFS as a kernel-mode device driver. The ExIFS driver (exifs.sys) loads as part of the kernel code and, as a result, is fast and efficient (although kernel-mode drivers are potentially dangerous if poorly written). IIS pumps data from its hosted Internet protocols through TCP/IP sockets to the Windows File System Cache, then into the streaming store file. ExIFS manages this data path as ExIFS operates in kernel mode with TCP/IP and the Windows Cache Manager. ExIFS also can communicate with ESE (in the STORE process) through a clever mechanism called a user-mode reflector, which lets store.exe (running in user mode) pass information to the ExIFS driver (running in kernel mode). This mechanism lets ESE and ExIFS coordinate and manage data and access to the streaming store file. Although ESE doesn't directly control the streaming store file, it can include it as an integral part of the Exchange Store—with the help of ExIFS.

ExIFS provides other benefits, but they tend to be double-edged swords of sorts. First, ExIFS exposes Exchange Store content to developers through common Win32 file system API calls. However, this feature also exposes the M drive as a file share on your Exchange 2000 server through the Server Message Block (SMB) protocol. Such exposure can cause more harm than good. When Exchange 2000 debuted, many enterprising Exchange administrators thought they could simply back up the M drive for Exchange disaster-recovery purposes. This action isn't the intended purpose of the feature and isn't an effective method of backing up Exchange 2000. As a result of the confusion that exposing the M drive caused, Microsoft has chosen to disable this feature by default in the most recent Exchange 2000 builds. (For information about manually removing this mapping, see this week's featured Exchange HOW TO in the Resources section below.)

Second, because ExIFS is a kernel-mode component and is outside the context of the Store process, it doesn't employ the same memory-management techniques as ESE. Instead of using the extensive Store buffer cache that's part of the STORE process, ExIFS uses the traditional Windows File System cache, which Windows Cache Manager manages. As a result, I/O requests to the streaming store files have different characteristics than requests to the property store (.edb file) do. This difference can make storage-system design, capacity planning, and optimization a challenge when your Exchange 2000 server hosts both MAPI and Internet protocol clients. Also, because ExIFS uses the Windows File System cache, the greater demands on that facility can create problems if other applications running on your Exchange server make use of the same cache.

Overall, Exchange 2000's ExIFS provides huge benefits and solves a big problem relative to native Internet content storage. Despite this kernel-mode component's potential problems, the benefits outweigh the costs and risks. So there you have it—the next time your spouse or significant other asks you over dinner about the pros and cons of the mysterious ExIFS, you're armed and ready!