I will no longer be posting to Dynamics GP Land, and all new posts will be at https://blog.steveendow.com
Thanks!
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.
UPDATE 3: I just built a new GP 2018 VM and encountered this eConnect permission error. After adding the eConnect windows user to the local Administrators group, I still got the logs error. I then restarted the eConnect service, and that seems to have reloaded eConnect with the Administrator rights, and the error went away. So, it could be that a server reboot may not be required, but a restart of the eConnect service is needed to refresh the permissions.
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.
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.
ReplyDeleteThanks 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.
ReplyDeleteSteve
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.
ReplyDeleteThank you for the post, and to "go away" for the comment.
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!
ReplyDeleteHi Steve:
ReplyDeleteTHANK YOU THANK YOU THANK YOU
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
It is really telling that MSFT still was not fixed this install blunder.
ReplyDeleteThere is a much simpler and more direct way to fix this than messing with credentials. Use the following powershell script in an elevated PS prompt on the machine you are running eConnect from. You may still need to reboot but this should add the sources eConnect is complaining about:
function CheckCreateEventSource ([string] $aEventSource) {
if ([System.Diagnostics.EventLog]::SourceExists($aEventSource) -ne "True") {
[System.Diagnostics.EventLog]::CreateEventSource($aEventSource, "Application")
Out-String -InputObject "Created EventSource: $aEventSource"
}
else {
Out-String -InputObject "$aEventSource already exists."
}
}
CheckCreateEventSource("Microsoft.Dynamics.GP.eConnect")
CheckCreateEventSource("Microsoft.Dynamics.GP.eConnect12")
CheckCreateEventSource("Microsoft.Dynamics.GP.eConnect14")
CheckCreateEventSource("Microsoft.Dynamics.GP.eConnect16")
Write-Host -NoNewLine "Press any key to continue..."
$null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")