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. 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 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 anymore - 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 had been doing some network and permission cleanup in recent days and inadvertently removed some groups' "log on as a service" permissions.
The moral of this story? If there is an error, check the event viewer too, to see if there is more specific information there about it. 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.
