Learn the essential functions of CompTIA Security+, which establishes the core knowledge required of any cybersecurity role and leads professionals into intermediate-level cybersecurity jobs.
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.
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
There are a few reasons to use this as a solution.
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.
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.
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: email@example.com, 530 5.7.1 Client was not authenticated
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: firstname.lastname@example.org 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 email@example.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.
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:
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:
In the ADSI Edit, change the context to Default naming context.
Now you fixed it in one folder. Check how many left and if there are many more, consider scripting it to save time.
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 1st 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.
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.