eConnect error “configured identity is incorrect”

A client recently had an issue with their nightly eConnect integrations, getting an error about the username and password.

This integration had been live for nearly 2 years, running every night, and running without issue - or at least without this kind of issue. In other words, fairly stable.  They also never touch the service accounts, so the thought that the password might have been changed was nearly impossible.

The Error

The text of the error was:

Error type: Unknown Code: 1000 Location: e-Connect User Message: The server process could not be started because the configured identity is incorrect.  Check the username and password. (Exception from HRESULT: 0x8000401A) Description: System.Runtime.InteropServices.COMException (0x8000401A): The server process could not be started because the configured identity is incorrect.  Check the username and password. (Exception from HRESULT: 0x8000401A)

The client is using Dynamics GP 2010 and the accompanying eConnect version for their integrations.

Troubleshooting

I researched the error the normal way, using “Dr Google” as one of my clients calls it.  (My bad, I guess I should say “using Bing!”, but alas, old habits die hard).  We got many hits on this error but everyone’s experience was one of two things:

• You need to use a domain account for the identity (this client already was using a domain account)
• The password must have been changed by someone (this was verified as not the case)

So, we were a little stumped until someone thought to check the Event Viewer on the server. In my role at this client I don’t have access to the server on which this integration runs (it doesn’t run on the actual GP sql server), so thankfully, one of the clients thought to look there to see if by chance there was more information. Sure enough, the event viewer log was much more specific!

The description in the error was “Logon failure: the user has not been granted the requested logon type at this computer”.  In short, the Active Directory account didn’t have permission to log onto that server any more - nothing to do with the username or password configuration being incorrect.

At that point we went back to the IT team, and sure enough, they were doing some network and permission clean up in the recent days and inadvertantly removed some groups’ “log on as a service” permissions.

The moral of this story?  If you get an error, check the event viewer too, to see if there is more specific information there about the error. In this case, it was obvious what the issue was but since no one checked there initially, we wasted a couple of days trying different things first.