I have a problem while trying to deploy a ssis package from a job. I have created the ssidb folder of the package, and I have not problems to execute it successfully. But when I use a job, by choosing the package from the ssisdb folder, I always get the same error message:
Failed to acquire connection "database". Connection may not be
configured correctly or you may not have the right permissions on this
connection.
The ProtectionLevel of the project and the package is "DontSaveSensitive", but apart of this I do not know what else can I do.
I would appreciate any advice you could give me.
Using SQL Server 2014.
Regards.
It sound's like you have almost worked this out yourself :-) The connection string will most likely not be valid because, when you deployed the package, the password would not have been carried across.
Easiest option if running via SSDB:
On the deployed server right click on the package.
Click configure
Amend your connection manager accordingly.
Easiest option if running via SQL Agent Job:
Right click job and select properties
Click Steps
Edit your step.
Click on configuration tab.
click on connection managers tab.
Amend accordingly.
There are, of course, other ways - have a look up Environments.
FWIW We store all our packages with sensitive data secured by a password.
Related
Here is the short version of the problem: I have a discrete DTSX file that works fine on our Production server, but doesn't on our new Dev server.
Symptom: When run from a SQL-Server job, the job starts and nothing at all happens, and it never finishes... it just hangs, using very little system resources.
Some info: For Prod, the packages were developed on SQL-Server 2012 and run on an NT 2008 server. The new Dev server is also SQL-Server 2012, but runs on an NT 2012 server (in case that matters). I have duplicated the folder/file structure exactly, including drive name. The package uses an external dtsConfig file, but as I said - the folder/file structure is identical.
The SSIS service, SQL-Server Agent, and my remote login are all the same, and is a member of the server Administrator group on the Dev box. If I copy the command line text from the SQL job and run it in a CMD window using dtexec.exe, the package executes correctly. The job owner is my login, and the "run as" is the SQL-Agent, which - as I mentioned - is the same login. Since everything in the package uses integrated security, everything should be running using the same login whether on the command line or via the SQL-Agent, which should eliminate any user permission/credentials issues.
I tried adding SSIS logging to the package, logging everything I could. When I run the package from the command line, I get a ton of messages in the log. When I run the package via the SQL job, there are no messages at all in the log - nothing.
Whatever is going on, it's not getting far enough into the SSIS package to generate a single log entry. It's just stopping but not exiting or throwing an error. FWIW - I have the same problem with every other package I've tried.
Any ideas are appreciated...
I found the cause of the problem. The MS-SQL Server service was using a different login than the SSIS server service and the NT Agent service (it was using a local service account).
Once I changed the MS-SQL Server login to match the others (and restarted the service), the job ran correctly.
I am using Package Deployment Model for one of my project in SSIS.
When I am importing the package on SSISDB under Integration Service Catalogs.
It imports successfully.
Then, I want to create a Job under SQL Job Agents to Run this Package periodically. But there I am not getting any Connection managers which I have used in my package.
My SSIS package has 2 connections :
Connection to the Sharepoint Site (Which is the source of the data)
Connection to the SQL Server ( Which is the destination of the data)
If I am not getting the connection manager while creating the job, then How can I change the connection Servers from local to Production ones from here?
Am I missing something on configuration part to include Connection Managers in the Deployment Package?
Please help here.
Thank you,
Mittal.
In SSMS open the Integration Services Catalogs -> SSISDB -> CatalogName -> Projects, then right click on the project OR Find the package in the SSIS Catalog and right click on it, then select the Configure... entry in the popup menu.
You can select the package in the Scope dropdown list, then you can find the connections under the Connection Managers tab.
Also please read this thread: How to configure SSIS 2012 project to run under different environment configurations?
I have the following problem. I have a SSIS Package that works fine when I execute it from visual studio, but when I execute it through the SQL Server Agent it gives me this error (I have it in spanish so I'll translate it and it might be a bit different from the normal message):
"Can't find connection "{(the id of one of my database connections)}". The Connections collection returns this error when it can't find the specific connection element.".
The SQLSERVERAGENT user has privilegies in the project's folder.
When planning the execution, I used the package file as a origin, if that has something to do.
I ran out of ideas and don't know what to do. Any help would be greatly appreciated.
Thanks in advance,
Khor
I finally made it work.
The problem was that the user who created the packages had permissions on the server I was accessing with the ODBC to but the SQLSERVERAGENT user didn't.
I changed the user in the SQL Server Agent service from SQLSERVERAGENT to the user who created the packages to make sure that this was the problem and it worked fine, so the solution is either leave the service with this user or give permission on the other server to the SQLSERVERAGENT user.
I'm having a rather frustrating issue with using an SSIS Flat File source. I am developing an SSIS package on my local machine via VS 2008 and I'm using a flat file source that is stored locally. However, I need to deploy this package to a remote server that hosts our SQLServer and then run it as a scheduled job from that host. However, when I deploy the package, it obviously can't read the flat file source from my machine and fails the job. I have tried putting the file directly on the remote host in the exact same file location (ie. C:\Source.txt) but to no avail. Any ideas on how I can get my deployed SSIS package to read a flat file source?
Hopefully I'm just missing something extremely simple and will ultimately have a "DUH" moment, but if anyone can help I will greatly appreciate it.
If the account under which the SSIS package (for instance the SQL Server Agent service account) is running doesn't have rights to open the file, you will also have problems. So not only does the file need to be on a path that is valid relative to the server running the package, it must also have rights.
Nice answer by Cade.
Remember that you create a SQL Server Job, by default it runs under the credentials of the Service Account assigned to the SQL Server Agent.
If some steps on a Job need some permissions not owned by the Service account you can define a SQL Server Agent Proxy.
That way you can keep the principle of least privileges.
More info on how to create a Proxy here.
I have an SSIS package that queries a view for some records then sends off an email using Database mail. I want to deploy the package to the SQL Server that these views exist in and then schedule us using SQL Server Agent but i've run into a number of issues.
The main problem is that within the job there is a connection manager that has stored credentials for a SQL Server account that has access to the views and email profile. I've set the package to EncryptSensitiveWithPassword instead of User Key but i can't seem to find any way to actually pass that password the the SQL Server Agent when the job is run. So when it executes it fails since it can't connect.
A bunch of websites say to use the config file, but when I go that route it breaks the job entirely complaining that the OLEDB connection can't be established. In that scenario I can't even run the job on my machine locally.
A few other sites recommended copying the package to the local ssis package store on the machine, but I only have access to the machine through SQL Server Tools, I can't remote in or install anything on the file system so I have to install through the manifest file using the SSIS deployment process.
I've read something about storing settings in another DB table, but that again presents issues with permissions on the server.
Finally I tried passing /password or /decrypt in the job scheduler, but when i click ok it scheduler removes that parameter.
This is an internal server and security isnt really a big concern, Any idea how i can pass the decryption password in plaintext or just tell SSIS to not bother securing sensitive data?
The trick is:
When saving the package in SQL Server Business Intelligence Studio, ensure the Package Properties > ProtectionLevel is set to EncryptSensitiveWithUserKey.
When you import the SSIS package into the SQL Server (from SQL Mgmt Studio > object explorer > [server] Integration Services > Stored Packages > MSDB > right-click > Import Package > set Package location to File System, Select the file in Package path, and select the option "Rely on server storage and roles for access control". I would guess when importing the .dtsx file you have to be logged in as the same user that saved the .dtsx file.
This means that the password is saved with the package and therefore can be used when anyone executes the package. If it's something you don't want anyone to execute you then lock down security appropriately.
Alternatively you could change the Connection so it uses Integrated Security (windows authentication instead of a sql login) and change the Job so it executes the package as a user that has access to the database & view that's queried by the package. This is the preferred option from the view that you don't need passwords anywhere and instead manage it via user identity and permissions.
It sounds like when you're using the config file that you're not setting up the config file correctly.
What is the exact error that you're receiving when running it locally? I can try to recreate the issue.
do you have the package set up in bids to store the passwords, and then save the package to ssis and tell it to encrypt the passwords? if you're not saving them locally, it could be that you've lost your passwords and then pushed the package without them.