On-Premises Legacy Public Folder Coexistence for Exchange 2013 Cumulative Update 7 and Beyond
Published Nov 07 2014 10:00 AM 111K Views

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.

  1. 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.

    pf1

  2. 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.
  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.
  4. 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.

  5. 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.
  6. 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).
  7. 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.

    pf2

  8. Using the Set-Mailbox cmdlet hide your new discovery mailbox(es) from address lists by setting the HiddenFromAddressListsEnabled parameter to $True.

    pf3

  9. Repeat steps 1-7 for additional Public Folder databases if you would like to distribute client connections across more than one PFDB.
  10. Prior to running the next two commands we look at the current organization configuration in its default state.

    pf4

  11. 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.
  12. 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.

    pf5

    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.

    pf6

  • After you configure these two new settings and a few caches expire you should be able to validate you are now getting the <PublicFolderInformation> section back in the initial Autodiscover response for users with Exchange 2013 mailboxes.

    pf7

  • If you were to run your favorite HTTP proxy/logging tool while Outlook is running you would eventually see another Autodiscover query/response for in our example the mailbox PFDiscovery-010@corp.contoso.com returned above. This is when Outlook learns where and how to connect to your legacy Public Folder infrastructure.

    pf8

  • Confirm via Outlook you can connect to the legacy Public Folder hierarchy. Below are examples of using MAPI/HTTP for the primary mailbox and either RPC/HTTP or RPC/TCP for the legacy Public Folders. In our example lab the Exchange 2010 server named CON-E2K10-002 holds the PFDB being accessed. This public folder database was accessed because it is the default public folder database of the Exchange 2013 mailbox database the user resides in. If you are not yet using MAPI/HTTP in your Exchange 2013 environment, then the screenshots below would look the same except for replacing “HTTP” with “RPC/TCP.”
  • MAPI/HTTP for the Primary mailbox and RPC/HTTP for legacy Public Folders

    pf9

    MAPI/HTTP for the Primary mailbox and RPC/TCP for legacy Public Folders

    pf11

    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>

    pf12

    Using an Exchange 2010 Public Folder Database

    Set-MailboxDatabase <2013DatabaseName> -PublicFolderDatabase <2010PFDatabaseName>

    pf13

    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.

    Brian Day
    Senior Program Manager
    Office 365 Customer Experience

    26 Comments
    Not applicable
    Also seeing the disappearing public folders experienced by Jörg von der Ohe. What happens when your coexistence period is over ? All your mailboxes are already in 2013 and you want to move the 2007 public folders and get rid of the servers ? How is that

    handled ? Can you just revert the process and go back from Remote to Local mode ?

    Not applicable
    Hi Brian, we are facing at the moment the following issue, that the public folder disappear from the navigation pane, sometimes the came back. We created a ticket at the Premier Support in Germany, maybe you can get in touch with them.
    Not applicable
    @Varol, thanks for confirming. I'll put it on the list of things we need to get done!
    Not applicable
    Thanks for a very good Exchange Server Article.

    Your Exchange On-Premises customers appreciate it :)

    We are looking forward to Exchange Server 2013 CU7.

    Not applicable
    Thanks for the updated guidance. Is this also a prerequisite for migrating legacy public folders to Office 365? If so, when will that procedure be updated? [http://technet.microsoft.com/en-us/library/jj983799(v=exchg.150).aspx]
    Not applicable
    @Thomas, PF referral is handled by the RPC Client Access Service when you connect to the mailbox server via a public logon. You are using the discovery mailbox to locate the client connection settings and nothing more. Once you do that and establish the

    connection the other 'behind the scenes' items remain the same.


    @Mike, baby steps. I can't comment on what we may do in the future, but for now most of our resources are committed to improving the public folder scale at the moment to help unblock larger customer migrations.


    @Varol, similar steps are used for hybrid PF configuration as seen in this URL, but we may need to create a "transitioning from hybrid to Exchange Online" document if one does not already exist.

    http://technet.microsoft.com/en-us/library/dn249373(v=exchg.150).aspx

    Not applicable
    Brian, thanks for the "longer version" of the explanation.

    I miss some Information regarding the topic "public folder referral". Are there any implication or design goals that need to be covered? Or is this handled by using the dedicated discovery mailboxes for different PF databases?

    Not applicable
    Thanks Brian. The transition article in fact does not exist. Going from PF hybrid config to modern PF migration has been more than troublesome, to say the least. Would highly appreciate guidance on that front :)
    Not applicable
    more of a general functionality item relating to hierarchy mailbox but isn't a bit head in sand in providing support to global estates with regarding the your FAQ answer


    "How does Exchange 2013 choose what Public Folder Mailbox to hand out to clients?"

    Why wouldn't you enhance the algorithm and provide logic to ensure connections can be controlled and load balanced effectively?

    Not applicable
    Brian - Any scalability updates with CU7?
    Not applicable
    Why MS Make Things Hard?
    Not applicable
    Excellent Info. Thanks Brian! But of course I have a question: what a about migrating from legacy to modern PFs. Does the process change? Do I have to set the "RemotePublicFolderMailboxes" Parameters back to $NULL and the "PublicFoldersEnabled" Parameters

    to "Local" after the migration is finished? Thanks Christian

    Not applicable
    Hi Brian,

    a few FAQ


    If we are in Migration from Ex2010 PF to Ex 2013 new PF. Must we perform that steps also? Should we migrate PF finish to Ex2013 Prior to install CU7.


    If we plan Migrate PF from 2010 to Ex2013 before CU7 installed and before MAPI/HTTP enabled, must we perform that steps also?


    Regards Steven

    Not applicable
    Looks like this is pretty much going to be similar as PF accessbility from Exchange online to Exchange on-premise 20072010 currently.
    Not applicable
    We are planning on migrating to Exchange 2013 from 2007. After migrating mailboxes, we will be migrating the public folders. We plan to be done by the end of January, 2015.

    If I understand this correctly, I don't need to do anything at this time, as we should be off of 2007 Public Folders by the time the "older code" is removed. Installing CU7 won't break our public folders - at this time. (Though if we delay this migration, things

    will break.)

    Is my assumption correct? Just asking for clarity on this.

    BTW - Thanks for keeping up updated on where these things are going.

    Not applicable
    Hi Brian, I need to commission the Public Folders from our Exchange 2010 Organization, I'm in the middle of an EX10-EX13 migration and even after clearing the msExchHomePublicMDB attribute from a test mailbox database I am still seeing a test user's Outlook

    trying to connect to a public folder. Is there a way that I can eliminate PFs completely and not have Outlook looking for them? Thank you.

    Not applicable
    in step 2, you say "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". My question is - what if we have only one PF database on Ex2010

    MBX server, and all public folders are stored within this single database? If there will be no need for referrals, can I skip this step? I don't like messing with production systems if I don't have to.


    Also, can we skip all this until we move all users to Exchange 2013 and decommission all 2010 servers? I expect this upgrade to be completed in next couple of months, so would it be safe to simply rely on old Outlook paths to legacy PF databases till we are

    all Ex2013?

    Not applicable
    "Step 2. 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."


    Is addition of CAS role really necessary? What if all public folders reside within single PF database on this mailbox server?

    Not applicable
    I followed steps from this article and I can confirm that Outlook is picking up new PF section via Autodiscover for Ex2013 users. However, OWA still reports that there are no public folders deployed in organization...any ideas?
    Not applicable
    Reading between the lines a bit... As long as we do not enable MAPI/HTTP, there is no reason to go through all of this trouble, correct? (The public folder transition will be relatively brief, so it seems simpler for us to just leave MAPI/HTTP off until

    Exchange 2007 is gone.)


    Assuming that we do have to go through these steps anyway, I'd have some additional questions:


    Why is the discovery mailbox placed onto its own database? (It seems odd to tell us to make a new database, but then to say that it's fine to put it on an existing database if we have to, with no explanation of why.)


    If there is only one public folder DB, or all public folders are replicated to all DBs, then does that mean we do not need to install the CAS role? (Since there would be no referrals in either of those designs.) I don't think I'm alone when I say I prefer to

    touch the old 2007 or 2010 servers as little as possible during a migration.


    And you already addressed this somewhat, but if you are aware of any Outlook versions that will break after these changes, that would be good to know. Some parts of Exchange 2013 documentation still list these requirements:


    Outlook 2013

    Outlook 2010 SP1 with the Outlook 2010 November 2012 update (14.0.6126.5000)

    Outlook 2007 SP3 with the Outlook 2007 November 2012 update (12.0.6665.5000)


    Will these versions still work?

    Not applicable
    Thanks for the explanation so far. Is the new legacy Public Folder connectivity experience also supported for Outlook 2007?
    Not applicable
    Is the Outlook Anywhere required to access Public Folder after applying CU7 in Hybrid environment?
    Not applicable
    CU7 has completely broken Public Folder access on Windows XP machines:


    https://social.technet.microsoft.com/Forums/office/en-US/c9abc7b7-1135-4f4c-8809-b2f8be843271/cu7-an...


    Will it be fixed like it was fixed previously?

    http://support.microsoft.com/kb/2918951

    Not applicable
    Hi,


    We have an issue with public folder and CU7. We upgraged recently our server from CU6 to CU7. Since, Windows XP computers can't connect to public folders.


    How the changes described here in CU7 can have an impact in this situation, Outlook is doing the job, not the OS ...


    We opened a case on microsoft support, there is no hotfix, and our case is paused, we have to wait the hotfix for this, and they even don't know if a hotfix is planned for this ...


    Any news baout this ?


    Thanks

    Not applicable
    Can you give any pointers to a more technical explanation of the RPC/HTTP code changes that were implemented with CU7?
    Not applicable
    Hi Brian,

    We have Exchange 2010 SP Hybrid deployed and couple of users accessing Public Folders. We are planning to move our PF's completely to Exchange Online, will on-premise users still be able to access Public Folders from Cloud?

    Version history
    Last update:
    ‎Jul 01 2019 04:20 PM
    Updated by: