On-Premises Public Folders, Exchange Online, And Multiple Forests

Update: October 2018. Microsoft have added support to hide public folders in Exchange Online. Now rather than the below post from me, you can set a users mailbox to see public folders or not as required and then enable the global setting to turn on controlled access to public folders. For more see https://techcommunity.microsoft.com/t5/exchange-team-blog/announcing-support-for-controlled-connections-to-public-folders/ba-p/608591  

Here is a scenario I have come across in a few clients in just the last few weeks. This is not something that I recommend implementing lightly, as there are implications. But it does allow some very specific problems with public folder integration to be solved in the short term.

Update: March 2018 – this process below has changed considerably due to changes in the Exchange Online and AutoDiscover that have stopped this process working for random subsets of customers. Please scroll down to bottom for the specific changes that are added to this post. The original info below remains as the principle of the information is fine to read and understand – but the specifics of the implementation have changed:

The specifics of the scenario is that with Exchange Online mailboxes and on-premises public folders, each user in Exchange Online needs a login account in the on-premises forest. That is easy for hybrid mode Exchange Server to Exchange Online, but once you move to multi-forest hybrid it is not. In multi-forest hybrid you will have users from more than one forest (of course).

When you set up integration between Exchange Online and an on-premises Exchange organization, you choose the single organization that you can proxy public folder requests to. This is done with Set-OrganizationConfiguration in Exchange Online and the value is the email address(es) of mailboxes that are located on the same servers as the public folder servers on premises – these are known as the public folder proxy mailboxes. For example this would look like Set-OrganizationConfiguration -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes pfProxy1. Once this is done, all Exchange Online users get allocated one of these email addresses as their public folder proxy address. When the user uses Outlook, the AutoDiscover response for their mailbox will include a publicFolder value that contains this email address given to the users mailbox. For example, it would look like this:

      <PublicFolderInformation>

<SmtpAddress>pfProxy1@domain.com</SmtpAddress>

</PublicFolderInformation>

Outlook will then do AutoDiscover for that mailbox (in the same way that it does AutoDiscover for shared mailboxes) and attempt to login to the public folders (Outlook 2010) or show “Public Folders” in the Outlook tree folder view and wait until the user expands to attempt to connect (Outlook 2013 and later). If the user has an account on-premises then the Public Folder hierarchy is shown and the user can open folders for which he or she has permission.

But, if the user belongs to another forest, they do not have an account in the forest that the public folders are in and so login to the public folder hierarchy fails.

So how do we solve this. There is one way I have tested, and another way I have yet to test. The first way turns off the public folders for the users in all the non-primary forest for public folders. They cannot access public folders at all, unless you implement a third party folder migration software and even these might not work. The steps to implement this “fix” is to begin to implement public folder migration, but actually to stop very early in the process and jump to near the end of that process. So first create a new public folder in Exchange Online. As you are using public folder proxies, you can only create public folders that are held for migration, and that is the key to this idea. So New-Mailbox pfMailbox1 -PublicFolder -HoldForMigration will create a new empty (and that is important) public folder mailbox in Exchange Online. Now near the end of published process for public folder migration there is a step where you can individually set cloud mailboxes to use the cloud public folders. You do this with Set-Mailbox name -DefaultPublicFolderMailbox pfMailbox1 and this user will now only look at the empty cloud public folders and not attempt to connect on-premises. Therefore if you do this for all mailboxes from the non-primary forest for public folders then they will stop failing to login on-premises. Sure, they loose public folder access to their original folders as well, but that was the risk that that you would have been discussing with your consultant before you started migrating.

Note that it has come to my attention that the email address of this proxy mailbox must not be the tenant.onmicrosoft.com address or tenant.mail.onmicrosoft.com, as AutoDiscover for that namespace intentionally blocks requests or is non-resolvable to its namespace as part of Exchange Online hybrid. Therefore the email address used must be a domain that resolves AutoDiscover quickly, as Outlook will query AutoDiscover for this proxy mailbox on every folder action (move folder) or where you scroll down the folder using the scroll bars.

My second, untested option, is to instead run the Set-OrganizationConfiguration option but to use proxy mailboxes from multiple forests that have previously created and synced. And rather than allowing Exchange Online to randomly distribute the proxy mailboxes across all the users, you would provision the user with the correct proxy mailbox for the organization they are in. Assume therefore that Forest1 has pfForest1Proxy and Forest2 has pfForest2Proxy1. You would run Set-OrganizationConfiguration -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes pfForest1Proxy,pfForest2Proxy and then individually ensure that Set-Mailbox <each user in Forest1> -DefaultPublicFolderMailbox pfForest1Proxy and that Set-Mailbox <each user in Forest2> -DefaultPublicFolderMailbox pfForest2Proxy. Note that this is not tested. Please let me know if this works for you in the comments if I don’t get to test it first!

So now onto the specifics that have become an issue with the above configurations since Feb 2018

AutoDiscover in some tenants and some implementations of Office 365 have started shown errors where Outlook fails to connect when the above is implemented, and viewing network traffic in Fiddler shows connections that never complete and cause the client PC to run out of resources and Outlook fails to start and is unoperable.

In this scenario the fix is to create a mail user object with an unresolvable target address. This means that AutoDiscover does not resolve to the onmicrosoft.com endpoint and fail, but does not resolve at all.

New-MailUser -Name PFDeadEnd -Alias PFDeadEnd -ExternalEmailAddress PFDeadEnd@PFDeadEnd -MicrosoftOnlineServicesID PFDeadEnd@PFDeadEnd.onmicrosoft.com -Password (ConvertTo-SecureString -AsPlainText "enter your password here" -Force) -DisplayName "PF Dead End Object"


Then add this mail enabled user to the OrganizationConfig as another public folder proxy.
Set-OrganizationConfig -RemotePublicFolderMailboxes @{add="PFDeadEnd"}


Finally, ensure that all users that need to access on-premises public folders get given one of the public folder proxy values that resolve to on-premises, and the others (who cannot connect to the on-premises public folders) get the “dead end proxy” mail user. This means you need to assign all user a PF proxy and not allow Exchange Online to allocate one at random. In the below, we allocated the DeadEndPF mail user to those who are cloud only, or merger/acquisition mailboxes based on domain – you will need to filter based on your specific requirements
Get-Mailbox -Filter {(WindowsEmailAddress -like '*@domainThatCannotGetPublicFolders.com') -and (RecipientTypeDetails -eq 'UserMailbox')} -ResultSize unlimited | Set-Mailbox -DefaultPublicFolderMailbox PFDeadEnd

Get-Mailbox -Filter {(WindowsEmailAddress -like '*@domainMigratedFromOnpremisesThatCanGetPublicFolders.com') -and (RecipientTypeDetails -eq 'UserMailbox')} -ResultSize unlimited | Set-Mailbox -DefaultPublicFolderMailbox <legacy PF, which is needed>

Thanks to Ingo Gegenwarth , Heiko Pohl and Michael Emmer for assistance on this. More information on this, including the AutoDiscover delay, in Ingo’s blog at https://bit.ly/2GzMjWJ