The Hidden Challenges of Mail-Enabled Public Folders

Exploring the Unseen Challenges of Mail-Enabled Public Folders

Introduction to Mail-Enabled Public Folders

Mail-Enabled Public Folders are a feature of Microsoft Exchange that has been available for more than 20 years stretching all the way back to Exchange 5.5. This feature allows for one or more email addresses to be attached to a Public Folder and which can then receive mail through normal mail delivery patterns like SMTP. The attraction of this feature stems from its simplicity in that no separate mailbox needs to be created and, unlike a mailbox, consists of only one folder. This is a very convenient alternative to a shared mailbox for non-user mail like ‘support’ or ‘info’ or other more generic mail addresses that an organization may choose to employ.

A mail-enabled public folder has many of the same options as a contact, distribution list, or mailbox in Microsoft Exchange. For example, one may set delivery restrictions or forwarding on a mail-enabled public folder in the same way it can be done to mailbox or distribution list. A mail-enabled public folder can have a primary SMTP address as well as multiple alternate addresses of any type that the Exchange system supports.

As a single folder, the possibly unnecessary structure of a mailbox is not present such as Inbox, Outbox, Sent Items, etc. Users need only view one folder to determine if new mail has arrived without the clutter of all the other ‘default’ folders of a mailbox.

However, for all its conveniences mail-enabled public folders are not with some administrative pain and frustration. In order to concisely describe some of these challenges and any solutions to them some explanation of how they work is warranted first.

Challenges of Mail-Enabled Public Folders

Transform your enterprise with Priasoft’s specialized solutions for Microsoft Office 365 Migration, ensuring a smooth transition that optimizes your business. Connect with a Priasoft expert today to explore our industry-leading Public Folder solutions tailored to meet your unique needs.

Speak to a Priasoft Expert

How Mail-Enabled Public Folders Work

In order to describe how this system works an understanding of how Exchange works regarding mail delivery is required first.

Incoming mail to an Exchange server is picked up by the hub-transport service for which there may be one or more ‘receive connectors’ with different rules or settings. One of the roles of the hub-transport service is to determine if a destination email address can and should be delivered locally. This determination is done by searching the Active Directory environment for a matching address. This search is made against the Global Catalog service (which is limited, fast, and in-memory copy of all objects in the entire Active Directory Forest…e.g. all domains). If the email address is found on a single object (multiple objects indicate an ambiguous situation and will fail on delivery) then the hub-transport evaluates the returned object reference to determine the ‘type’ of object. Common object types are mailboxes, mail-users, contacts, distributions lists, and…public folders.

Since the hub-transport starts with an Active Directory search, mail can only delivery to a public folder if there is some object in Active Directory with the email address.

For those that are unfamiliar with this, every public folder that is mail-enabled has (or should have) a corresponding Active Directory ‘proxy’ object. An Exchange server will automatically create this proxy object when a folder is mail-enabled and creates these objects in the Microsoft Exchange System Objects container in the domain of the Exchange server that is processing the request. However, throughout the years that Exchange Public Folders have existed, the specific rules on where the proxy object is created has changed from time to time. In a multi-domain Active Directory Forest, it has been found that some deployments cause the proxy objects to be created in the forest root domain while in other environments it creates them in the domain of the first Exchange server that was created. The specific domain in which the proxy objects are created has no real affect on mail delivery since the hub-transport performs its searches using the Global Catalog service. Modern public folders (Exchange 2013 and later) create the Active Directory object in the root domain.

From a management perspective however, it means that these public folder proxy objects could exist in any domain of a multi-domain forest. Before calling any of the Exchange powershell commands one should start with a scope change to include the entire AD Forest: Set-ADServerSettings -ViewEntireForest $true.

The Active Directory proxy object is listed with an object class of ‘publicFolder’, so it is distinct by type from other mail objects that may exist in Active Directory. The publicFolder class does not inherit from any of the other common mail-object types (like person) but instead defines specific exchange properties that it supports (like proxyAddresses, mailNickName, etc.). Furthermore, while the default location for these objects is and always has been the Microsoft Exchange System Objects container, mail delivery through one of these publicFolder objects does not seem to fail if the object is moved to another container…however doing so does frustrate the management tools (like powershell).

The Active Directory proxy object is listed with an object class of ‘publicFolder’, so it is distinct by type from other mail objects that may exist in Active Directory.

The Active Directory proxy object for a public folder has a few special properties that link it to the public folder in the hierarchy.

The Active Directory ‘objectGuid’ property is written to the mapi property PR_PF_PROXY of the folder in the hierarchy. This is the linking attribute.
The public folder in the hierarchy also stores a Boolean value indicating whether the Active Directory proxy object is hidden from the Global Address List (GAL): PR_PUBLISH_IN_ADDRESSBOOK.
The public folder in the hierarchy also stores another Boolean value indicating whether the folder needs to have its Active Directory object created: PR_PF_PROXY_REQUIRED.
The proxy object will also have another linking value to the folder in the hierarchy that is or can be translated to the mapi ‘EntryID’ of the folder. This value is used by the hub-transport to open the specific folder via mapi in order to create a new message in the folder for delivery.

