Server Side Sync with Forward mailbox and SMTP

Server Side Sync with Forward mailbox and SMTP

by | Feb 17, 2019

Most often when setting up server side sync, especially in Online environments, Dynamics 365 CE/CDS is connected to Exchange Online. This is rather straight forward. Even in less straight forward cases like On-prem to On-prem or the so called hybrid cases of on-line to on-prem where the involved parties are Microsoft Dynamics 365 and Exchange in some manner are all rather well documented and might be a bit tricky but generally there are some good instructions for how to get it working. Like for instance this. However, if your setups require more complex email management then the documentation and blogs around the Internet start getting a lot sparser. This article will detail a complex setup with Server Side Sync using Forward Mailbox to a proxy O365 exchange account and outgoing email using SMTP using the SMTP service SMTP2GO.
I recently migrated a customer with a complex setup from Email router to Server Side Sync as the Email router has been long deprecated and the indications I am getting from Microsoft are that it is hight time to start transitioning away from it to Server side Sync or to some other solution that can solve it, like for instance Riva. I will not go into the advantages of using that in this post, but generally it can be said that it has a lot more configuration options and logging options available, but at a price of course. Most of my customers try to get the Server Side Sync (SSS) to work and if this cannot be done, then other venues, like Riva or custom code are evaluated.
The background to why this complex setup was required was that my customer had their main Exchange server managed by their parent’s parent company in Germany. If you are not aware of the requirements for setting up Server Side Synchronization (SSS) from Dynamics 365 to an Exchange, it requires the use of an account using “Application Impersonation”. Asking the Exchange admins for this permission, although I have heard (I am no Exchange guru though) that is can be limited to specific users, was perceived to be practically impossible. We could, however, setup Forwarding rules with “Forward as attachment” on the public folders where the incoming emails were received.
As for outgoing email, the story was more or less the same. We could not connect to the Exchange server in Germany to send any emails. However, my customer were allowed controll over the DNS entries of the domains they worked with hence they could add SPF records to other email sending servers. When using the Email router, we had installed this on a VM hosted in Amazon Web Services and then sent email using the Amazon Simple Email Service (SES) on port 25. When we tried this with Server Side Sync, however, we noticed that we were now “outside traffic”, no longer coming from inside Amazons networks, and were hence throttled on Port 25. We tried all other possible SMTP ports for SES but nothing seemed to work with SSS.

Incoming – Forward mailbox

Ok, so how to solve it? Let’s start with the incoming email. As I have hinted the best method for this is to use the “Forward Mailbox” technique. This means that you set up a special mailbox, you actually create a new mailbox in Dynamics of the type Forward mailbox. This is then linked to a normal Exchange mailbox user account. It cannot be a public folder or something else. It has to be a user. You might be able to use a O365 Exchange Kiosk but be aware of the size limitations if you decide to keep the email on the server. Otherwise an E1 is probably recommended. This email address is never seen by any customer, so can be rather obscure, like forwardmailbox@contoso.onmicrosoft.com.

Rules are then set up on the onprem server to forward emails coming in to all relevant email addresses (be it users, public folders, groups or otherwise) as attachments to this forward mailbox. Why forward as attachment you might ask? The reason is that it keeps the entire header of the email intact which allows Dynamics to parse it and connect it correctly. Below is an figure discribing this incoming email flow with two queues. Typically you would have many more queues. My customer has 100+ queues.

Incoming email using forward mailbox proxied via O365

Setting up forwarding rules for “forward as attachment” is done in the following steps:

Using Outlook Web Access, click on the Settings cog (1) and then Mail (2).
Go to Inbox and Sweep rules and press (+) to create a new.

Apply it to all email (if that is what you want) and then select the action – “Forward the message as an attachment to” and select the Forward mailbox contact that either created before or do it in the next step.

This is how you create a contact (this is rather straight forward)

After this, you should have a forwarding rule which is activated and you should be able to start seeing emails landing in the forward mailbox shortly after they have arrived in the normal inbox, and with the orginal email as an attachment.

When creating the forward mailbox you have to remember to get a global admin to approve the email address (1) even if you switched this off for users or queues. You also need to “Test & Enable Mailbox” (2)

Outgoing – SMTP

Outgoing email we solved by finding an SMTP service that did support Dynamics 365. As mentioned above we first tried working with Amazon Simple Email Service but found that there was no combination of settings that would make this work. The best possible option was port 25 using TLS, but as we were “outside” traffic (as compared to when we were using the Email router and running on a AWS VM) we got throttled rather quickly and I couldn’t even get the 100+ queues through the Test & Enable until things started breaking.
It is important here, to understand that there is a difference between SMTP using TLS (more modern way of securing SMTP) and using SMTP with SSL. The former seems to be what Dynamics 365 is using though I havn’t found any really good definition saying this is so.

