#550 5.2.0 RESOLVER.PF.Invalid; misconfigured public folder mailbox #

If you find yourself in the above scenario, here is an explanation and solution you might like to consider.

During the migration from the local Exchange to Office 365, you have a lot of planning, dilemma, and decisions to make. 

Some of the most important decisions you'll be faced with are how to handle the mail flow which is coming from a variety of equipment, servers and applications installed in your local networks, and then sent to Exchange Online mailboxes and/or mail-enabled Public Folders. 

• Should you configure a local SMTP relay server on the Exchange server or just a simple SMTP service from Microsoft?
• Should you use third-party SMTP server installed on your own premises?
• Or maybe there are not so many scanners, servers, and applications in your network that it would be easier to change their configuration to use an Exchange Online as the SMTP server. But remember that in this scenario, each device or application must be able to connect to, and authenticate with Office 365. 

Here is an article from Microsoft which describes possible scenarios I recommend you should read: How to set up a multifunction device or application to send email using Office 365

SMTP relay based on the local Exchange server

There are a few reasons to use this as a solution.

• Tight schedule for a migration project. There was no time or resources to redesign your setup. Several hundred scanners which do not have access to the Internet. To change that would require a redesign of your network setup, policies and would involve extra resources. 

and/or...

• Some devices and scripts which were sending reports by mail were not able to use SMTP authentication or didn't support TLS which is required by Exchange Online.

and/or...

• You needed to send emails to external recipients. The above mentioned Micorosft article recommends the 3^rd option in this situation.

Exchange 2016 is available for free for hybrid configuration and could be monitored by SCOM (Microsoft System Center Operations Manager) which we can use for surveillance.  So the choice of the Exchange version was pretty obvious. 

Everything is set but ... can't send any emails.

If you choose to use the local Exchange as an SMTP relay, then you have to create a Receive and Send Connector. 

A Send Connector is used for sending emails out to Office 365 and uses the Exchange Online as a smart host. The Receive Connector receives emails from all of your on-premise devices and applications. 

Because the Receive Connector might use Anonymous Users as Permission Group (which was in my case) you should secure it by narrowing down the IP scope and list those devices which are known to be sending emails. 

Even if you set Anonymous Users in the Permission Group of the Receive Connector, there may be one extra step you'll have to complete in order to use the connector with success.

• You'll need to grant relay permission to anonymous connections on the new Receive Connector.

Here's a sample command based on the article Allow Anonymous Relay on a Receive Connector

Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

If you don't do this, during the mail handshake you might see the following error which will prevent sending emails:

mail from: user@domain.com,
530 5.7.1 Client was not authenticated

#550 5.2.0 RESOLVER.PF.Invalid; misconfigured public folder mailbox # 

The migration process for me went smoothly until the Public Folder mailbox database and server had been shut down and deleted. Then whatever device or application was trying to send an email to the mail-enabled Public Folder migrated to Exchange online, ended up not delivered with the following error report:

Delivery has failed to these recipients or groups:
mail-enabled-public-folder@domain.com
There's a problem with the recipient's mailbox. Please try resending the message. If the problem continues, please contact your helpdesk.

Diagnostic information for administrators:
Generating server: EXCH.domain.com
mail-enabled-public-folder@domain.com
#550 5.2.0 RESOLVER.PF.Invalid; misconfigured public folder mailbox ##

It turned out that decommissioning of the on-premises Public Folder database deletes a Public Folder Hierarchy in Active Directory. To check it out you need to open ADSI Edit, connect to a Domain Controller. change the context to Configuration and navigate to:

Configuration ⇒ Services ⇒ Microsoft Exchange ⇒ [your organization] ⇒Administrative Groups ⇒ [Exchange Administrative Group (xxx)]

If you cannot find this object CN=Folder Hierarchies you'll need to create it.

Recreating public folder hierarchy to fix the issue

The issue and solution have been described by Bill Long in the Fixing Public Folder Directory Objects That Aren’t Linked To The Hierarchy article long time ago. So I will focus on what's missing there - creating the public folder hierarchy and fixing the issue manually. 

If you want to recreate the Folder Hierarchies under the Exchange Administrative Group follow these steps:

1. Open ADSI Edit, connect to a Domain Controller, change the context to Configuration.
    
   
2. Navigate to Configuration ⇒ Services ⇒ Microsoft Exchange ⇒ [your organization] ⇒Administrative Groups ⇒ [your administrative group]
   
   
3. Right-click on your administrative group and select New Object
   
   
4. Select msExchContainer as class and click Next
    
   
   
5. Enter the following as value: Folder Hierarchies, click Next, Finish
   
   
6.  Right-click Folder Hierarchies and select New Object
    
   
7. Select msExchPFTree as class, click Next
   
   
8. Enter the following as value: Public Folders, and then click Next
   
   
   
9. Click on the More Attributes button, drop down the “Select a property to view:” list, select msExchPFTreeType and set the attribute to 1 (it should populate into the value field).
   
   
10. Click OK to Finish.

Now to fix the issue you can skip linking the store to the hierarchy object (as described in the Microsoft Technet Article mentioned above) by setting the msExchOwningPFTree value because you do not have any mailbox database stores for Public Folders anymore on-premises. 

Instead, you just need to put the distinguishedName of the newly created object into the HomeMDB attribute for each mail-enabled Public Folder. 

If you have only a few mail-enabled Public Folders you can go ahead and fix it manually, but if you have more, it's much easier to use the script published in Bill's article. 

To fix it manually you may follow these steps:

1. Double-click the newly created “Public Folders” object (see instruction above)
   
   
2. Double-click distinguishedName attribute
   
   
3. Copy the value to your computer's clipboard
    
   
4. Click Cancel.
   

In the ADSI Edit, change the context to Default naming context.
 

1. Navigate to CN=Microsoft Exchange System Objects
    
   
2.  Double-click each mail-enabled Public Folder
   
   
3. Find and double-click the homeMDB attribute and paste the copied value
   
   
4. Click OK.
   
   

Now you fixed it in one folder. Check how many left and if there are many more, consider scripting it to save time. 

Alternate solution

The above is a short-term solution just to put out the fire (and let my phone turn from red to black again). 

In my opinion, you should not stick to this if you are going to use mail-enabled Public Folder in the future for your organization. Every time you create mail-enabled Public Folder in Office 365 and it may be emailed by the on-premises scanner, application or device, you have to remember to create a reference AD objects on-premise. 

I have decided to convert all AD objects which referred to mail-enabled Public Folders into mail contacts. It allows 1^st Line Support to maintain it as standard changes letting you focus on other challenges in your organization.

You may ask - so how to convert? Well, this is material for another article. 

Summary

If you can stop businesses sending emails from on-premise devices or applications to mail-enabled Public Folders, do so. Otherwise, try to convert mail-enabled Public Folders into shared mailboxes. This should make administration tasks far more simple in the future.  

I hope this article was informative and helpful for those of you who found yourself in trouble.

I'll be looking forward to seeing your comments, suggestions and your own solutions taken from the battlefield in regards to migrated Public Folders.  Please do so in the comments below.