Link to home
Start Free TrialLog in
Avatar of Dimarc67
Dimarc67Flag for United States of America

asked on

O365-created MEPF's can't receive internet mail after PF migration to cloud

We have a Microsoft Exchange Hybrid environment, meaning that we are using Azure AD Connect to synchronize our on-premises Active Directory objects (users/mailboxes) to our Azure AD and Office 365 cloud presence.  We completed migrating all mailboxes to O365 about 9 months ago, and all Exchange Public Folders about 2 months ago.  All went well and was ultimately error-free.

To support our Barracuda Email Security Gateway appliance, we have configured all inbound/outbound cloud mail to route through our on-premises Exchange server.  We've had no major issues, and our mail clients are working well.

However, we recently discovered that Mail-Enabled Public Folders (MEPF's) that were created after migrating all PF's to the cloud are unable to receive mail from the internet.  (Internal mail is received without issue, and we've confirmed MEPF permissions include CreateItems for Anonymous users.)  

Internet senders receive a bounce-back NDR message that states:
"#5.4.4 smtp;554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop".  

In an Exchange Hybrid configuration like ours, we're aware that all new mailboxes must be created on our on-premises Exchange server in order for the associated AD objects to be synchronized to our Azure AD.  Once sync'd we then migrate the new mailbox to O365.  

However, we can find no analogous procedure for creating new cloud-hosted MEPF's.  Because our new MEPFs were created in the cloud, our on-premises AD and Exchange have no awareness of them, so mail addressed to them is routed back to the internet--which promptly routes it right back to our Exchange server (hence, the NDR's "loop").

We can find no information regarding how to support new MEPF's in this scenario.  Once we completed our PF migration to Office 365, our on-premises public folder mailboxes were made unavailable by necessity, so there's no ability we know of to create a mail folder on-premises in order for its AD objects to be subsequently sync'ed to Azure.  Even if we did create folders on-premises, there's no support to migrate public folders individually to the cloud--only whole pf mailboxes, which we've already completed.

Ultimately, we need to know the recommended solution for supporting cloud-hosted MEPF's in an Exchange Hybird environment with mail being routed through the on-premises Exchange server.  Technical detail and documentation links are hugely appreciated.

TIA.
ASKER CERTIFIED SOLUTION
Avatar of Vasil Michev (MVP)
Vasil Michev (MVP)
Flag of Bulgaria image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Dimarc67

ASKER

Vasil--

The Microsoft documentation link you provided is EXACTLY what we need.  Thanks very much!  (Microsoft support has been trading emails with us for over a week now, and has yet to fully understand the issue much less provide helpful information.)

Can you give an example of creating an on-prem recipient in AD?  What object type do you suggest to create?
Any type would do, but mail contact should have least overhead.
Thanks, Vasil.  May yet go that route after this morning's fire drill.

Configured and ran Microsoft's Sync-MailPublicFoldersCloudToOnprem.ps1 script per their documentation...which actually inverted our issue.  Before, internet mail senders would receive an NDR bounce-back message when emailing MEPFs we'd created in the cloud.  After running the script once, the issue was now occurring for our migrated MEPFs while no longer occurring for cloud-created folders (SMH).

Examining the PF objects in onprem AD, the targetAddress was set to our primary domain instead of our onmicrosoft.com alias.  Wrote and ran the following one-time PowerShell script to correct the targetAddress values.  This (finally) corrected mail reception for all MEPFs.

$BrokenPFobjects = (Get-ADObject -Filter 'ObjectClass -eq "publicFolder"' -Properties targetAddress | ?{$_.targetAddress -notlike "*domain0*"})
ForEach ($PF in $BrokenPFobjects) {
    $OldTargetAddress = $PF.targetAddress
    $OldTargetAddress
    $UpdatedTargetAddress = $OldTargetAddress -replace "domain.com","domain0.onmicrosoft.com"
    $UpdatedTargetAddress
    $PF | Set-ADObject -Remove @{targetAddress=$OldTargetAddress} -Verbose
    $PF | Set-ADObject -Add @{targetAddress=$UpdatedTargetAddress} -Verbose
}

Open in new window


Will need to do subsequent testing and possibly adding corrective code with the Sync-MailPublicFoldersCloudToOnprem.ps1 script to prevent further similar issues.
The Expert provided precisely what was requested.