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.
Related
I install SQL Server Connector for Power Query for SQL server 2017. Create SSDT SSIS package with power query connector. It works perfect in SSDT! But when I deploy project to SSIS catalog, I get an error:
Credentials are required to connect web source.
Package:Error: The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread's user context, which may be the case when the thread is impersonating.
Moreover, when I import this package from SSIS catalog to new project, power query connection manager go away from project with error:
The connection "{EFC6889A-D312-4A9E-B251-877C7A67B8DF}" is not found.
This error is thrown by Connections collection when the specific connection element is not found.
Solved!!! In SSDT I used my own login. But in SSIS catalog used SSIS proxy account that don't have access to web.
After granting access to web to SSIS proxy account it works!
If you met same error just try to run SSDT under proxy account and check web access in data source manager :)
I am trying to execute an SSIS package using a Credential and Proxy - it works fine with a user with a SysAdmin role and we want to avoid using SysAdmin.
I have followed all the steps to create a Credential and Proxy and set up the permissions for the user in msdb and SSISDb tables and in the Security -> logins
I have followed the steps in the below links as a guide:-
Run an SSIS Package Under a Different Account
Running a SSIS Package from SQL Server Agent Using a Proxy Account
SQL Server Agent - Running SSIS Package with Proxy
Proxy -> properties -> Principals
When I run the job I get the below error - looks like a permission issue
Unable to start execution of step 1 (Reason: Could not get proxy data for proxy_id = 198_. The step failed.
What am I missing?
As you mentioned in the comments, you are using an SQL Server login as a proxy account. While in the Microsoft documentation they mentioned that:
SQL Server Agent proxies use credentials to store information about Windows user accounts. The user-specified in the credential must have "Access this computer from the network" permission (SeNetworkLogonRight) on the computer on which SQL Server is running.
I suggest following one of the following articles to set up an SQL Server agent proxy:
Create a SQL Server Agent Proxy
Setting Up Your SQL Server Agent Correctly
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 created a SSIS package that watches for files being created on another server using a WMI Event Watcher Task. This package works fine when I run it in VS. It works fine when I manually Execute it from the Integration Services Catalog. When I try to run it as a scheduled SQL Agent Job I get
Error: Watching for the Wql query caused the following system exception: "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))". Check the query for errors or WMI connection for access rights/permissions.
My question is why does this not run as a SQL Agent Job when I can run it successfully several different ways? Based on the error code seems to be a COM/DCOM security issue.
So far I have:
Tried many web sites most are more or less like this
https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-troubleshooting?redirectedfrom=MSDN I have followed all the instructions on these websites with no change.
Gone back and gave even more permissions then specified by the website to the COM Limits and DCOM Config of the Windows Management and Instrumentation.
Have restarted the WMI service on the other server several times after each change.
Tried SA and myself as owner of the Job.
Tried my usual SQL Agent Proxy account and the default Server Agent Service Account (which is a Managed Service Account) as the Run As for the package.
Tried running as a 32 and 64 bit runtimes.
Have made the SQL Agent Proxy account and Server Agent Service Account Admins on the other server.
Tried hard coding my user name and password into the Connection Manager and used Windows Authentication.
* New tests *
Tested the SQL Agent Job using the File System as the package source instead of the SSIS Catalog, still failed with same error.
Tested running package using the Execute Package Utility and it worked!
The AgentSqlServer user does not have rights to launch WMI Querys on server, You should create a proxy account and join it à to the step on the SQL Job.
I am trying to schedule a SSIS2014 package via SQL Server Agent job. Both SSIS and SSMS are running on my local machine in the same domain. I am running SSMS with the same user Domain\Admin which is the creator of the SSIS package. SSMS 32-Bit and SSIS 32-Bit are running on Windows 7 64-Bit machine. I can run the package within SSIS without problems.
Using Microsofts KB article http://support.microsoft.com/kb/918760 and tutorial video http://technet.microsoft.com/en-us/library/dd440760%28v=sql.100%29.aspx I tried a couple of methods (proxy, configuration file, EncryptSensitiveWithPassword) but none of them worked for me.
When I use a proxy account to run the job step, the following message occurs:
Unable to start execution of step 1 (reason: Error authenticating proxy
`Domain\Admin`, system error: Logon failure: unknown user name or bad password.).
The step failed.
The proxy account uses the credentials identity Domain\Admin. Since the password fields for credential properties in SSMS cannot be left blank, I typed any password although my corresponding windows account has no password. So as mentioned above it's the same user account that created the SSIS package since Domain\Admin is stated in the CreatorName property of the SSIS package.
With this proxy, I tried to run SSIS jobs using the package ProtectionLevel's EncryptSensitiveWithUserKey and EncryptSensitiveWithPassword. Running the package manually within SSDT without problems, but from SSMS agent job the same error message appears. I tried the package sources "File System" and, after importing the package to MSDB, "SQL Server" and "SSIS Package Store". But exactly the same error message appears with each method.
Task manager shows that SSMS is running in administrator mode. Using Windows Component Services I added DCOM permissions for Domain\Admin to start and activate "Microsoft SQL Server Integration Services 12.0" from local. But the same error message appears. So in my opinion it's a problem with SSMS user account permissions (???) but unfortunately I don't know what exactly to do here. I tried the following:
In the system database MSDB (full path: Databases / System Databases / MSDB / Security / Logins) I assigned all available role memberships (Including db_ssisoperator, db_ssisltduser, db_ssisadmin) to Domain\Admin.
In server security (full path: Security / Logins) I assigned all available server roles. In the tab User Mapping, I assigned the MSDB database.
Still the same error message appears when I try to run the job. Does anybody have some ideas what I can try?