What are we talking about today?
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.
Why should I care about this?
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.
Give me the short version. What do I have to do?
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.
- From a CU5 or later Exchange 2013 Server: Use the Set-OrganizationConfig cmdlet to assign the legacy public folder discovery mailbox(es) to the RemotePublicFolderMailboxes value of the organization.
- From a CU5 or later Exchange 2013 Server: Use the Set-OrganizationConfig cmdlet to set the PublicFoldersEnabled attribute of your Exchange organization from Local to Remote.
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;
<PublicFolderInformation>
<SmtpAddress>PFDiscovery-001@contoso.com</SmtpAddress>
</PublicFolderInformation>
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 PFDiscovery-001@contoso.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.
I like pictures and examples. Is there a longer version?
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.
- Identify the Public Folder database(s) you need users to be able to connect to initially by examining the PublicFolderDatabase attribute of your Exchange 2013 mailbox databases. This attribute defines the default legacy public folder database for each Exchange 2013 mailbox database.
Below we can see there are two legacy public folder databases used as defaults for our Exchange 2013 databases.
- Add the Client Access Server role if the PFDB resides on an Exchange 2010 Mailbox Server without CAS installed. The addition of the CAS role will ensure public folder replica referrals happen appropriately if a folder a user is accessing does not have a local replica in the PFDB. If the PFDB resides on a server with both the Mailbox and Client Access Server roles (Whether Hub Transport or UM are installed are irrelevant here), you can skip this step and go to step 3.
- After installing the CAS role, if it was necessary, configure the role as you would any other CAS in this AD site with the proper virtual directory and other settings to ensure Autodiscover results for clients are not impacted by a bunch of default virtual directory values. You do not have to add this new CAS role to your load balancer pool if you do not want to. If you did not have to install the CAS role as it was already installed on the PFDB server, please skip to step 3.
- Create a new empty mailbox database on the Mailbox Server containing the PFDB to be accessed. If this mailbox server is a member of a DAG, please do not create additional copies of this particular mailbox database. You can safely leave this mailbox database as a single copy.
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.
- Skip this step if you are re-using another mailbox database due to Exchange Server Standard Edition limitations. Using the Set-MailboxDatabase cmdlet, exclude this new empty mailbox database from automatic mailbox provisioning by setting the IsExcludedFromProvisioning flag to $True.
- Skip this step if you are re-using another mailbox database due to Exchange Server Standard Edition limitations. Using the Set-MailboxDatabase cmdlet, set the RPCClientAccessServer value of the new empty mailbox database to the FQDN of the Mailbox Server holding the public folder database to be accessed. The RPCClientAccessServer value is only used for RPC/TCP connectivity and this does not mean a new name is added to your SSL certificate as HTTPS will not be used here (see Item #3 here for explanation).
- Create a new mailbox inside the empty mailbox database you just created on the server holding your PFDB. This will be known as a Public Folder discovery mailbox. This mailbox is not accessed in any way. This mailbox is used as a target to retrieve connection settings via Autodiscover and nothing more. A naming convention such as PFDiscovery-<ServerName> or PFDiscovery-<###> is helpful to identify these mailboxes in the future. This mailbox must have an SMTP address which can be used by Autodiscover internally, and also used externally if you have external users requiring access to legacy public folders. If you are re-using another mailbox database due to Exchange Server Standard Edition limitations, the mailbox will reside in an existing database.
Below you can see the mailbox we created and its SMTP address.
- Using the Set-Mailbox cmdlet hide your new discovery mailbox(es) from address lists by setting the HiddenFromAddressListsEnabled parameter to $True.
- Repeat steps 1-7 for additional Public Folder databases if you would like to distribute client connections across more than one PFDB.
- Prior to running the next two commands we look at the current organization configuration in its default state.
- From a CU5 or higher Exchange 2013 Server: Using the Set-OrganizationConfig cmdlet, assign the PF discovery mailbox(es) to the RemotePublicFolderMailboxes value of the organization.
- From a CU5 or later Exchange 2013 Server: Using the Set-OrganizationConfig cmdlet, set the PublicFoldersEnabled attribute of your Exchange organization to Remote.
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
FAQ
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.
Summary
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