Configure Hybrid Public Folder with Exchange 2013/2016 (aka Modern Public Folders)

Public Folders don’t seem to have the usage that they used to so it’s been a while since we worked with Public Folders in Exchange. So long in fact that what we last configured is now called Legacy Public Folders with the new version, introduced in Exchange 2013 called Modern Public Folders.

A Refresher on Exchange Public Folders

In order to understand the new process of setting up Hybrid mode with Exchange Online you first need to understand some changes to how Public Folders work.

In Exchange 2010 public folders were stored in dedicated Public Folder Databases. These also had their own log files and had to be managed independently of any User Mailbox Databases.

With Modern Public Folders they have been moved into Mailboxes which are stored in a standard user database. The environment can contain multiple public folder mailboxes, each of which can contain different parts of the public folder hierarchy.

When a user accesses a public folder they are actually opening the mailbox that contains that part of the hierarchy. Unlike previous versions the data is only accessible from the server hosting the active database rather than any server hosting a public folder replica.

Configuring Hybrid Public Folders

What does this mean for configuring Hybrid mode Public Folders?

First of all if you searched for something like “Configure Exchange Public Folder Hybrid” and found this Exchange 2019 article referring to Exchange 2010 SP3 or later then you’ve got the wrong article. You need to look for this article which is only on the Exchange Online documents site.

This newer article ignores all of the steps setting up new Public Folder Mailboxes resulting in just three steps:

1) Download the following files from Mail-enabled Public Folders – directory sync script

  • Sync-MailPublicFolders.ps1
  • SyncMailPublicFolders.strings.psd1

2) On Exchange Server, run the following command to synchronize mail-enabled public folders from your local on-premises Active Directory to O365.


Sync-MailPublicFolders.ps1 -Credential (Get-Credential) -CsvSummaryFile:sync_summary.csv

3) Enable the exchange online organization to access the on-premises public folders. You will point to all of you on-premises public folder mailboxes.


Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3

Issues When Configuring Hybrid Mode

There are a few things to be aware of with this process though, particularly the final step.

1) Remember that the new Public Folders are stored in User Mailboxes which are associated with AD user accounts. If you aren’t syncing your entire Active Directory forest then the Public Folder Mailbox objects may not be synced to Exchange Online. So where are these stored by default? Well the Users container in your exchange enabled domain of course.

It’s likely that you haven’t synced this but you CAN move these objects to an OU that is being synced without any impact. Unfortunately this requirement isn’t included in the documentation. If these objects aren’t synced to Exchange Online then you’ll get the following message


Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1
Couldn't find object "PFMailbox1". Please make sure that it was spelled correctly or specify a different object.
    + CategoryInfo          : NotSpecified: (:) [Set-OrganizationConfig], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=SYAPR01MB2717,RequestId=d79eaa00-ff32-4076-8791-54ba22e3cb76,TimeStamp=26/11/201
   8 7:13:26 AM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] C4302B7C,Microsoft.Exchange.Management.Sy
  stemConfigurationTasks.SetOrganizationConfig
    + PSComputerName        : outlook.office365.com

2) Once you’ve moved the public folder mailbox objects remember that the -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3 syntax is referring to the Public Folder Mailboxes and NOT the public folder names. You can find these in the ECP under Public Folder Mailboxes.

3) You also need to list all public folder mailboxes in the one command. If you add an additional public folder mailbox in the future then include all the mailboxes and not just the new one.

4) Finally remember that your on-premises address book is different from your online address book. This means that any new mail enabled public folders will only appear in your online address book if you sync them using the Sync-MailPublicFolders.ps1 script. If users can create these objects then you may want to think about scheduling this task.

Only users who have been created on-premises and migrated to Exchange Online can access the on-premises Public Folder store. Only these users exist in the on-premises address book used to authenticate access.

It may not seem that way but ultimately this is a simple service to configure with just a few little gotchas to be aware of.

Misconfigured Skype for Business Edge Server Breaks Office 365 Hybrid Federation

We’ve been moving more customers to Office 365 recently. Not only are they seeing the business case stacking up from a cost point of view but they are also after the cloud only features which are now more frequently appearing. A troubling development with these migrations are the number of broken Skype for Business Edge servers that we are seeing.

Now these aren’t totally broken but just broken enough that when we try to integrate their on-premises Skype for Business environment with Office 365 services things go wrong.

How will you detect this?

This will often show up when trying to get voicemail configured to use hosted voicemail in Exchange Online since this is often the first hybrid service being deployed. When the call is redirected to the Exchange Online server it fails. Looking at the event logs on the front end server it says that the dial plan wasn’t configured correctly.


Attempts to route to servers in an Exchange UM Dialplan failed

No server in the dialplan [Hosted__exap.um.outlook.com__tenant.onmicrosoft.com] accepted the call with id [XXXXXXXXXXXXXXXXXXXXXXXXX].

Cause: Dialplan is not configured properly.

Resolution:

Check the configuration of the dialplan on Exchange UM Servers.


All the configuration looked fine and so we needed to dig into the SIP traffic a little more. We did this using snooper. We could see the message being handed off to the edge server from the front-end server but then the edge server connection timed out.


Response Data
504  Server time-out
ms-diagnostics:  1008;reason=”Unable to resolve DNS SRV"

This was a little strange as the edge server was working fine for other federation partners, and DNS lookups were working on the edge server.

What was happening?

One thing that didn’t look right though was that the internal interface was configured to use the internal DNS server. Referring to the Edge server deployment guide confirmed that this wasn’t correct.

https://docs.microsoft.com/en-us/skypeforbusiness/deploy/deploy-edge-server/deploy-edge-servers

Interface configuration without DNS servers in the perimeter network
1. Install two network adapters for each Edge Server, one for the internal-facing interface, and one for the external-facing interface.

Note
The internal and external subnets must not be routable to each other.


2. On your external interface, you’ll configure one of the following:


a. Three static IP addresses on the external perimeter network subnet. You’ll also need to configure the default gateway on the external interface, for example, defining the internet-facing router or the external firewall as the default gateway. Configure the adapter DNS settings to point to an external DNS server, ideally a pair of external DNS servers.


b. One static IP address on the external perimeter network subnet. You’ll also need to configure the default gateway on the external interface, for example, defining the internet-facing router or the external firewall as the default gateway. Configure the adapter DNS settings to point to an external DNS server, or ideally a pair of external DNS servers. This configuration is ONLY acceptable if you have previously configured your topology to have non-standard values in the port assignments, which is covered in the Create your Edge topology for Skype for Business Server article.


3. On your internal interface, configure one static IP on the internal perimeter network subnet, and don’t set a default gateway. Also leave the adapter DNS settings empty.

4. Create persistent static routes on the internal interface to all internal networks where clients, Skype for Business Server, and Exchange Unified Messaging (UM) servers reside.

5. Edit the HOST file on each Edge Server to contain a record for the next hop server or virtual IP (VIP). This record will be the Director, Standard Edition server or Front End pool you configured as the Edge Server next hop address in Topology Builder. If you’re using DNS load balancing, include a line for each member of the next hop pool.

How to fix it?

The edge servers were changed to meet this guidance by creating a hosts file with all servers in the topology using both short names and FQDNs, as well as setting the external adapter to be the only adapter with DNS settings which were external to the organisation.

Voicemail started working once this change was made.

Why this happens

So why did this happen? Part of the setup for voicemail located in Office 365 is configuring a hosting provider in Skype for Business.


New-CsHostingProvider -Identity 'Exchange Online' -Enabled $True -EnabledSharedAddressSpace $True -HostsOCSUsers $False -ProxyFqdn "exap.um.outlook.com" -IsLocal $False -VerificationLevel UseSourceVerification

This provider has shared address space enabled. This means that endpoints with the same SIP domain name can be located either on-premises or in the cloud. In our case the endpoint is the Exchange Online UM service.

When a call is routed to Exchange Online UM it looks up the local directory to see that the user isn’t located on-premises. The call is passed to the Edge server which performs a lookup of the _sipfederationtls._tcp.domain.com DNS record. Why is it doing this? Well basically it’s trying to make a federation request with it’s own domain and this is the start of that process. But the _sipfederationtls._tcp.domain.com record only exists externally so that lookup is failing. Since it can’t federate with itself it doesn’t go to the next step which is establishing a connection to Exchange Online.

This can also be fixed by adding the DNS record to your internal DNS but the edge server would still not being configured correctly. It’s possible that using the internal DNS server would result in something else not working later on. Far better to fix it properly.

Just as a matter of interest if you tried to configure a hybrid mode with Skype Online you would also experience issues where your on-premises users couldn’t see presence or send messages to cloud users. This is the same reason as the Exchange UM issue with shared address space also enabled on this hosted provider


New-CSHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn "sipfed.online.lync.com" -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

Both Exchange Online and Skype for Business have hybrid relationships with Skype for Business On-Premises. The only difference, apart from the provider endpoint address, is that the Skype Online provider is configured to host users while the Exchange Online provider hosts services.

Office 365 Hybrid Send-As Functionality – Not quite there yet.

Recently Microsoft announced that mailbox delegation would be available between Cloud and On-Premises accounts. This would allow for a cloud mailbox user to send-as an on-premises mailbox.

Looking at the documentation (https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx) it appears that this should now be working in early May 2018. In particular.

NoteNote:
As of February 2018 the feature to support Full Access, Send on Behalf and folder rights cross forest is being rolled out and expected to be complete by April 2018.

This feature requires the latest Exchange 2010 RU, Exchange 2013 CU10, Exchange 2016 or above but otherwise should just work.

Unfortunately when a user tried to use this feature it didn’t work.


This message could not be sent. Try sending the message again later, or contact your network administrator. You do not have the permission to send the message on behalf of the specified user. Error is [0x80070005-0x0004dc-0x000524].


Notice that this mentions the send on behalf rights. Well in this case the user didn’t have those but instead had the more powerful Send-As rights.

Well it looks like Microsoft are running a bit late on the rollout with this other article (https://technet.microsoft.com/en-us/library/jj906433%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396) now shifting the rollout completion to Q2 2018.


NoteNote:
As of February 2018 the feature to support Full Access and Send on Behalf Of is being rolled out and expected to be complete by the second quarter of 2018.

Either way it’s not much longer but in the interim you may need to keep assigning send on behalf rights prior to migrating mailboxes. This will save you having to use powershell to do this post-migration since the on-premises ECP interface doesn’t support granting these rights to cloud mailboxes.