Managing Exchange Store Resources

Active Directory is not the only communication partner of Exchange System Manager. Various Exchange System Manager snap-ins also communicate with the Exchange store. These enable you to display real-time information about Exchange store resources and to manage public folders. Exchange System Manager uses MAPI to display mailbox statistics and client logons. It uses Distributed Authoring and Versioning (DAV) protocol to display and manage public folder resources.

MAPI-Based Communication

The following figure illustrates the difference between mailbox store and public folder store objects in Active Directory and Exchange System Manager. In Active Directory Sites and Services, mailbox store and public folder store objects are represented by leaf nodes that do not contain child objects. In Exchange System Manager, however, mailbox store and public folder store objects are represented as nodes in the console tree. They contain several child containers, such as Logons, Mailboxes or Public Folders, Public Folder Instances, Replication Status, and Full-Text Indexing.

Mailbox and public folder store objects in Active Directory Sites and Services and Exchange System Manager

Information Obtained Through the IExchangeManageStore Interface

The child containers under mailbox store and public folder store objects are virtual containers that do not exist in Active Directory or elsewhere. To display these containers, Exchange System Manager must communicate with the Exchange store through the IExchangeManageStore interface, which is an internal MAPI-based interface. This MAPI communication is dynamic in nature and occurs when you expand a particular mailbox store or public folder store in Exchange System Manager. You cannot display the child containers of a mailbox store or public folder store if the mailbox store or public folder is dismounted. Communication through MAPI also occurs when you add mailbox stores or public folder stores to an Exchange server, when you display the properties of an individual mailbox store or public folder store, and when you mount or dismount mailbox stores or public folder stores.

Exchange System Manager calls the following IExchangeManageStore methods to obtain dynamic information about mailbox and public folder stores:

• GetMailboxTable   The GetMailboxTable method obtains information about all mailboxes in a mailbox store. This method returns a pointer to a MAPI IMAPITable interface, which contains information about all the mailboxes in the specified Exchange store. Each row in this MAPI table represents an individual mailbox. The columns in the table provide detailed information about the mailbox, such as the name, number of messages, message sizes, the Windows user account name of the last user to log on to the mailbox, and the date and time when the user last logged on. Additionally, columns indicate whether a mailbox is currently within storage limits.

• GetPublicFolderTable   The GetPublicFolderTable method obtains information about all public folders in a public folder store. This method returns a pointer to a MAPI IMAPITable interface, which contains information about all public folders in the specified Exchange store. Each row in this MAPI table represents an individual public folder. The columns in the table provide detailed information about the public folder, such as the name, number of associated messages, sizes (in bytes) of all associated messages, number of associated messages with attachments, number of cached columns and categorizations on the public folder, number of public folder contacts, date and time that the replica of a public folder was accessed, and date and time that an object in the public folder was last modified.

Exchange System Manager and MAPI-Based Clients

Because Exchange System Manager uses MAPI to obtain dynamic information from the Exchange store, do not install MAPI-based clients, such as Microsoft Outlook, on an Exchange server or workstation running Exchange System Manager. Exchange System Manager uses Mapi32.dll to communicate with the Exchange store. Mapi32.dll represents a core component of the MAPI subsystem and is located in the Winnt\System32 folder. If you install Microsoft Office Outlook 2000 or later on the same computer that contains Exchange System Manager, the MAPI subsystem moves to the Program Files\Common Files\System\Mapi\1033\NT folder. Typically, Outlook installs a stub version of MAPI in the Winnt\System32 folder, which then routes MAPI calls to the Outlook implementation. If you replace the Exchange Server 2003 version of Mapi32.dll with the Outlook implementation, your system could experience version conflicts in the MAPI subsystem and could cause Exchange System Manager to fail.

DAV-Based Communication

To create, manage, and delete public folder resources, Exchange System Manager (specifically the Public Folders snap-in) uses DAV to communicate with the Exchange store. DAV is an HTTP-based protocol. Therefore, access to the Exchange store is provided through the World Wide Web Publishing service (w3svc). DAV commands, such as PROPFIND, SEARCH, DELETE, MOVE, COPY, and OPTIONS, are encoded using XML.

DAV-Based Communication and HTTP Virtual Directories

By default, Exchange Server 2003 creates the following HTTP virtual directories on an Exchange server:

• Exchweb   Stores graphics and additional files required for Microsoft Office Outlook Web Access for Exchange Server 2003. This is a standard virtual directory that points to the \Program Files\Exchsrvr\Exchweb directory on the server's hard disk.

