Understanding EXOLEDB Default Folders


Topic Last Modified: 2006-01-11

By Jason Nelson

This article describes the different EXOLEDB folders on the Microsoft® Exchange server and explains the purpose of the folders.

EXOLEDB creates a number of system folders under the NON_IPM_SUBTREE during the Accept Clients phase of message database (MDB) initialization. Some of the folders remain for historic reasons, but most have useful purposes. If the folders are deleted, it can affect the server. None of these folders should be replicated. The folders that are created include the following:

  • \NON_IPM_SUBTREE\schema-root\

  • \NON_IPM_SUBTREE\schema-root\Default

  • \NON_IPM_SUBTREE\schema-root\Microsoft\

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views

  • \NON_IPM_SUBTREE\StoreEvents\

  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents

  • \NON_IPM_SUBTREE\StoreEvents\Internal


In all cases, subfolders named with the GUID correspond to the MDB object with the same GUID.

The first folders created are the schema folders.

The following list introduces the schema-root:

  • \NON_IPM_SUBTREE\schema-root\

    This was introduced in Exchange 2000 Server.

  • \NON_IPM_SUBTREE\schema-root\Default

    This was introduced in Exchange 2000 Server Service Pack 1 (SP1).

  • \NON_IPM_SUBTREE\schema-root\Microsoft\

    This was introduced in Exchange 2000 Server SP1.

  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1

    This was introduced in Exchange 2000 Server SP1.

The following shows a typical schema path for a public MDB:

  • File://.BackOfficeStorage/<domain>/<TLHName>/NON_IPM_SUBTREE/schema-root/microsoft/exchangeV1

The private MDB schema path is under the system attendant mailbox.

EXOLEDB supports multiple schemas, or property type definitions. These folders support the Exchange Web Store development platform. The idea was that folder items could reference various versions of the schema and exist alongside each other. At one point in Exchange 2000 Server, schema files were in the schema root folder, and changes to the schema effectively propagated to all items. Because this lead to problems in the application development workspace, where each item needed to be handled to remove or add props as appropriate, Microsoft adopted a versioning method. Under schema-root, Microsoft creates subfolders with application and version elements to allow effectively seamless upgrades. EXOLEDB watches the schema folders for changes, so that it can propagate the entries, dump the schema cache, and repopulate as processing occurs. The \schemaroot\default folder is where normal folder items obtain their schema, and the schema-root folder is flagged as pointing to the ExchangeV1 folder. EXOLEDB populates the schema entries from the .xml files, which are processed by an event sink, EXSCHEMA.EXE. The schema event sink binding cannot be deleted or removed, because it does not have an entry in the EventBindings folder like most events.

The following list introduces EXCHWEB, views, IMG, and controls:





Introduced in Exchange 2000 Server SP1, these items were not populated in Exchange 2000 Server Service Pack 3 (SP3), and they are not populated in Exchange Server 2003.

For the local store to open items that reference Microsoft Outlook® Web Access control functionality, the files must be in a folder that can be synchronized. These folders once contained copies of the Web data for Outlook Web Access to allow LIS stored items to open, but have never actually been used outside of LIS.

Next, EXOLEDB starts the event binding system, which creates StoreEvents.

All store event folders described in the following list have been present since Exchange 2000 Server:

  • \NON_IPM_SUBTREE\StoreEvents\

  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents

  • \NON_IPM_SUBTREE\StoreEvents\Internal

This is the event binding folder, where EXOLEDB stores information on events built to a specific MDB. At startup, EXOLEDB must enumerate the events here, which can lead to long store startup times with large event sink numbers. Exchange Server 2003 performance in this area is greatly improved, but time to mount an MDB is still affected by the number of rows. Each binding is validated for class, having a valid event method, such as onsave or ontimer, valid clsid, and sink parameters. Events with a match class of ANY can only be registered in the GlobalEvents subfolder.

After creating the schema folders and starting the event bindings system, EXOLEDB creates the Outlook Web Access scratch pad.

The OWAScratchPad was introduced in Exchange 2000 Server SP1. It appears as follows:


Posts have to start out somewhere to have attachments, and for public store logons, that place is the Outlook Web Access scratch pad. Because Distributed Authoring and Versioning (DAV) does not cross MDB operations, you need a point on every mailbox where you can always write posts to, so that you can support adding attachments. The posts are staged in the OWAScratchPad until all attachments are added, or they are saved. The size limit on the Outlook Web Access scratch pad controls the size of attachments that can be added through Outlook Web Access. Attempts to post larger messages should result in the following error:

  • This item exceeds the maximum size defined for this folder and cannot be saved. Contact your administrator to have the folder limits increased.

The size of OWAScratchPad is always reset to 1 megabyte (MB) at EXOLEDB initialization if the registry key HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA REG_DWORD value "Message Size Limit" is not set. This is required for Microsoft SharePoint® Portal Server, because EXOLEDB has no idea if you are running in magma mode.

Outlook Web Access posts to the scratch pad are done in flat URL format, meaning they directly reference the folder and message. This is to support deep vroots where the friendly URL might be too long.

Consider the following frequently asked questions (FAQs).

There are two categories for this question:

  • Active Directory objects   When a store is deleted, you have no way to tell Active Directory that the public folder objects went away. Then, when folders are re-created, they do not get attached to the corresponding Directory Service objects. New Directory Service objects are created.

  • Actual folders   If the folders are set to replicate, and the store in question is deleted, EXOLEDB will re-create the folders on startup, and replication can then create a second duplicate of any such folders. This causes problems with event bindings. Deleting the duplicate folders through friendly URLs is dangerous, because the two will often have duplicate friendly URLs.

When the number of system folders with the same number grows, a random number is appended to the Directory Service proxy to make it unique, resulting in names like controls12345678.

If you were to delete the folders, EXOLEDB would put them back. Also, most of these folders have uses that will adversely affect the operation of the server if not present.

If schema folders are missing, that is, not present under the ipm subtree, setting the following registry key to a REG_DWORD value of 0, causes the schema to be repopulated:


EXOLEDB automatically grants everyone read access to schema folders. This access control list (ACL) could be modified, but would be deleted if schema propagation were re-triggered.

You do not have to replicate folder content as part of the replicate system folders procedures.

For more information, see the following Exchange blog entry: