I am troubleshooting an SSIS package, permission issues around external files.
It only fails when running via the SQLAgent obviously using the SQL Agent unattended account.
This is fixed now however in order to test I needed to create a SQLAgent job and then a step within that job to test.
Obviously when a package is run locally via Visual studio it uses your own credentials. When you log into SSIS server via Management studio and use the Execute package utility does this use your own credentials or the SQL Agent credentials?
Is there any quick way of executing a package with the Agent without going through the fuss of creating an Agent job?
Related
I have a OLEDB task that connects to ms-access database on local file system and dumps data into sql database.
Access db connection string is: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
The SSIS package runs OK in visual studio. Access 2016 32-bit runtime is installed on this computer.
After deployment to SSIS catalog, right click and execute works OK. Access 2016 64-bit runtime is installed on this computer.
When this package is scheduled to run via SQL Agent job, using proxy/credential [domain user - example: domainname\user1] (having read permission on the access db file), then the job fails. The SSIS execution report shows error as: Unexpected Termination. There is no further information.
Suppose if I add the proxy credential (domainname\user1) to the local administrators group (in computer management) then the SQL Job runs OK. What could be the solution to this so I can give only the minimum required permissions?
The error is very difficult to debug as it doesn't occur when running via visual studio. Even when deployed to the SQL server and run from the SSIS catalog, the execution works OK. The error occurs only when the package is run via SQL server agent job (via credential/proxy) - the SSIS execution report doesn't show any helpful messages; and surprisingly the error gets resolved when the credential is added as local administrator on the computer - which is a bad practice.
The solution is analyse what kind of ms access file you are using and appropriately use the correct access runtime version (2013 vs 2016) and the correct provider value in the connection string.
Access runtime:
In my case, I uninstalled Access 2016 64-bit runtime and installed Access 2013 64-bit runtime.
Provider version:
I changed the provider version from 16.0 to 15.0, as shown below-
Before: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
After: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.15.0;
Note:
There is no need to add the user to the local administrator group.
There is no need to login to the computer using that account.
Only read permission (under windows folder security) is sufficient assuming the SSIS packge will only read the ms access database.
It's hard to debug this only with the information provided, but in general:
The user running the job requires at least write and delete access on the underlying folder in which the Access database resides. This is required to generate a lockfile for the database.
If this is undesirable because the job may be modified by a malicious user, I've seen deployments where a copy is made in a temporary folder with write access and a size quota, and that temporary folder is removed as soon as the job finishes, regardless of if the job succeeded.
As per the Microsoft documentation on DTEXEC for executing SSIS packages:
When you use the version of the dtexec utility that comes with SQL
Server 2012 Integration Services (SSIS) to run a SQL Server 2005
Integration Services (SSIS) or a SQL Server 2008 Integration Services
(SSIS) package, Integration Services temporarily upgrades the package
to SQL Server 2012 Integration Services (SSIS).
Is there a feature to disable this aspect of DTEXEC utility when running SSIS packages?
My reason for this question is that I have a script task to rename some files in an SSIS package. This works just fine on my local machine and a coworkers local machine, but after deploying this SSIS package to our windows 2012 server with SQL Server 2012 installed I get an error message. I'm really confused, because I wrote this package in SQL Server 2012 Data Tools so this task shouldn't need to be upgraded/migrated at all, which is what the error is complaining about...
Warning: 2016-04-06 11:29:58.14
Code: 0x00000000
Source: DataMergeScriptTask
Description: Found SQL Server Integration Services 2012 Script Task "my_Script_task" that requires migration!
End Warning
Error: 2016-04-06 11:30:03.02
Code: 0x00000001
Source: DataMergeScriptTask
Description: Exception has been thrown by the target of an invocation.
End Error
Unfortunately we haven't found a solution for the Script Task not converting into 2012, as these packages are all written in Data Tools 2012 and opening/resaving the task doesn't seem to actually upgrade the script task in a way that solves it on the server.
My solution has been to take the C# script and turn it into a standalone .exe which has some command line arguments to pass our different parameters with defaults in place to match our current environment. Then I set this up to be executed by a Batch script called by a windows task scheduler job.
I'm hoping to find a real fix for this so that script tasks in larger packages will still be peachy, but that may take more time or a reinstall of data tools... Having multiple versions of SQL Server data tools/BIDS on my workstation could be a cause of this grief. More testing to come!
Just update the TargetServerVersion in your package to match the server version that you plan to deploy to.
Make sure you have a copy of your project in case it doesn't go smoothly. Then right click on the project name, choose properties, then drill into Configuration Properties -> General and update the TargetServerVersion.
Then rebuild and deploy. When the project builds, it should now be in the format that your server expects so it won't try to rebuild the script code on the server where references might not be the same.
I have installed SSIS for VS2012 (SQL Server 2012) and I am able to create basic packages that run, however I am unable to get any of the logging to work. I have configured logging for text files and for the SQL Provider however, neither will log the execution of the package which is just a few SQL statements. I have configured all of the events to log in the details and in the advanced selections. The exec SQL tasks are in a Data Flow container, which I have also enabled logging.
When I look for the table msdb.dbo.sysssislog it is there but it is empty. If I configure the file writer, it will not create a file, which I specified to be in \windows\temp to avoid any permission problems.
If you deploy your packages to SSIS Catalog, you can have access to a better logging system that is offered by SSIS2012. You can Right-Click on your project under Integration Services Catalog and Report All Executions. This is highly recommended and makes your DBA's life much easier. you can learn more about how to set this up here.
I have some task which I want to schedule and I did not work with SSIS before. I have created SSIS package using the Execute T-SQL Statement Task. It has run my procedures from DB.
But I need to run this procedures weekly using SSIS package. Is it possible and how can it be implemented?
Once this is implemented, I will send this SSIS package to the guys who are working with SQL server.
One possible option would be to use an SQL Server Agent job to run the SSIS packages.
Have a look at the following link. It explains how to create an SQL job that can execute an SSIS package on a scheduled basis. You can create a Credential and Proxy if you need to access any external resources outside of the database. If your package accesses only a database, you can possibly skip the steps that create Credential and Proxy Account.
The scheduling part is not explained in the below link but I think it should be easy enough to figure out on the SQL Server Agent Job creation dialog.
How do I create a step in my SQL Server Agent Job which will run my SSIS package?
Hope that gives you an idea.
SSIS package execution scheduling is done on the SSIS server, when the package is imported (or, on the machine you wrote the SSIS package on, if it's the Production machine - it isn't, right?)
The SSIS GUI (BIDS) offers a range of scheduling options.
How do I schedule SSIS to automatically execute a package from a file at a given time every day?
You have a few options, but I'll give you something that will allow you to get up and running quickly...
Open SQL Server Management Studio and connect to the Database Engine of the SQL Server that will run the job. This SQL Server should have SQL Server Agent installed and running.
Expand SQL Server Agent, expand Jobs.
Right-click, select New Job.
When you create your package step, for Type choose SQL Server Integration Services Package. For the Package source, choose File system. Then for the Package you can use the browse button (...) to browse for the DTSX file on the file system.
Go to Schedules and create job schedules as you normally would for any other SQL Server Agent job. In your case, set the Frequency to Daily, and set the value of Occurs once at to whatever time the job should run.
A couple of things to keep in mind...
Make sure that the SQL Server Agent service account (this is the default, you can choose an alternative security context if needed) has the permission to access the dtsx package on the filesystem.
This will only work if the server on which you're scheduling the job is also the Integration Services server. There are plenty of ways to handle remote package execution if you require it.
For additional information, please see https://msdn.microsoft.com/en-us/library/ms191439%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396
I prefer the above anwser but it is also possible with the windows Task Scheduler and start your ssis package with dtexec. (Only possible on the SSIS server) Check also execution with dtexec
First choice - if possible is to to schedule the package:
1) using the SQL Server Agent for the standard jobs
2) non-standard windows task scheduling, depends on what the package is doing
3) dtexec can play nicely but it depends on what ssis tasks the package runs
4) the more the ssis package does, the more it may require of the dtexec config
and set up to play nicely with the windows scheduler