We came across this rather strange problem with the Outlook app for Dynamics 365. No matter what we did we couldn’t get the Dynamics 365 to talk to an on-premise Exchange server. The connection tests failed, the OWA froze when tracking an e-mail and the logs were of little to no help. I bet many of you have found yourself in similar situations in the past, so I would like to spare you a potential déjà vu when it comes to the Outlook app. I won’t bore you with all the tests we made that didn’t lead anywhere and instead focus on the ones that did, and of course the solution.

The problem

I have made similar deployments before and it is usually quite straightforward. An app impersonation account is set up to handle the communication between Dynamics 365 and Exchange, an Email Server Profile is configured in Dynamics 365 and the app is pushed out to the clients. However, it turned out it really wasn’t that easy this time.

When testing the Email Server Profile, we got success on the HTTPS connection. But it failed when trying to connect to the Exchange Web Service and that also meant that the connection to the app impersonation mailbox failed. The error log said “Remote server error: (401) Unauthorized. Make sure the user name and password you entered are correct and try again”. This didn’t really help to pinpoint the problem since we verified that the user name and password were correct and still got the same error message.

Testing connectivity with the Oulook app

We had pushed out the Outlook app to our test user and figured we might get some information from trying to launch the Outlook app in the OWA. All we got was a message saying it were getting things ready for us and then nothing happened.

So we went to https://testconnectivity.microsoft.com/ and ran the Service Account Access test with Exchange impersonation and after some tweaking the test was successful. Problem solved we hoped. But no, we still got the same error message in the Email Server Profile test and the same static page in OWA.

We spoke to Microsoft support, performed some tests together and generated a fiddler log for them to analyse. Unfortunately, nothing came of this, so we were back at square one again.

Pulling strings, like a MVP

After a lot of tests, time and frustration, our CRM MVP @Gustaf Westerlund managed to pull some strings and got some information that hadn’t made it down the line at Microsoft: the problem is most likely with the Exchange server certificate and if that didn’t help we should try using NTLM.

The Exchange admin looked at the server and found out that the thumbprint on the ”Microsoft Exchange Server Auth Certificate” didn’t match any of the thumbprints for the self-signed certificates. Strange indeed. A new certificate was created and published on the server.

To test if this had solved the problem I logged in to OWA and clicked on the Dynamics 365 link. Now I got a blank pop-up window to “…crm4.dynamics.com/crmmailapp/auth.html#id_token=” followed by a long token sting. Back in the OWA tab I got the same message about setting things up for us and nothing else. I then tried logging in to Dynamics 365 in the browser before tracking an e-mail and after a while I received an error saying an error occurred during login. It looked like we needed to get the NTLM up and running and I informed the Exchange admin to go ahead.

Troubleshooting on both ends

At this time, I had another screen sharing meeting with Microsoft’s 2’nd (or 3’rd?) line support. We ran fiddler on my end and he looked at the server logs on his end. Everything seemed fine. We then doublechecked the Dynamics 365 app for Outlook page in Dynamics and saw that after all the tests we had done, our test user was no longer shown in the list of eligible users. However, according to Microsoft the app manifest file was cached for the mailbox, making it look like the app was installed and could not connect to the server when it in fact wasn’t installed.

Breakthrough

So, we reapproved and tested the mailbox and it turned up again in the list with the (wrong) status “Added to Outlook”. We then pushed out the app to the mailbox again. After the installation was complete we tried it in the OWA. The same white pop-up window appeared when I clicked the Dynamics 365 link, but after a couple of seconds I was redirected to https://login.microsoftonline.com. I logged in with the cloud username and password and voilà, it finally worked! We then proceeded by executing quite a lot of tests in the OWA and it worked like a charm. After a short celebratory dance, we went ahead and tested the same tasks in an Outlook client and lo and behold, it worked as well.

As I am writing this, a pilot group of users have been running the Outlook app in their daily line of work and I have yet to receive anything but good feedback from them. Great success!

Final thoughts

Even though we have got the Outlook app to work, there are still 2 questions that we don’t have any answers to.

The Email Server Profile in Dynamics 365 still fails on 2 of the 3 tests. How can the app work when the test says it can’t connect to the Exchange server?

How come it looked like the app was installed for the mailbox even though it wasn’t?

A question we do have an answer to however is: Why was the Exchange certificate incorrect to begin with? It turns out that the mail server crashed a couple of years ago and a backup was restored to a new server. The restore overwrote the certificate on the new Exchange server which led to the configuration pointing to a server-to-server certificate that didn’t exist. To make it worse, you can’t even see this in the GUI, you must use cmdlets.

A big thank you to Jonas Ekvall at Ekvall-data.se for his work with the Exchange server.

You might also be interested in reading Gustaf Westerlunds article about the same topic.

Extras

And for those of you that are interested in how to manage the certificates on the Exchange server:

From EMC – Go to Server/Certificate

  • Edit all self-signed certificates and check the corresponding thumbprint

From EMS – Check the thumbprint for the actual ”Microsoft Exchange Server Auth Certificate”

  • Get-authconfig

How to create a new ”Microsoft Exchange Server Auth Certificate” with the cmdlets:

  • New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName ”cn= Microsoft Exchange Server Auth Certificate” -FriendlyName ”Microsoft Exchange Server Auth Certificate” -DomainName server.domain.com -Services smtp

(Do not accept to replace the SMTP certificate when prompted)

From EMC – Go to Server/Certificate, edit the new certificate and copy the thumbprint

Replace the old reference to “Microsoft Exchange Server Auth Certificate” with this new certificate with the following cmdlets in EMS:

  • $a=get-date

Set-AuthConfig –NewCertificateThumbprint {insert the thumbprint we copied} –NewCertificateEffectiveDate $a

(Accept even though the certificate effective date is not 48 hours into the future)

Set-AuthConfig –PublishCertificate

Set-AuthConfig -ClearPreviousCertificate