Different versions of Microsoft Exchange through the years have changed the attribute and format of the mapi EntryID link. It is also possible to have public folders from a previous version of exchange that continue to work with a newer version of Exchange and in this case the Exchange hub-transport will simply fall back to the older format of the value if the current format doesn’t work or is not present on the expected property. In the end this is an entirely opaque element and process and attempts to figure out the format and attribute are undocumented and unsupported by Microsoft.

Mail-Enabled Public Folder Management Friction and Frustration

When attempting to manage mail-enabled public folders many points of friction or frustration can occur. Most of these points of pain come from the fact that the mail-enabled aspect of a public folder is a separated object from the folder in the hierarchy and the Active Directory proxy object does not store the folder path of the related folder in the hierarchy.

The relationship between the proxy object and the folder in the hierarchy can be broken and happens whenever the directory ‘ObjectGuid’ does not match the value stored on the PR_PF_PROXY value of the hierarchy folder. This break in the relationship can occur for many reasons:

The proxy object was somehow deleted and recreated which causes the object to receive a new ObjectGuid, and which now doesn’t match the hierarchy folder’s value.
The hierarchy folder loses the linking value thru some odd user interaction or by a replication failure.
The public folder in the hierarchy is moved to a new replica or public-folder-mailbox. When a public folder is moved to a different ‘store’ (database or mailbox) its underlying EntryID value will change slightly as a result which can break the mail delivery since the AD proxy object had previously stored the value.
The public folder in hierarchy can be deleted and fail to delete the AD proxy object. This leaves behind an orphaned object in Active Directory and in the Global Address List.

When attempting to manage mail-enabled public folders many points of friction or frustration can occur.

Much of the management issue with public folder links comes from the carrying forward of older mail-enabled public folders from prior versions of Microsoft Exchange. This is very prevalent if an organization’s mail system has existed since Exchange 2000 or 2003. In these older versions of Exchange EVERY new folder created was automatically mail-enabled but was hidden from the GAL. When upgrading Exchange over the years many of these may simply have “come along for the ride”. They will appear as mail-enabled folders from a management perspective, but in reality do not actually deliver mail because the mapi EntryID link format is incompatible with later versions of Exchange.

Friction with Exchange Powershell cmdlets for Public Folders

Most public folder implementations are currently with Exchange 2010 or later (and a few Exchange 2007 from time to time). The common thread with all these versions is the existence of PowerShell to manage objects in Exchange.

There are 2 ways it identify mail-enabled public folders with powershell and they operate in very different ways. The first and likely more common usage is with Get-MailPublicFolder. This command will enumerate all the Active Directory proxy objects. Note the subtlety of this command in that it ONLY enumerates the Active Directory objects. It makes no validation against any folders in the hierarchy. Running this command is likely to generate many warning messages about name formatting and character issues. When this is seen it is generally another holdover of older settings and values from prior versions of Microsoft Exchange. These warnings do not prevent mail delivery in most cases.

The Get-MailPublicFolder command is also sensitive to multi-domain forests. If one does not use the command ‘Set-ADServerSettings -ViewEntireForest $true’ prior to calling Get-MailPublicFolder, the result set can be less than the entire list of mail-enabled proxy objects.

The second command that can identify mail-enabled folders is Get-PublicFolder. When using this command, each returned public folder object has a Boolean property named ‘MailEnabled’. In contrast to Get-MailPublicFolder, the Get-PublicFolder command works against the folder hierarchy and the value is only true if the underlying folder in the mailbox/database has a non-null/non-empty PR_PF_PROXY value – note that this value cannot be seen via powershell; MFCMAPI and EWS (Exchange Web Services) can expose this property for those that are curious. However, the Get-PublicFolder command also does not validate a mail-enabled public folder; it only shows TRUE if the property is non-empty. It does not provide any information about the Active Directory proxy object.

If the linking guid (objectGuid) is not broken between the proxy object and the hierarchy folder, it is possible to ‘pipe’ the two commands together. For example: Get-MailPublicFolder my-folder-name | Get-PublicFolder. The combined commands, if the link is correct, will return the hierarchy folder.

The reverse is also true: Get-PublicFolder \this\folder\path | Get-MailPublicFolder should return the mail-enabled properties.

However, this above only works if the commands are run in a powershell session that is directly on the exchange server – thru either remote desktop or physically. When running powershell directly on an exchange server, returned objects are not serialized and have more information than when running in a remote powershell session (e.g. Import-PSSession).

For any case where the combined commands do not provide a value it does NOT mean that mail is not delivered to the folder, only that the management link is broken.

