In Exchange 2013 CU5 (yes 5, V, cinco, fem, and cinque) we started implementing changes to how Legacy Public Folder endpoint discovery will be performed by Outlook (for Windows) in the future. This work continues behind the scenes and will be completed with the release of Cumulative Update 7. This becomes important in on-premises Exchange coexistence environments where some or all of your on-premises user mailboxes have been moved to Exchange 2013 and your Public Folder infrastructure is still on Exchange 2007 or Exchange 2010. Anyone whom has gone through the Legacy Public Folder hybrid configuration steps for Exchange Online will recognize what we are about to go through for the on-premises edition of Exchange 2013.
Prior to CU7, Exchange 2013 mailboxes using the Outlook client were proxied to the legacy mailbox server hosting the Public Folder being accessed either via RPC/TCP or RPC/HTTP depending on the client’s location, the connectivity model being used, and the configuration on the legacy Exchange servers.
With the introduction of MAPI/HTTP in Exchange 2013 SP1, we identified an issue where clients could not always access the legacy Public Folder environment after moving to the MAPI/HTTP protocol.
An analysis of this behavior led us to understand that a combination of RPC Client Access code and older code within the Outlook client enabled the client to be redirected to the legacy Public Folder store under certain circumstances. While you may be thinking this is great news, it is not the desired state – both Exchange and Outlook need to utilize a common pathway for directing clients to connect to mailbox and Public Folder data. That common pathway is Autodiscover.
In the future, both Exchange and Outlook will remove the old code that enabled the older redirection logic. As a result new configuration steps exist which customers should undertake to coexist with legacy Public Folders and support connectivity with Outlook (for Windows) clients whose mailboxes reside on Exchange 2013, regardless of the connectivity protocol (RPC/HTTP or MAPI/HTTP) in use by their clients.
We are providing you with this information in advance of CU7’s release (No, we’re not going to answer when it will be released other than ‘when it is ready.’J) so you may prepare your environments for the new legacy public folder coexistence method. All of the commands discussed here were available starting in CU5 so you may configure your environment in advance of deploying CU7 if you would like to.
The configuration steps for enabling this new discovery method have been published in the following article.
There are two new commands you will need to execute prior to installing CU7 or just after (we recommend before) to ensure Exchange 2013 CU7 and later will provide Outlook the information it needs to properly discover legacy public folders.
With the above settings configured Exchange 2013 will begin returning a new section in Autodiscover responses to Exchange 2013 mailbox users similar to the following and using the new coexistence code paths;
With this information Outlook will then perform a second Autodiscover request using the provided SMTP address. This SMTP address is for a legacy Public Folder discovery mailbox that resides on an Exchange 2007 or Exchange 2010 mailbox server that also serves a public folder database (PFDB). In the above example Outlook would perform an Autodiscover request for PFDiscoveryemail@example.com to discover the connection endpoint (RPC, or RPC/HTTPS) to use when the Exchange 2013 user is accessing your organization’s legacy Public Folder. Outlook is not logging on as this mailbox, nor is it actively using this mailbox to access the legacy public folder content. The mailbox strictly exists to be able to perform an Autodiscover request/response such that Outlook receives a valid connection endpoint for your legacy Public Folders.
Without these new settings being configured, Exchange 2013 will continue to use the old code paths which will be removed at some point in the future. It is important that all on-premises Exchange 2013 organizations fully configure their environment to ensure uninterrupted legacy Public Folder access in the future.
Yes, we have you covered. Let us go through configuring an Exchange 2013 environment for Exchange 2010 legacy public folder access as it is the more complicated of the two scenarios to configure. If you need to configure Exchange 2007 there are fewer steps involved and you can reference the TechNet documentation.
Below we can see there are two legacy public folder databases used as defaults for our Exchange 2013 databases.
Note: If you are unable to create an additional mailbox database in this step due to using Exchange Server Standard Edition, you can utilize an existing mailbox database in this case.
Below you can see the mailbox we created and its SMTP address.
Running our Set-OrganizationConfig commands.
Note: If you need to add multiple mailboxes you can use this example PowerShell command format.
Set-OrganizationConfig -RemotePublicFolderMailboxes "PFDiscovery-001", "PFDiscovery-002"
Validating the changes took place.
MAPI/HTTP for the Primary mailbox and RPC/HTTP for legacy Public Folders
MAPI/HTTP for the Primary mailbox and RPC/TCP for legacy Public Folders
Q: We're running Exchange 2013 SP1 (or earlier) and plan on upgrading directly to CU7. Our Exchange 2013 users seem to be accessing legacy Public Folders without issue today. Does this mean their legacy Public Folder access will break when CU7 is applied?
A: CU7 has logic that will only use the new code paths if RemotePublicFolderMailboxes is not empty and the PublicFoldersEnabled is set to ‘Remote’. If you were to upgrade directly from an SP1 or earlier to CU7, then Exchange will use the old code paths until you complete the necessary configuration steps to ensure users are not interrupted post-upgrade.
Q: Does Outlook Anywhere need to be enabled in the legacy (2007/2010) environment for this to work if we do not currently provide external access to Exchange via OA?
A: No, Outlook Anywhere does not need to be enabled if the only connectivity method you need to provide to legacy Exchange versions is RPC for internal users or external users connecting via a VPN tunnel. If OA is disabled in the 2007/2010 environment, then the Autodiscover results will inform Outlook to use RPC via the EXCH Outlook Provider instead of RPC/HTTP via the EXPR Outlook Provider to connect to the public folder database.
Q: Are there any specific Outlook versions/builds required for this to work?
A: As a general rule we always suggest keeping Outlook up to date with both service packs and public updates, and we maintain that suggestion here. As long as you are running a version of Outlook 2010 or 2013 supported by Office 365 this feature should work. If this guidance ever changes, we will update necessary documentation.
Q: How does Exchange 2013 choose what Remote Public Folder Mailbox to hand out to clients if more than one is configured in the RemotePublicFolderMailboxes variable? Is it random, round robin, looking at availability?
A: By default Exchange looks at the hash of the user calling into Autodiscover and will pick an entry from the array of mailboxes in RemotePublicFolderMailboxes or use the default public folder mailbox value if it is explicitly set on the mailbox. There is no logic based on user location versus PFDB location or anything of such nature.
Q: Will Exchange 2013 check to make sure th e server holding a PF discovery mailbox is up and reachable before a client attempts to retrieve its connection settings via Autodiscover?
A: No, there is no availability check to ensure the legacy server is available before the PF discovery mailbox is given to a client to look up via Autodiscover.
Q: How many legacy public folder databases do I need accessible?
A: Public folder scalability guidance for Exchange 2007 and Exchange 2010 recommended no more than 10,000 active users connecting to a single PFDB. Based on that guidance, then at least one PFDB per 10,000 active users should be accessible. If you have 50,000 users in your organization then a conservative number would be to have no less than 5 public folder databases.
Note: This is a starting point. Your environment may vary and as a result require more or even less PF public folder databases as you monitor your system performance, user concurrency, and user client experience in your legacy environment.
Q: How many PF discovery mailboxes do I need?
A: At this time we are suggesting one per PFDB to be accessed.
Q: How do I control what particular PFDB the user connects to first?
A: For environments with geographically disperse locations it may be beneficial to ensure users connect to a PFDB close to their home location on a well performing network link path. You can make this happen by defining the default public folder database on the user’s Exchange 2013 mailbox database and locate users with similar geographical needs in the same Exchange 2013 mailbox database.
The commands are slightly different depending on if you are setting an Exchange 2010 or an Exchange 2007 public folder database as the default for an Exchange 2013 mailbox database. The command will tell you the ‘PublicFolderDatabase’ parameter has been deprecated, but it does do what it is supposed to do for coexistence purposes.
Using an Exchange 2007 Public Folder Database
Set-MailboxDatabase <2013DatabaseName> -PublicFolderDatabase <2007ServerName>\<Storage GroupName>\<PFDatabaseName>
Using an Exchange 2010 Public Folder Database
Set-MailboxDatabase <2013DatabaseName> -PublicFolderDatabase <2010PFDatabaseName>
Q: For Exchanage 2010 do I really need to install CAS on every Mailbox server with a PFDB to be accessed and create a new mailbox database?
A: At this time, yes, but we are evaluating a few other options to help improve and possibly streamline the coexistence configuration in the future. If we are able to streamline this process in the future we will be sure to update you. Remember, you do not need to add the server to your load balancer pool simply because CAS has been installed. The server should not see the volume of client traffic other CAS in the AD site experience.
After implementing this configuration you will have a more robust and predictable legacy Public Folder connectivity experience with Exchange 2013 Cumulative Update 7 and beyond by making your legacy Public Folder infrastructure discoverable via Autodiscover by your Outlook (for Windows) clients. We look forward to your comments and questions below. Be on the lookout soon for another article that will go into detail on deployment recommendations for Exchange 2013 public folders themselves.
Senior Program Manager
Office 365 Customer Experience
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.