| Platform SDK: Exchange 2000 Server |
[This is preliminary documentation and subject to change.]
ExOLEDB registers with the OLE DB RootBinder to support both a public and private namespace in a local Exchange private and public Information Stores. Both namespaces are prefixed by "file://./backofficestorage". This is static—it cannot be changed by system administration or any other means. The public namespace is:
"file://./backofficestorage/DomainName/TLHName"
This is for all public folder databases, including the default MAPI public folder database. DomainName represents the fully qualified domain name for the organization. TLHName stands for top-level-hierarchy (i.e., the top of the information store for a particular MDB). For example:
"file://./backofficestorage/microsoft.com/documents"
Top Level Hierarchies beyond the default MAPI public folder TLH are not visible to Outlook2000 and prior MAPI clients.
The private namespace is:
"file://./backofficestorage/DomainName/MBX/UserName"
This namespace is for all private databases. The UserName string is the part of the address string that comes before the "@" of the user's proxy address. For example:
"file://./backofficestorage/microsoft.com/MBX/user1"
Note that there is a URL per domain—not a URL per private database. Note that by having the URL per domain, the user can change their private MDB without changing the URL to the mailbox. The DomainName is the part of the user's proxy address that follows the @. By including this domain name in the private form, exchange is able to distinguish the URL for mailto:user1@microsoft.com and mailto:user1@microsoft2.com.
The store will notify the ExOLEDB provider when a new database is created. Also, a directory listing at the "file://./backofficestorage" level will return the list of organizations. A directory listing at the "file://./backofficestorage/DomainName" will return the list of TLHs for the specified domain or organization, including the static "MBX" string, which represents private mailboxes. A directory listing at the "file://./backofficestorage/DomainName/MBX" will return an empty list—in order to preserve mailbox privacy. However, a directory listing of a specific user, such as "file://./backofficestorage/DomainName/MBX/UserName", will give a list of the top-level folders within the IPM sub-tree (e.g., Inbox, Outbox, Deleted Items, etc.). One can change to any of these directories and continue to navigate down the folder hierarchy.
Access to a user's NON-IPM sub-tree is via the URL "file://./backofficestorage/DomainName/MBX/UserName/NON_IPM_SUBTREE". The NON-IPM sub-tree is not visible in a directory listing of a user mailbox. The only way to access the NON-IPM sub-tree is to explicitly change directory to the NON-IPM folder. Once bound to the NON-IPM folder, one can get a directory listing of the folders under the NON-IPM folder for a particular user.
Access to a public Top-Level Hierarchy NON-IPM sub-tree is similar via the URL "file://./backofficestorage/DomainName/TLHname/NON_IPM_SUBTREE". The behavior is the same as described for private databases.
Here are some additional examples for further clarification:
Result List of TLH's plus an MBX folder
Result List of folders under TLH1
Result MBX folder
Result empty directory
Result command fails
Result lists the top-level folders in the NON-IPM-SUBTREE for this user. Note that the NON-IPM-SUBTREE is not visible in a normal directory listing of //./backofficestorage/<DomainName>/MBX/<username> - one must specify the NON-IPM-SUBTREE explicitly to get it's contents.
Result lists the top-level folders in the NON-IPM-SUBTREE for TLH1 - same rules about visibility as stated in Example6