Monday, April 13, 2015

Dynamics GP 2015 eConnect error: The source was not found, but some or all event logs could not be searched.

By Steve Endow

UPDATE: See comments at the bottom of this post for a resolution: Temporarily add the eConnect service account to the Local Administrator group.

UPDATE 2: I just worked with a customer where adding the eConnect domain user to the Local Administrator group still didn't resolve the issue.  Lacking any other ideas, the system administrator at the customer rebooted the server.  After the reboot, the eConnect error was properly written to the event log.  So it seems that in some environments, a server reboot may be required.

After upgrading an eConnect integration to Dynamics GP 2015, I received the following strange error message:

Exception type:Microsoft.Dynamics.GP.eConnect.eConnectException
Exception message:The source was not found, but some or all event logs could not be searched.  To create the source, you need permission to read all event logs to make sure that the new source name is unique.  Inaccessible logs: Security.
Stack Trace:   at Microsoft.Dynamics.GP.eConnect.ServiceProxy.CreateTransactionEntity(String connectionString, String xml)   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.EntityImportImplementation(String connectionString, String sXML, Boolean isTransaction)   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.ProcessEntityImport(String connectionString, String sXML, Boolean isTransaction)   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.CreateTransactionEntity(String connectionString, String sXML)

That part that stood out was "Inaccessible logs: Security".  This reminded me of some errors I've seen where an application is trying to write to a windows Event Log that doesn't exist, that it is unable to create, or that it doesn't have permissions to write to.

I looked all of the logs Windows Event viewer, but couldn't figure out what was causing the error.

After running the GP 2015 integration a few more times, I eventually received an error I did recognize.
Error Number = 936  Stored Procedure= taPMDistribution  Error Description = Vendor number does not existNode Identifier Parameters: taPMDistribution

Once I fixed the vendor ID in my test data file, the integration ran fine and I didn't receive the strange "The source was not found" message again.

I then installed the integration on the customer's workstation, and once again, the "The source was not found" error message appeared.  After a few more tests, we received a standard eConnect error message, fixed the data, and the integration ran fine.

My guess is that there is some type of issue with the eConnect 2015 install or the process that creates or writes to the eConnect event log when the first error is encountered.  The error appears once, and then things get straightened out in the log, and subsequent errors are logged properly.

Since the error does go away and appears to be a one-time event, I believe that you can safely ignore this message.  Unfortunately it is confusing for users, but if you remember to warn them in advance, or are able to recognize the error and explain the issue to users, it shouldn't be an issue.

And here's some GP geek trivia:  Did anyone notice that the error message refers to "eConnect12"?  Even though the internal version number for GP 2015 is version 14?  

Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter


go away said...

I had the same error message with eConnect 2015 and was able to resolve the error message by making the eConnect service a local administrator and then repairing the installation of eConnect. I was then able to remove the eConnect service account from the local administrators and I have had no erros since.

Steve Endow said...

Thanks for the tip--that makes sense. I previously thought that elevating the user account that is running the eConnect integration might get past the log issue, but your approach makes more sense, as it would be the eConnect service creating the logs, not the integration itself.


Chad Bruels said...

I just had the pleasure of working on this error message. The user accessed GP via a terminal server, but with a shortcut which ran the application directly on her machine - a scenario I admit I am not used to. The error listed her user so I thought the same as you, that elevating her account on the terminal server would be the way to go. However, again it was elevating the service account running the eConnect service.

Thank you for the post, and to "go away" for the comment.

Tanya Henderson said...

I also just had the pleasure of working with this message and thank you go away we did exactly what you did with the permission on the eConnect user and this is what worked for us thank you!

Marla G said...

Hi Steve:
Once again I searched on the text of this error in my econnect log (using Gorilla Expense). Of course that was after I chased the security setup for a short while and found that my econnect service was fine and the user was already an admin on this machine. But looking closer after reading your blog I saw that the issue was a bad GL account string. Sure enough when we fixed the account number the expense report went to GP without a hitch.
As I said already, THANK YOU THANK YOU

Hope that I will see you in Fargo next August. Although as I am typing this I realize that is pretty funny when we are both coming from So Cal!

Marla Greenman