How ESM Matches Public Folder Objects to Directory Objects

I recently worked on a few support cases where questions came up on “what exactly happens” when we use the Exchange System Manager (ESM) to pull up properties of public folders. How does the ESM find a matching public folder directory object in Active Directory, to display the public folder email addresses?

In order to understand this we need to first understand how the directory object is created originally.  A directory object is created in a mixed mode Exchange environment for every public folder in the organization, but is also hidden from the address book by default.  This is due to the requirements for 5.5 public folder objects, where all public folders were mail enabled by default. Also, in mixed mode, the “mail re-enable” option is also available (when right-clicking on public folders in the public folder hierarchy) for disaster recovery situations in which recreation of the Active Directory object would be required.  However once a native mode Exchange environment is in place, the directory object in the Microsoft Exchange System Objects Container (OU) get created only when the public folder is mail enabled manually.

When a public folder is mail enabled, the directory object is created inside the Exchange System Objects container inside the domain in which the exchange server resides.  If this is a mixed mode organization then the PR_PF_PROXY_REQUIRED MAPI attribute is set to TRUE (1) on the folder.  If this is a native mode organization then both PR_PF_PROXY_REQUIRED and PR_PUBLISH_IN_ADDRESS_BOOK are set to TRUE (1).  Finally the Active Directory object itself is created using the folder’s display name to compose the new objects distinguishedName attribute.  As long as another object does not exist in Active Directory with the same distinguishedName then it will be created. 

When the properties of a public folder are desired and accessed via Exchange System Manager several steps take place.  First the value of PR_PF_PROXY is retrieved.  Then we query the Active Directory for the objectGUID using the PR_PF_PROXY attribute.  If the GUID is found then we know that this folder is mail enabled and has a directory object.  At this point the property pages for the public folder are displayed with the additional tabs needed to display the mail enabled attributes.

Jason Dool

Comments (4)
  1. Setesh says:

    That blog answered a few questions that I was trying to work out. Thanks :)

  2. Adam Gates says:

    So what happens when the ESM pulls the contents of a Public Folder oh great master of Exchange Jason Dool?

  3. GeneK says:

    You may want to add that if you are accessing the properties of non mail enabled Public Folder via ESM (PR_PF_PROXY is not set), then ESM queries Active Directory for an object that has a matching legacyExchangeDN attribute.

    The following kb article talks about this process:

  4. Bruce Hanson says:

    Hi Jason,

    After our Org is in Exchange Native mode, there will be thousands of objects in the ESO container that don’t need to be there – email attributes aren’t needed for most of them. What is involved with removing email attributes from these folders and reducing ESO membership to just the necessary?



Comments are closed.