Recently we ran in to an issue while preparing a Lotus Notes customer (let’s call them Company A) to migrate to Exchange Online.As we started to prepare the customer for the first directory sync, the customer had a requirement to start leveraging Microsoft Online and SharePoint Online.Since the customer signed up for standard licenses, we knew were only going to create temporary accounts until the directory sync accounts could be leveraged.As the temporary accounts were created, some of them were additionally stamped with their on-premise email address to support notifications from SharePoint Online.Since Exchange Online was not set to receive inbound messages from their domain, it was not recognized as a major issue (at least not until we were ready for directory sync.)
Company A has a partnering company they work with regularly (let’s call them Company B.) It just so happens that Company B is also a subscriber of Exchange Online and has fully migrated to Exchange Online.This is where the problems started to occur…Normally when Company B emails a user in Company A, the message comes through to Lotus Notes just fine.When the temporary accounts for Company A were setup in Exchange Online, this is when the problems started to occur.Somehow Company B was recognizing that Company A had existing mail objects and would force all message to be delivered as if they were MAPI recipients, even with the delivery path set to Lotus Notes (by MX record.)The resulting message to the Lotus Notes user was a winmail.dat message.What’s even worse was the winmail.dat message could not be converted to a normal message, resulting in a completely unreadable message.Here is an example of the configuration:
After validating that the registered Company A domain was setup properly (not to deliver internally), it was determined that by having a mailbox, but not delivering to it, was causing the problem.Since these accounts were considered temporary, we decided to remove the Company A email address from the activated mailbox.To further test if this would be a problem in coexistence, we decided to jump ahead in the schedule and directory sync a couple objects to Exchange online, tie their Company A email address to the object, have Microsoft Support run MAPIRECIPIENT=FALSE on the Company A’s accounts, and validate mail delivery.
By doing so, we discovered that mail delivery would start to function again and messages would not arrive as the notorious winmail.dat issue.
