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.
Related
We converted our 2012 SSIS package to 2016 SSIS (TargetServerVersion = SQL Server 2016).
One of the database the SSIS package reads from is a SQL Server 2012 database.
Either connecting using Native OLE DB\SQL Server Native Client 11.0 or connecting using OLE DB provider for SQL Server give the same error.
Data Source=my2012SQLDBServer;Initial Catalog=my2012SQLDB;Provider=SQLNCLI11.1;Integrated Security=SSPI;Auto Translate=False;
Data Source=my2012SQLDBServer;Initial Catalog=my2012SQLDB;Provider=SQLOLEDB.1;Integrated Security=SSPI;Application Name=myApplicationName-{....}my2012SQLDBServer.my2012SQLDB;Auto Translate=False;
When running the SSIS package from SSMS (SSMS is run using a user that has a dbOwner permission to the 2012 database, ie myDomain\myUser) , I am getting the error in the step reading a table from the 2012 database
Execute SQL Task: Error: Failed to acquire connection "my2012SQLDBServer.my2012SQLDB".
Connection may not be configured correctly or you may not have the right permissions on this connection.
DTS_E_OLEDBERROR. An OLE DB error has occurred. Error Code:0x80040E4D. An OLE DB record is available. Source: "Microsoft SQL Server Native Client 11.0" HResult:0x80040E4D
Description: "Login failed for user "NT AUTHORITY\ANONYMOUS LOGON".
On Visual Studio (run using myDomain\myUser), I am able to succesfully run the SSIS package.
myDomain\myUser also has an ssis_admin, ssis_logreader, db_owner, app_dbowner role in the SSISDB database.
How can I fix this error ?
Thank you.
It is typical error for double-hop problem.
Simplest solution is to login using remote desktop to SSIS server and then run it using SSMS there.
Other option is to define SQL Agent job on the SSIS server and then run the package using this job.
Ultimate solution will be to configure Kerberos and allow double-hop connections on the SSIS box.
You can check following post how to configure Kerberos:
SSIS job fails when run remotely thru ssms, but runs fine on SQL Server
solution for me was like just changing windows authentication in the destination settings to SQL server authentication with apropriate
Account that have rights to reach the server, i dont understand how it works but it does.
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.
I have an SSIS package with a Connection Manager that is connecting to a SQL Server database using SQL credentials, i.e., not Windows Authentication. Save my password is checked. It's been deployed to a SQL Server as a job and is running fine. Now, we have a 3rd party vendor who is trying to interface with our SQL jobs. When we open the configuration window in SSMS's SSIS Catalog and go to this connection manager, the password is empty. Our vendor needs to grab the password. Does anyone know why it's empty, or alternatively, where our vendor can get the password from?
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.
I'm new to ETL so I have developed a simple ETL package, and now I'm going to deploy it to a remote server.
I connect to server using SQL Server authentication, so I go to solution explorer and open deployment wizard, in there in destination tab entered my server ip and then it shows me a error message saying
Login failed for user 'MYDOMAIN\MYUSERNAME'. (.Net SqlClient Data Provider)
As I said earlier I want to use SQL Server authentication to connect to my server, where can I change this settings in SSIS ?
Take a look at the link below. I think it should solve your problem.
On the Specify Target SQL Server page, specify the instance of SQL Server to install the packages to and select an authentication mode. If you select SQL Server Authentication, you must provide a user name and a password.
https://technet.microsoft.com/en-us/library/ms141693(v=sql.110).aspx