• Exchange   Used by Outlook Web Access for mailbox access. This virtual directory binds to the URL \\.\BackOfficeStorage\<server's fully qualified domain name>\mbx.

• Public   Used by Outlook Web Access for public folder access. This virtual directory binds to the URL \\.\BackOfficeStorage\<server's fully qualified domain name>\public folders.

• Exadmin   Used by Exchange System Manager to administer public folders. This virtual directory binds to the URL \\.\BackOfficeStorage.

For Exchange System Manager, the most important HTTP virtual directory is the Exadmin virtual directory. Exadmin provides access to all public folder hierarchies, also named public folder trees, on an Exchange server. This access is enabled because Exadmin points directly to the BackOfficeStorage namespace. To provide access to all mailbox and public folder stores on an Exchange server, the Exchange OLE DB (ExOLEDB) provider registers the BackOfficeStorage namespace with the OLE DB RootBinder. When you expand the public folder hierarchy or create, manage, or delete public folders in Exchange System Manager, communication occurs through the Exadmin virtual directory.

Exchange System Manager also uses other HTTP virtual directories. For example, Exchange System Manager uses the Public virtual directory to display the content of MAPI-based public folders. The Public virtual directory exists on all Exchange servers. However, if you create an additional general-purpose public folder tree and associate it with an additional public store, Exchange System Manager cannot display public folder contents until you create a virtual directory to provide HTTP-based access to this hierarchy. For more information about how to create and configure public folder hierarchies and stores, see the Exchange Server 2003 Administration Guide.

The following figure shows the content of a public folder, as it appears in Exchange System Manager.

The content of a MAPI-based public folder in Exchange System Manager

Exchange System Manager and the Exadmin Virtual Directory

Most of the interaction between the Public Folders snap-in in Exchange System Manager and the Exchange store is done through the Exadmin virtual directory. Exadmin relies on the ExOLEDB provider, which is a component that is not remotable. Exchange System Manager must access the Exadmin virtual directory on the Exchange server that hosts the public store associated with the public folder hierarchy. This server is determined with information obtained from the directory object that corresponds to the public folder hierarchy. The following figure illustrates how Exchange System Manager communicates with an Exchange store through the Exadmin virtual directory.

Communicating with a public store through the Exadmin virtual directory

Exchange System Manager performs the following steps when it connects to the Exadmin virtual directory:

1. Obtains list of Exchange stores from hierarchy object   Exchange System Manager reads the msExchOwningPFTreeBL attribute of the public folder hierarchy object in Active Directory. This determines the list of Exchange servers that host public stores associated with the public folder hierarchy.

   Tip

   You can see the Exchange stores as listed in the msExchOwningPFTreeBL attribute when you display the properties of the public folder hierarchy in Exchange System Manager. The stores are listed on the General tab, under Public stores associated to the folder tree.

2. Selects target server and retrieves Exadmin binding information   Exchange System Manager selects a server that contains a replica of the public folder hierarchy and then reads the configuration information of that server's Exadmin virtual directory. The Exadmin virtual directory is represented in Active Directory by a directory object, named Exadmin, which resides under the server's default HTTP virtual server, named Exchange Virtual Server. The msExchServerBindings attribute of that directory object contains the TCP port number that Exchange System Manager must use to connect to the Exadmin virtual directory on the Exchange server that hosts the public folder hierarchy. If this attribute is not set, Exchange System Manager uses the default TCP port 80.

   Note

   If you are running Exchange System Manager locally on an Exchange server that hosts a public store associated with the public folder hierarchy, Exchange System Manager tries to connect to the local server first.

3. Uses binding information to connect to the Exadmin virtual directory   Exchange System Manager uses the TCP port number obtained from the msExchServerBindings attribute to connect to the Exadmin virtual directory on the selected Exchange server. It then requests a list of all top level public folders in the hierarchy. In the HTTP User-Agent header of the HTTP request, Exchange System Manager identifies itself as an Exchange Admin client. Internet Information Services (IIS) authenticates the client and returns the list of top level public folders to Exchange System Manager.

4. Displays the top level public folders   Exchange System Manager displays the top level public folders as container objects in the console tree, under the public folder hierarchy. This step is not illustrated in the figure above.

   Note

   By default, only the top level folders in the interpersonal message (IPM) subtree are displayed, but you can also display the folders in the non-IPM subtree, if you right-click the hierarchy object and then select View System Folders.

Connecting to a Specific Exchange Server

