I have a Client, running on Server A, which executes a SSIS package which is located on Server B. This SSIS package process a SSAS Tabular Cube which is located on Server C.
The connection from A to B works fine. However, the connection from B to C fails with the error "A connection cannot be made. Ensure that the server is running". The Connection from B to C is via Windows Authentication, the Servver is running and permissions are fine.
When I execute the deployed SSIS package directly on Server B then it works.
When I execute the deployed SSIS package over SSMS on Server A then doesn't work.
The user is the same on every server on which the services are running.
It was a "double hop kerberos" issue. I solved it by creating a SQl Server Agent Job which executes the SSIS Package. The client then starts the Agent Job.
Thanks #billinkc for the comment.
Related
TLDR; I am attempting to connect to a host and hitting "To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher". Does SSIS need to be installed on all Hosts for my package to succeed? Secondary question: If so, why would a manual execution from my dev machine work while the deployed/dtexec versions fail?
Apologies if this is a basic question (I am still steeping myself in all things SSIS and trying to learn as quickly as possible). Thanks in advance for any assistance you can provide!
I have a package that runs fine on my development machine (via Visual Studio). However, when I deploy the package out I encounter errors when attempting to connect to a MySQL database on a secondary host machine on the network. Taking a step back, I decided to attempt a manual execution via DTEXEC on my dev machine to attempt troubleshooting...
When executing this package through DTEXEC however, I encounter an error stating:
"To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher"
Looking at the log, it looks like the package is able to connect to Host 1 successfully and do some data manipulation (one of the 3 hosts; I know Host 1 and Host 3 have SSIS installed). However, when it attempts connection to Host 2, it fails with the aforementioned error. For the longest time, I thought this was due to the MySQL database I am trying to connect to (using .net Provider\MySQL Data Provider) but given the error above, it is possibly pointing to something else...
After doing a bit of searching I have located the following articles which may be related:
https://dba.stackexchange.com/questions/49786/error-to-run-a-ssis-package-outside-of-sql-server-data-tools-you-must-install
Getting error running SSIS package on non-SSIS Server
I know SSIS isn't installed on Host 2. The package is being executed from Host 1 and this host does have SQL Server and SSIS installed. Host 3 additionally has SQL Server and SSIS installed and I am able to successfully operate/connect on this host as well. The only host presenting a problem is Host 2 which does not have SQL Server nor SSIS installed.
Do all hosts have to have SSIS installed for connections to be made? Additionally, if SSIS does need to installed on Host 2, why would my dev machine succeed while the dtexec/deployed versions fail?
Again, thank you for any assistance you can provide!
The answer to your first question is "Yes", and that fact is the answer to your secondary question.
In short, SSIS packages are NOT self-contained executable files. They are more like .ini files that the SSIS Service reads, interprets, and executes. If the SSIS Service is not running on a host computer, then that computer cannot do anything with an SSIS package (the .dtsx file).
Your dev machine succeeds because it has Visual Studio, or BIDS, which is a developer's version of the SSIS Service engine.
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 developed an SSIS package on my database server (ServerDB) to execute SSRS reports on another server (ServerRPT).
When I run the SSIS package using MS VS 2008 on ServerDB, the reports can be generated.
Then, I try to schedule the package on my database using SQL Server Agent, the package failed to produce the reports. File name has been created on the server but zero file size. So, the package execution is fine and problem potentially lies on the Reporting Server access.
Reporting Server (ServerRpt) has a Windows Service Account.
Database Server (ServerDB) jobs executed using SQL Server Agent Account.
Is there anything I miss out or accounts that need to be created ?
Suspect it could be permission issue on ServerRpt.
Hope you can shed some lights.
Thanks ....
I have a question regarding to SSIS. I designed a package and it worked fine when I executed in my local machine. I used to extract the data from Teradata and load into SQL SERVER 2008. Everything was fine but I'm looking for how to execute the package without my local machine. I mean how to configure and set up the odbc in the SSIS server machine, not my local machine.
Thank you,
Paul
You'll need to make sure you've installed SQL Server Integration Services on the box; then there's a number of ways to go about running it. From there, I prefer to connect to Integration Services from the Object Explorer in SSMS and import packages, using the "SQL Server" as the Package Location. Once the Integration Services on the box has an entry for the package, you'll be able to run it with the agent by specifying a step type of "SQL Server Integration Services Package." I don't think you will need to set up the ODBC on the server itself if you have it configured correctly in your package, but if you do that should be no different than the way you have it set up on your own box.
I've kept my ssis package in my local application folder and through vb.net m able to execute that as package.execute(), But when i publish the same code in my server, its showing some eror,
so is that we need to install sql server in the applicaiton server also ?
My server does'nt have sql server installed....
or any prerequisite do we need to install on my server machine to make this work....
You will need to install sql server integration services on that server