Today's #TipTuesday post is a pretty short one. A client of mine recently merged with another firm and part of that was everyone getting new email addresses for a new web domain. For most of the users that used email functionality in GP, it was a non-event: they simply logged into the "Exchange Log On" prompt with their new email and password and continued with their task.

For one user, however, they were stuck in an endless loop of "Login Failed: check your login information and try again.". In this case, the user had gotten married and had a name change so their Exchange profile had numerous aliases in it, which may be related to this, but I'm not 100% sure of that (it was the only "unique" thing I could think of for this individual).

Background

The user was attempting to change an email address on a vendor, but it didn't matter what they were doing, as any attempt to open any window with email functionality would not let them past the "Exchange Log On" window.

Exhange Log On window
Exchange Log On window, showing the error “Login Failed”.

Since the user had aliases with their married name and previous name, plus old and new email address domains, there were four combinations we tried to ensure there was no valid combination that would work. The user was careful to type the password in the same each time and had done it enough times that I had no concerns that it was being mistyped. They had tried this multiple times before me requesting they do it all again with me watching. (Consultants can be annoying that way! :) ).

Resolution

In the end, I followed some of the troubleshooting documentation (links below) to work with the SY04920 ("User Exchange Server Address Master"). It caches the last successful attempt at logging in via the Exchange Log On window.

The first suggestion is to remove the record of the person attempting to log in, and GP should cache the value again once the user exchange login is successful. In our testing, that did not have an impact, they still got the error message. On my user ID, I am in the table twice from testing various email functionalities over the years, with both the old and new internal email addresses. The old one has zero impact on my ability to open GP and do anything related to email.

The screenshot below is the table with what this looks like on my instance of GP. Both my email and this client use Office 365 so the URL is identical; GP uses Exchange Web Services to send email (EWS).

SY04920 table
Screenshot of SQL script and results from querying the SY04920 table.

My second idea was to manually create a record to populate the table with the user's new email address, and that worked. 

⚠️
Caution! This falls under the category of an unsupported action.

I am not going to provide the script since it is not technically supported, but I will say that I inserted a record into the SY04920 table with the UserID, email address and Exchange Server URL and the user was then able to log in without any issue. My only guess is it was not able to auto-discover their credentials for some reason, where other users had no issues.

If that hadn't worked, my third idea was going to be to recommend they try the Advanced login, which is clicking on Show Advanced in the Exchange Log On window and entering either DOMAIN\USERID or re-entering the email address. That often seems to work, and in my instance of GP, I need to do that.

Resources

Here are some handy resources for all things email inside Dynamics GP:

  1. Email troubleshooting guide (official Microsoft docs)
  2. Support KB that explains the Show Advanced option in a bit more detail.
  3. GP Support team blog about emailing with Exchange and more detailed information

Summary

I hope this helps someone out there. Most times just logging in with the Advanced Options visible is enough to work around most situations, but sometimes I get an odd scenario like this where the issue is related to one specific user in an environment.