Exchange Public Folder / System Folder replicate which ones?

This is an often question we had seen and there is a KB which gives a good overview which folders are from what version of Exchange.

Sadly The Microsoft Script “.\AddReplicaToPFRecursive.ps1 -server “SBSERVER2” -TopPublicFolder “\non_ipm_subtree” -ServerToAdd “SBSERVER2″” does not handle that KB or has the knowledge what to replicate and not.

We had a case where the OLD Exchange 2010 “System Folders” under “\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1″ was replicated from 2010 to a replaced DAG member 2010. The customer also had

Mcafee Security for Exchange 8.5 P1 running which lets you exclude Public Folder for Mailbox Scanning but NOT on the HUB function. Because we had a file filter for .JS the replication files triggered an alert.

Here is the alert because of the JS extension of replication of old Exchange 2000 public folder structure:

Exchange OLE DB Provider

https://msdn.microsoft.com/en-us/library/aa142634(v=exchg.65).aspx

EXOLEDB Introduction

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
  
• \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

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.

EXCHWEB, Views, IMG, and Controls

The following list introduces EXCHWEB, views, IMG, and 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 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.

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.

OWAScratchPad

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

• \NON_IPM_SUBTREE\OWAScratchPad
  

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.

EXOLEDB Folders FAQ

Consider the following frequently asked questions (FAQs).

What causes duplicate system folders?

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.
  

Why do folders get strange names?

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.

Why can I not delete folders?

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.

How do I fix missing schema folders?

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:

HKLM\System\CurrentControlSet\MSExchangeIS\Parameters\Schema\<MDBGUID>

What permissions are used on schema folders?

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.

Do you need to replicate those folders when servers are decommissioned?

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

For More Information

For more information, see the following Exchange blog entry: