Are you in the migration process of your Exchange to Exchange Online?
Be aware of customized solutions developed on the transport role on your old Exchange server. They might not be convertible to Exchange Online!
There is no doubt that every migration to Office 365 needs quite detailed revisions of your existing environment. You shouldn't focus only on the Exchange server but think in a wider perspective finding all dependencies which might not be realized at first glance.
Along with one of my last migrations to Exchange Online, I found a business process which was related to the Exchange transport layer. There were a few mailboxes monitored for specific incoming emails. When the mail with attachment had been sent to one of this mailboxes, the attachment had been extracted from the message and saved to a particular folder dependent on the sender or type of the file. The process was business critical and any other solution was not acceptable.
As you may know (or not), after migration to Exchange Online your possibilities of the customization of the transport layer are limited to the transport rules which might not meet your expectations although there are a lot of available options.
The solution for this particular process has been officially released in 2016 and it is Microsoft Flow.
How the Microsoft Flow controls emails and handles attachments?
Microsoft Flow doesn't work on a transport layer. Instead, the Flow can check the mailbox for any new emails and process them according to your needs and based on conditions you set.
One issue I faced is that the Flow cannot save attachments on-premise unless you install an On-Premises Data Gateway. If this is not acceptable you might use FTP for uploading files to an on-premise file share. I end up saving attachments in SharePoint Online and developed a script which moves files to on-premise file share.
The business process requires a bulletproof solution
Although the Microsoft Flow is a quite new solution, from day to day it becomes more mature. Since May 2017 the flow can be controlled against errors and act upon them. The process of building error handling is described at Error handling steps, counters, a new flow details experience and more article on the MS Flow blog.
Disadvantages of the Microfot Flow
Though the solution is fast developing, there are some major disadvantages which you may find difficult to accept.
- There is a history of the Flow runs but it is available only in the web interface and not searchable. At the time I am publishing this article there is a suggested improvement which you can vote on to get Microsoft attention on this issue. Here is the link.
- There is no PowerShell cmdlet for the MS Flow available. So if PowerShell is your daily work tool, forget about building or monitoring the Flow from PowerShell for now.
- The web interface sometimes makes the Flow building or editing very difficult. And believe me, this is gently said.
I hope this article put some more light on the issues you may encounter when migrating to the cloud and a solution you may use. I am sure we all would love to hear from you what unusual business process have you found during the Exchange migration to the cloud and how you solved it. Feel free to share with us in comments below this article.
If you found this article helpful and informative, please do consider clicking the Thumbs Up icon at the bottom left of this article. Thank you.