EXOLEDB creates a number of system folders under the NON_IPM_SUBTREE during the Accept Clients phase of MDB initialization. Some of the folders remain for historic reasons, but most have real purposes and impact on the server should they be deleted. None of these folders should ever be replicated. The folders that are created are:
\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
\NON_IPM_SUBTREE\OWAScratchPad
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:
Schema-Root
\NON_IPM_SUBTREE\schema-root\ - introduced in Exchange 2000 RTM.
\NON_IPM_SUBTREE\schema-root\Default - introduced in Exchange 2000 SP1
\NON_IPM_SUBTREE\schema-root\Microsoft\ - introduced in Exchange 2000 SP1
\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1 - introduced in Exchange 2000 SP1
The typical schema path for a public mdb looks like:
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. This was part of support for the "never fully implemented" exchange web store development platform. The idea was that Folder items could reference various versions of the schema and live happily alongside of each other. At one point (Exchange 2000 RTM) schema files lived in the schema root folder, and changes to the schema effectively propagated to all items. This lead to problems in the application development workspace where each item needed to be touched to remove or add props as appropriate, so we adopted a versioning method. Under schemaroot, we create 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 on the fly. The \schemaroot\default folder is where normal folder items pull their schema from, 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, as it does not have an entry in the EventBindings folder like most events.
EXCHWEB, Views, IMG, Controls
\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
Introduced in Exchange 2000 SP1, no longer populated in Exchange 2000 Post SP3 hotfixes and Exchange 2003. For the Local Store to open items that referenced OWA control functionality the files had to be in a sync-able folder. These folders once contained copies of the web data for OWA 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 have been present since Exchange 2000 RTM.
\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 build to a given MDB. At startup EXOLEDB must enumerate the events here, which can lead to long store startup times with large event sink numbers. Titanium performance in this area is greatly improved, but time to mount an MDB is still affected by number of rows. Each binding is validated for class, having a valid event method (onsave, ontimer, ect), 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 OWA scratch pad
OWAScratchPad
\NON_IPM_SUBTREE\OWAScratchPad - Introduced in Exchange 2000 SP1
Posts have to start out somewhere in order to have attachments, and for public store logons, that place is the OWA scratch pad. Because DAV doesn’t do cross mdb operations, we need a point on every mailbox where we can always write posts to, so that we 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 OWA scratch pad controls the size of attachments that can be added via OWA. Attempts to post larger messages should result in an 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 1mb at EXOLEDB initialization if the registry key "HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA", a REG_DWORD value "Message Size Limit" is not set. This is required for Sharepoint, because EXOLEDB has no idea of we are running in magma mode or not.
OWA 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.
What causes duplicate system folders?
This question really falls into two categories.
AD Objects -Because when a store is deleted (disaster recovery & friends) we have no way to tell the AD the PF objects went away, then when folders are re-created they do not get "attached" to the corresponding DS objects. New ones are created.
Actual Folders - If the folders are set to replicate, and the store in question is deleted, EXOLEDB will recreate the folders on startup, and replication can then create a second, duplicate of any such folders. This wreaks havoc with event bindings. Deleting said folder via friendly URL is dangerous, as the two will often have duplicate friendly URLs..
Why do they get strange names?
When the number of system folders with the same number grows, we append a random number to the DS proxy to make it unique, resulting in names like "controls12345678".
Why can I not delete them?
First off, if you were to delete the folders, EXOLEDB would put them back. Secondly, most of these folders have real uses that will adversely affect the operation of the server if not present.
Microsoft