It turned out that my customer was using SMTP2GO for another service so we tried it out and it worked fine using port 587 using TLS. SMTP2GO, it seems, has a load of different ports and variations of security setup that can be used. According to my customers operations people, they also like it better than Amazon SES as it gives better feedback on bounces and such which is good (data which would be nice to get into Dynamics of course – good ISV opportunity there!).

Outgoing settings are not that complicated – each mailbox has the Server Profile “SMTP2GO” which uses the SMTP protocol to send

To understand some of the details of how the SMTP2GO Server profile is setup, look at this picture.

The Server Profile for SMTP2GO – note that the Incoming Server location is not used/is relevant.

One of the problems I found was that I wasn’t able to set the credentials centrally, on the server profile. It just seems this isn’t supported for SMTP, I do not know why. Hence we had to add the credential (the same) to each and every single queue. I found this was rather easily done in bulk using SSIS with Kingswaysoft or your other favorite tool for this like Scribe or CozyRoc (I havn’t tried them but I guess you could). Or you can of course write a small program. I did try to do it using workflows or bulk edit but that didn’t work. Maybe with some shoehorning you could get that to work. Maybe a Flow could work too. The fields that had to be set can be seen in the picture below:

The queue mailbox record – Note the three fields marked that you need to set as the credentials are set on the queue level. Also note that as the Incoming is “Forward Mailbox” it will not be expected to be tested in the testrun – hence Incoming Email Status :”Not Run”

Testing SMTP Server/Service
When working with this, and testing out different SMTP providers it is sometimes hard to know where the problem is. Hence it is good to have a good tool to test the SMTP email server to see that it works, that your credential for it work and so on. I got a good tip from one of the operations technicians at my customer, which was the service SMTPer as seen below:

SMTPer – www.smtper.net – great tool for testing a SMTP server

Limitations

What are the limitations of using a technique like this for server side synchronization?

First of all I would say it is that you will not be able to get Appointment, Contacts and Task (ACT) synchronized. Hence it is mostly useful in applications where the Dynamics/CDS is set up to work for Customer Service or in other non-personal uses. If you want ACT synchronization I would recommend trying to get a Dynamics-Exchange synchronization working somehow. Talk to some Exchange experts to see if they have some interesting views on how to solve your issue.

The second drawback of this is complexity. This solution has many moving parts and it can go wrong in many places. There are many different accounts and password that it depends on, thankfully everything will not break if just one password is invalidated, but you will see issues. It is also dependent on different technologies like Dynamics email handling, Exchange rules, SMTP services and so on. This requires rather a broad skillset or several people being involved. Especially if something breaks or just doesn’t work supergood.

Conclusions

Hence, this a setup that I would only recommend if you do not have the option of using Exchange. If you have the option of using Exchange, but cannot get it to work for some reason, try harder or ask for help. Using this kind of solution will limit the end users functionality of Dynamics and is hence more of a “last resort”.

New times, new blog – less nagging!

New times, new blog – less nagging!

by | Feb 14, 2019

Time for a new blog engine, time for a new blog title and time for my own domain to blog from and above all, time for Jonas Rapp to stop nagging about me blogging on blogspot. Old blog is still up and running and I will keep it there for some time as long as people find interesting stuff there.

As you might be aware of, I have been blogging on blogspot since May 24 2006. That is quite some time, almost 13 years now. Some periods have been more energetic than others, and I guess that is only natural. During this time my life has changed a lot. Since then I have gone from a CRM developer being employed as the only CRM-expert and SharePoint expert at Humandata  at that time a smaller company of less than 10 people. I have since worked a couple of years at Logica, now CGI, and 2010 I started my own company, CRM-Konsulterna which now has grown to 15 employees. I have also during this time gotten two kids, Nora and Adrian, who are now 11 and 8. The article on my blog about Nora’s birth being the only one not strictly about Dynamics (and SharePoint as it was originally focused on as well). 

Otherwise, it has received several awards for its content and I generally have tried to focus a lot on the who the readers are and attemted to not write anything that would dilute your trust. I have been given many offers during the years of companies wanting to market their products on my blog and I also during a short time tried some ads but I found that it was really counter acting the point of the blog. I would rather share what I know so that people can build trust in that I know what I do so that they do not hesitate to contract me. Diluting this is just dumb.

But now new times! This new blog is running on WordPress with the world famous Divi Theme. I hope you like it and if you have any comments about the layout or anything else, please leave a comment and I will see to that. I have some articles in store waiting to come out (the store is above my shoulders), one regarding complex email setups with Server Side Sync which I think many might find interesting as it is not a very common scenario so when you run into it, a good references might be needed.

I have imported the old blog entries into this blog. They might be sorted a bit weirdly and so, I won’t put too much energy into fixing that, more into writing new stuff.

Hope to hear from you in the future and that I have will have the strenght to continue this blog for the next 13 years.

Gustaf