How to Match Mail-Enabled to Hierarchy Folders

Given all the possible ways that the relationship between a mail-enabled public folder can be frustrated there is often a need to analyze, review, and possibly make corrections to this system.

Conceptually there is only one way to do such analysis: Send mail to all Active Directory proxy objects and then look for the corresponding mail in the hierarchy folder. While on the surface this may sound simple, there are many influencers to this task that can make to be less than successful or a complete failure.

Firstly, mail can only delivery to a public folder if the authenticated account has sufficient rights to the folder to create items. When a public folder is mail-enabled the very first time, Microsoft Exchange will add the CREATE ITEMS right to the ANONYMOUS account on the folder. However, if an internal forest/domain user attempts to send to this folder the access check will not be made against the ANONYMOUS account. Authenticated users will be compared to groups and explicit permission assignments first, and the lastly against the DEFAULT account. As such, mail sent from a forest/domain user will fail to deliver and an NDR (non-delivery report) will be generated unless that user has the CREATE ITEMS right somehow.

Secondly, mail-enabled public folders can have delivery restrictions that can prevent delivery. If an internal user has the CREATE ITEMS right but the proxy object is set to ‘only accept messages from’ or ‘reject messages from’, mail can fail to deliver if the authenticated sender is/is not in those lists.

Thirdly, mail-enabled public folders can be setup for ‘moderation’ in which incoming mail is first forwarded to a ‘moderator’ to accept or deny delivery. If the ‘moderator’ has left the organization then the mail has no chance of every being delivered, unless the authenticated user is included in a ‘moderation bypass’ list.

Priasoft Has An Automated Solution For This Task

The Priasoft Public Folder Toolbox and PF Sync solution has a deep analysis feature that uses the above process to both send the tracking messages out and to scan and find them. The feature also will track folders that have restrictions or moderation and will monitor the ‘send-from’ mailbox that to look for non-delivery responses.

The resulting reports help administrator understand which folders are valid and delivery property from those with issues, blockers, or broken links.

The process is restartable, controllable, and support large and geographically dispersed environments (the last of which has its own set of influences on this task).

The output from this task can generate the following reports:

PERFECT MATCH: A perfect match is one where the folder received the test message and the link between the mail-public-folder and the public folder is correct.

IMPERFECT MATCH: An imperfect match is one where the folder received the test message, but the public folder’s link doesn’t match the mail-public-folder. This can occur if the mail-public-folder is forwarding to another mail-public-folder or if the mail-public-folder was somehow deleted and recreated and received a different AD ‘objectGuid’ value. Imperfect matches should be corrected by using this tool or by another tool that knows how to handle this case.

MATCHED FOLDER: A matched folder is one that did not receive a test message but the link between the public folder and the mail-public-folder is correct. The failure to receive the test message may be due to PF replication, transport rules, moderation, or other mail delivery rules.

AMBIGUOUS FOLDER: An ambiguous folder is one where more than one folder in the hierarchy received the same tracking message. Any of the folders could be the expected target, or none of them. These folders require a review to determine which folder in the hierarchy to keep as the mail-enabled folder.

UNLINKED FOLDER: An unlinked folder is one where the link property exists on the public folder from the hierarchy but does not match any of the mail-public-folders tested. This can happen when the mail-public-folder is somehow deleted in Active Directory directly without properly mail-disabling the folder.

ORPHANED FOLDER: An orphaned folder Is one that received a test message but doesn’t map back to one of the mail-public-folders. This can happen if a previous run of this task was canceled before completion and the mail-public-folder was deleted in Active Directory without properly mail-disabling the folder.

ORPHANED MAIL-PUBLIC-FOLDER: An orphaned mail-public-folder is one where the test message was sent but did not appear in any of the scanned folders. This can happen if the public folder was deleted or moved and somehow did not cause the mail-public-folder in Active Directory to be updated or removed. Alternatively, this can happen if the less than the entire hierarchy was scanned. These objects should be reviewed and removed by manually deleting the Active Directory object if all folders in the hierarchy have been scanned. Office 365 may require Microsoft support to take action on these.

EXCLUDED MAIL-PUBLIC-FOLDER: An excluded mail-public-folder is one where the during the initial analysis of the mail-public-folders it was found that mail could not be sent due to a restriction, rule, moderation or other blocker and was excluded from sending test messages or matched a user pattern for exclusion.

NON-DELIVERY ERROR MAIL-PUBLIC-FOLDER: A non-delivery error mail-public-folder is one where the sending of the tracking message was returned due to a delivery issue of some sort.

Importance of Analysis Before a Migration

While the above information is always true for public folders, it becomes more relevant when a migration is pending or in-process. Failure to address the problem public folders can prevent mail delivery, create non-delivery message (possibly to customers or external senders), or leave folders that are problematic for management and can increase an organization threat surface for exploits.