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 really matter what they were doing, as any attempt to open any window with email functionality will prompt a GP user with this window: “Exchange Log On” is the title of the window.
Since the user had alises 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 actually 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 repeated typos. They had tried this multiple times prior to 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 table. That is called the “User Exchange Server Address Master” and 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 succesful. In our testing, that did not have an impact, they still got the error message. On my own user ID, I am in the table twice from testing various email functionality over the years, with both the old and new internal email address. The old one has zero impact on my ability to open GP and do anything related to email.
I’ve also pasted below the screenshot what this looks like on my own instance of GP. Both my email and this client use Office 365 so the URL is identical; GP uses the Exchange Web Services to send email (EWS).
My second idea was to manually create a record to populate the table with the user’s new email address, and that actually worked. *** CAUTION *** this falls under the category of a totally unsupported hack, so I am not going to provide the script to do that, 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 have worked, my third idea was going to be recommending 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 on my own instance of GP, I need to do that.
Resources
Here are some handy resources for all things email inside Dynamics GP:
- Email troubleshooting guide (official Microsoft docs)
- Support KB that explains the Show Advanced option in a bit more detail.
- 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 you get an odd scenario like this where the issue is related to one specific user in an environment.
*This post is locked for comments