Understanding Exoledb’s default folders


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.


Jason Nelson

Comments (9)
  1. Very cool posting. I was asking myself what this folders are for since Exchange 2000 was released. Thanks!

  2. Jeff Guillet says:

    You write, "The size of OWAScratchPad is always reset to 1mb at EXOLEDB initialization if the registry key "HKLMSystemCurrentControlSetServicesMSExchangeWebOWA", a REG_DWORD value "Message Size Limit" is not set." Can I set this key to a value, say 10MB, so that the OWAScratchPad defaults to 10MB instead of 1MB? I’m having to manually edit the OWAScratchPad for each of my Exchange servers after they’re built.

  3. Jason Nelson says:

    Yes, you can set that in the registry, and I recommend it as it will be reset the next time the store starts if you don’t.

  4. Jason Nelson says:

    >Can I set this key to a value, say 10MB, so that the OWAScratchPad defaults to 10MB instead of 1MB?

    You can, and I recommend it, as it will get reset otherwise.

  5. Anonymous says:

    Jason Nelson goes into a bunch of more and better detail on the specific Exoledb-related folders in the…

  6. Matt Van Sickler says:

    Does the Message Size Limit registry key go by bytes, kb, or mb?

    PS – this should be in a KB article! I’ve been manually editing these folders for years. In a large environment, going through all the OWAScratchPad folders is a real pain. ;)

  7. Bodo Josefy says:

    Our virus protection software deleted all .js attachments in the schema-root/microsoft/exchangev1/exchweb/controls folder. Now OWA does not work any more.

    Do you have a hint how the attachments can be re-created without a repair install of Exchange ?

    Thanks !

  8. Anonymous says:

    Jason Nelson goes into a bunch of more and better detail on the specific Exoledb-related folders in the…

  9. Anonymous says:

    As many of my co-workers know, one of the messaging technologies that is near and dear to my heart is

Comments are closed.