Issue with SQL connection with groundplex running as service

[johnbilay]

Dear community and expert

We have the following scenario:
Snaplogic connects to a Store procedure provided by MSQL. The authentication method used by the MSQL server is “Windows authentication”. We have a groundplex running at a Windows based VMware close to the Database.
In the account used to connect to the store procedure we are therefore using the setting “IntegratedSecurity” set to true. This works perfectly fine when the groundplex was manually started using the jcc.bat start command.

When we start the groundplex as a service using the command : jcc.bat intall_service; then the account to connect to the database does not run anymore. It fails with the error below:

SQL Server - SP_o2c_creditmgmntparent[2940ff56-c8cd-45ea-a447-18bae4652be7 – 3ea9df9e-cd6d-4804-9354-5cc0d95230db]
com.snaplogic.snap.api.SnapDataException: Failed to retrieve a database connection.
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user ‘xxxxxx$’. ClientConnectionId:8cd46738-696f-4279-b460-7e3b40ebed41
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:258)

I understand the reason. This is because when starting the groundplex as a service, it runs under a local user (on the Windows VMware) but not as a windows users – which is required for calling the store procedure (Since the authentication in MSQL is set to Windows…. ). Actually, we will need to run snaplogic as a service using a windows user that is authorized to connect to the MS SQL. But when I try to change the credentials of the user running the groundplex as below, the groundplex does not start. It stops immediately. Any suggestions of what to look?

Kr
J

[del]

@johnbilay, try adding your service account user to the VM local machine Administrators group, to see if that helps. We’ve been running JCC as a Windows service for 5+ years, and never had trouble running as an AD user, but that user has always been in the local machine Administrators group from the beginning.

As a side note: it’s extremely rare, but occasionally, we have had to reinstall the service for no apparent reason. You always have to reset the login user when you do this.

Aside from those thoughts, the most common issue we’ve had with the service not starting is that Java did an auto update and changed the Java path. So, I installed Java in at a non-standard path, turned off auto-updates in the Java console, and added the Java path to the jcc.bat file.

set JAVA_HOME="d:\opt\java"

I hope one of the ideas helps…