You can associate a public folder hierarchy with public folder stores from multiple Exchange servers. When you do this, the hierarchy is replicated between these public stores automatically. This replication makes sure that all public folder stores are aware of all public folders in the hierarchy. Therefore, you can connect to any one of these Exchange servers to manage public folder resources. In fact, changing from one server to another enables you to verify that all public stores have a consistent view of the hierarchy. For example, you might want to do this when diagnosing problems related to hierarchy replication. For detailed instructions about how to connect to a specific Exchange server, see How to Connect to a Specific Exchange Server in Exchange System Manager.

Exchange System Manager and the Default Web Site

Whether you specify a public folder store to connect to or let Exchange System Manager make the choice for you, the connection mechanisms remain the same, as discussed earlier in this section. However, the Exadmin virtual directory must be located on the Exchange server in the default Web site of IIS. In IIS Manager, make sure that IP Address is set to (All Unassigned), TCP port is set to 80, and that Host header value is not specified. This is because Exchange System Manager attempts to connect to TCP port 80 by default and specifies the name of the Exchange server in the Host header value of the HTTP requests. If you specify a Host header value for the default Web site in IIS Manager that is other than the server name, Exchange System Manager cannot access the Exadmin directory. Therefore, you receive an error message that states that the operation failed due to an invalid format in the HTTP request. You cannot manage public folder resources, although you might be able to access public folders in Outlook Web Access. For more information about issues with accessing the Exadmin virtual directory, see Knowledge Base article 325920, "Error Message When You View Public Folders in Exchange System Manager."

However, you can assign the default Web site that hosts the Exadmin virtual directory a dedicated IP address and a custom TCP port using IIS Manager. When you display the properties of the Web site, specify an IP address or custom TCP port on the Web Site tab. Exchange System Manager tries to connect to TCP port 80 first. If this connection attempt fails, Exchange System Manager communicates with the IIS Admin service on the Exchange server through remote procedure calls (RPCs), to determine the required port number. The IIS Admin service returns the custom port number to Exchange System Manager, because it is registered in the IIS metabase. Exchange System Manager then registers the custom port in the msExchServerBindings attribute of the Exadmin directory object. After this, Exchange System Manager connects to the Exadmin virtual directory, as discussed earlier in this section.

Communication with the IIS Admin service fails if RPCs are not supported between the Exchange server and the computer that is running Exchange System Manager. For example, a firewall blocking access to the RPC Endpoint Mapper through TCP port 135 might prevent this communication. In this case, Exchange System Manager cannot determine the custom port dynamically. It is best to use the default port number 80 for the Exadmin virtual directory.

The Exadmin Virtual Directory and SSL Encryption

The Exchange Server 2003 version of Exchange System Manager fully supports Secure Sockets Layer (SSL). Therefore, you can install an SSL certificate on your Exchange server and enforce SSL encryption over HTTP, which protects Exchange Server 2003 virtual directories, such as Public and Exadmin. Enforcing a secure communications channel is a good idea if the Exchange server and the computer that is running Exchange System Manager must communicate with each other over a public or untrustworthy network segment.

The following figure illustrates how the process of connecting to an Exadmin virtual directory through HTTP over SSL (HTTPS) works.

Connecting to Exadmin through HTTPS

When connecting to the Exadmin virtual directory over HTTPS for the first time, Exchange System Manager performs the following steps:

1. Exchange System Manager tries to connect over HTTP, as explained earlier in this section.

2. Because HTTPS is required for the Exadmin directory, the Web server responds to the HTTP request with an HTTP status code of 403 – Forbidden.

3. Exchange System Manager queries the IIS Admin service through RPCs for SSL-specific information, such as the SSL port that must be used to connect to the Web site that hosts the Exadmin virtual directory. The IIS Admin service returns this information to Exchange System Manager.

4. Exchange System Manager connects to the Exadmin virtual directory through HTTPS and displays the list of public folders in the hierarchy.

   Note

   The security certificate that you register for the Web site that hosts the Exadmin virtual directory must list the local Exchange server's fully qualified domain name (FQDN) as the Web site's common name. Also, the computer that is running Exchange System Manager must trust the certificate authority that issued the SSL certificate. Otherwise, Exchange System Manager displays an error message that states that the SSL certificate is incorrect, and does not display the public folder hierarchy.

5. Exchange System Manager writes the SSL port number in the msExchSecureBindings attribute of the directory object that corresponds to the Exadmin virtual directory. On subsequent connections, you do not have to run the algorithm to obtain the SSL port number from the server.