I have a basic SSIS package that pulls data from a Redshift database ODBC DSN connection and puts it in a SQL Server database using an OLEDB connection. When I test the connections in Visual Studio everything is successful. When I run the package in Visiual Studio and the SSIS instance from SQL Server, they both are successful. However, when I try to run it from a SQL Sever agent job it fails with the AcquireConnection method failed error.
The VS solution/project is targeted to SQL Server 2014 same as the server.
The VS solution/project 64bitRunTime property is set to false so it will run as 32bit.
The configuration for the job step in SQL Agent is also set to 32bit.
Both the job owner and the step's login to the package are set to "sa" (just to test).
Still not working. Any ideas?
The difference between cases is the user credentials. When you run the package - it runs under your credentials, when SQL Server Agent runs it - it (by default) runs under service account.
Ways to test and fix:
Create a SQL Credential, SSIS execution proxy and configure Job step to use it in run as dropdown.
For testing - create a credential mapped to your account.
Change account under which SQL Agent starts or add privileges to the service account.
I opt for the first method, since it is more granular and affects only your job.
Related
I have created a SIS Log Provider to write a log entry from a Script Task in a SSIS package. The connection is working a long as I use Windows Authentication, but if I switch to SQL Server Authentication and provide a username and a password no log entry is written. I use the same connection in the package to execute a SQL Task to read from the SSIS Log with no problem. The SQL Server User has read and write access to the SSIS Log.
I have to use SQL Server Authentication because the Windows User Running the SSIS Job and the package doesn't have access to SSIS Log and this could not be changed.
I'm using VS SSDT 2017 and deploy the package to SQL Server 2016.
I tried to store the username and password in the package and to provide the connectionstring and password via package parameters and environment.
No effect as soon as I switch from Windows Authentication to SQL Server Authentication.
Dts.Log(logMessage, 0, emptyBytes);
The above code should write an entry in the SSIS Log, but works only for Windows Authentication.
Edit:
The SSIS Log Provider Type is SSIS log provider for SQL Server.
The connection manager type is OLEDB, the provider type is Native OLE DB/SQL Server Native Client 11.0.
The connection is parameterized for the connection string and the password.
I have an issue with an SSL ODBC connection from SSIS Package, while the package is executed by SQL Agent.
I am using a technical user (ActiveDirectory account) used to execute (run as) a step in a SQL Agent job that calls the package.
The user has a proxy credential and all required privileges on SQL server to execute the job and all dependent resources from SQL server, as while the DSN, used by SSIS ODBC connection is configured without SSL it works as flawless.
When the "Connect using SSL" property is set, I am getting a generic error message:
:Error: Failed to acquire connection "". Connection may not be configured correctly or you may not have the right permissions on this connection.
I have noticed, by accident while debugging, that if I have any application running or a session established for the technical user to the server, the load with SSL configuration ends successfully. When the session is terminated/closed the error comes back.
Please advise, what has to be reconfigured to make it work with SSL!
Environment:
SQL Server 2016 (v: 13.0.4001.0)
SQL Agent runs as: NT Service\SQLSERVERAGENT
SAP Hana is a target DB
SQL Server runs on Windows Server 2016
My SSIS package consists of an Execute Process Task which executes some compiled python code which downloads files from a Web API.
The code works.
The package executes succesfully from Visual Studio.
Once deployed to my localhost sql server 2012 instance SSISDB, I can right click execute it and it works fine.
However, as soon as I try to invoke the package from a SQL Server Agent job, it fails with. I do not understand this but I suspect this is because I don't understand what's happening with the SSL handshake. Does SQL Server Agent reference it's own store? If so, does this mean that my store is inactivated (do I need to enable SSL for my sql server agent?) or missing a certificate?
It feels like I have tried every possible workaround - I have ensured that my sql server agent is owned by my credential, rather than a generic credential - I've even created a proxy and explicitly instructed the sql server agent job step to run under that proxy but I guess this isn't the issue. The issue is the SSL certification step.
How can I fix this?
We currently have a SQL Server 2012 job that fails to execute because of an account lock out. The message found within the Event Viewer is the following:
SQL Error: The referenced account is currently locked out and may not be logged on to.
The SQL Agent runs a local account and have verified it is not currently locked out within System Admin on the server. Have also verified that account is not locked out on the SQL Server box. The SQL Server job runs a SSIS package. If I run the SSIS package by itself the job will execute just fine. It is when it is executed via the job that it fails.
Has anyone else had a mysterious account locking problem with a SQL Server Job?
Follow below steps:
Right click sql agent job name -> view history -> check error. It gives exact details of what has gone wrong.
SSIS Jobs via SQL Agent needs proxy account, which contains credentials of SQL Server login. Hence Security -> Credentials and update the username and password.
Once done, make sure it is reflected in Proxy (SQL Server Agent -> Proxies -> SSIS Package Execution.
Make sure the referenced account is added under Security -> Login
I created a SSIS package in Visual Studio 2010 (BIDS). It's using an OLE DB Source and an OLE DB Destination. Both the source and destination use Windows authentication (a domain user) to connect and both are local to the Package.
In VS the connection is successful and I'm able to execute the package.
Now, I'm trying to schedule it in SSMS using SQL Server Agent.
I first connected to SSIS in SSMS and imported the package from my file system into MSDB. Then, I created a new job with one step to execute the SSIS package. I see my package level connections, so everything appears ok. I also used Windows Authentication for this step as well
However when I try to run the I got login errors.
First, it said the login 'Domain\InstanceName$' failed.
So I switched the windows authentication in the step within the job to sql server authentication. Now I get another error (it's slightly different) stating the login 'Domain\UserName' failed.
How do I get this to work as a schedule?
The answer was creating a SSIS proxy and then running the job under that proxy account instead of the SQL Server Agent account.
First need to create a credential tied to a Windows domain account. Then create a proxy and tie that proxy to the credential. Last, apply that proxy to job instead of using the SQL Server Agent account.