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.

Incoming email using forward mailbox proxied via O365

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

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.

Outgoing – SMTP

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!).

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

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”.