I am working on my first SSIS package that connects to a SQL server. While I am developing it, I am connecting using Windows authentication which works fine since my Windows user name was added to the security of the database I am working on. Now, my IT department created a service account to deploy the package with. My question is, how can I change the user name/password of the connection before I deploy it? Is there a configuration file that the connection can read from? How can this be handled?
You actually have two security contexts here to be concerned with. The first is the account required to deploy the package or project you've created. The second is the account required to be able to execute the package you've created.
End-to-end Windows Authentication (deployment, execution and data sources)
The deployment account would need to have correct permissions to the server or filesystem on which it will reside. The execution account may be configured with a very different set of permissions, primarily related to the permissions required to execute whatever tasks you've built into the package.
In order to deploy the package under a different user that your own, it may be as simple as opening an application (like Command Prompt, Windows Explorer or SSIS Deployment Utility) as that user account and moving the package to the correct location. This can be handled on your workstation or the server.
For the execution account, you have options depending on how you're going to operationalize the execution of the package. Here's a few scenarios:
If you will have the package be executed by the SQL Server Agent and the account you need to execute the package with is the SQL Server Agent service account, you only need to create the job to run the package. Unless otherwise programmed, packages called from a SQL Agent job will run as the SQL Agent account
If you will have the package be executed through a SQL Server Agent job and the account you need to use for executing the package is NOT the SQL Agent service account, you can create an SSIS Proxy Account and specify that in the SSIS Package execution job step. After creating the credential inside SQL Server, it is as simple as changing a dropdown.
If you will be using command line execution from a SQL Agent job, the above two scenarios are still applicable.
If you will be using another mechanism (like Windows Scheduler or another Enterprise Scheduling tool) that uses a command line execution-like method, you should still be able to have that process "run as" the execution account.
Windows Authentication for deployment and execution only (SQL authentication for data)
The above details still apply for executing SSIS packages via jobs and/or command line, but you will need to pass the username and password to the connection manager at the time the package runs. You have several options to do this and should follow any established patterns or standard your organization has in place. SSIS has long supported using an XML-based .dtsConfig file which can be read into the package at run-time. There is a GUI within SSDT/BIDS that will lead you through the process of creating the file and telling it which package properties you want it to be able to configure.
A word of caution
Be careful when you're trying to SAVE sensitive information inside SSIS packages. There is a property named PackageProtectionLevel which can be set at the project and package level. By default, it is set to EncryptSensitiveWithUserKey. Now, don't let this property trick you into thinking the entire package is encrypted. It is not. This setting specifically refers to how SSIS will handle properties that are typed as sensitive. For example, the passwords in the connection managers are typed as sensitive information. SSIS will encrypt that field so that it doesn't store passwords in plain text. But it ONLY pertains to saving/storing the package. You can pass in plain text through a variable or configuration file that will be read into a sensitive field (like a password) at run-time.
If you need to be able to save a password with the package you've developed, I would recommend changing the PackageProtectionLevel to EncryptSensitiveWithPassword and setting it to something your team is able to remember or uses to protect other assets. Once that setting is in place, you will be able to check the "Save Password" box within the connection manager and have that go where ever the package goes. If you don't need to save that password with the package, change the property to DontSaveSentitive. Like I mentioned, you can still pass in credentials through configurations or other means, but it won't be stored INSIDE the package itself.
Related
What is the 'best practices' way to configure connections in SSIS 2012 project (that will be deployed to the server)? Documentation and Google shows multiple ways to accomplish this, but which way takes full advantage of the 2012 project/deployment model and is easily customizable, maintainable etc?
Consider a project (NorthwindETL) with three packages with each package referencing localhost.Northwind. On SSIS server, there is a project 'NorthwindETL', and an Environment 'Dev'.
To configure the connection, I have the following options
IN BIDS: Hard code the connection (via connection manager) manually in each package. IN SSIS: Configure the SSISDB 'NorthwindETL' project, under the connection manager tab, modify the Northwind connection string, once for each package.
IN BIDS: Using the Connection Manager 'Parameterize…' option, create a project (or package) parameter to specify the connection string (Northwind_Conn). IN SSIS: Configure the SSISDB 'NorthwindETL' project, specify the Northwind_Conn parameter value.
IN BIDS: Create a project level Connection Manager (Project_Northwind_Conn). IN SSIS: Configure the Configure the SSISDB 'NorthwindETL' project, under the connection manager tab, modify the 'Project_Northwind_Conn' connection string.
IN SSIS: Create an Environment on SSISDB called 'DEV'. In the 'Dev' environment properties, under variables, create a variable 'Env_Northwind_Conn'. Configure the NorthwindETL project, set 'Northwind_Conn' to the environmental variable 'Env_Nothwind_Conn'
(Also, I would prefer a solution that allows us to specify items separately such as InitialCatalog and Server, but this is not necessary. Although the connection manager allows you to modify the InitialCatalog and Server properties, this does not seem to actually modify the ConnectionString.)
For connection managers that are to be used across all the packages, typically database connections, the 2012 release gives us Project Connection Manager (option 3). I find that to be the most enjoyable for connection managers as when I go to apply configuration, I'm applying it once at the project level instead of once per package.
Unless you run your dev/test/prod ETL from the same dedicated server, I am not a fan of naming my SSIS Environment Variables as such. The primary reason is that my deployment script then has to have the intelligence built into it to not only switch server names per tier, but also the environment name. Just makes more opportunity for the dumb to enter.
I'm also a fan of just creating an empty Folder within the SSISDB, call it Configs and then establish my SSIS Environment variables there. All projects then reference that folder's variables. At my clients, it's generally been the case that they're all referencing the same Sales database so it seems like more work for me to have to maintain N configurations to satisfy N projects instead of having a single shared configuration repository.
Script everything. Click the scroll icon as you create and assign your configurations. It's going to make it a far easier row to hoe when you need to migrate from one environment to the next.
I have an SSIS package that I am attempting to set up as a SQL Server Agent Job. This package takes XML files and inserts/ updates records in Dynamics CRM 2011. In my development environment, the execution works correctly. However, when deployed to the server (which is the same domain as the database concerned), when executing a System.MissingMethodException is thrown.
The machine definitely has the DynamicsCRM2011.dll in the GAC - this machine has both the database and teh instance of CRM2011 running on it. On my test machine, I was connecting to this server (which is on a different domain) without incident. I get the same issue for all users whether integrated security is used or not.
The files are correctly read, this error is happening when declaring the CRM service and assigning a new Helper from the service (CRM2011.Proxy.Helper).
Any ideas?
Are you sure u added the dll in GAC? You can copy the dll in the same folder as the SSIS Package.
I am new to SSIS and am facing an issue with reading a File from a remote server
I have a Flat File Connection defined at the Project level where the ConnectionString is defined by a variable say #AbsoluteFilePath.
The value of #AbsoluteFilePath is calculated at run-time to a UNC say :
\\myserver\myfolder\myfile.txt
I have a Web Application which invokes execution of the package.
I am able to view the file folder as a logged in user however the execution of the package ends in an error while reading the file.
The execution fails with error message of return code 0XC020200E
I tried mapping my UNC \\myserver\myfolder to Z: on the machine where SQL 2012 is running. However this too gives me the same error.
Is using UNC advisible in SSIS ? What is the standard way of doing this task ?
Following is the complete workflow I am trying to achieve :
Complete Picture
User picks a file on the web front end. the web application saves the
file at a shared drive and invokes the SSIS package to run. the SSIS
package reads the file from the shared drive and performs required
action it.
Update : Explaining Permissions and running SSIS package from stored procedure
Web Application X runs on a server server-web
SSIS package Y runs on a server server-ssis
accesses database on a server server-database
accesses UNC where on a server server-filesystem
The package is being run by executing a stored procedure by running a stored procedures mentioned here http://msdn.microsoft.com/en-us/library/ff878099.aspx
the connection string used by server-web is of the form
Data Source=server-ssis;Initial Catalog=SSISDB;Integrated Security=SSPI;
I'd bet dollars to dumplin's this is a permissions issue (besides the fact a search for 0XC020200E yields hits on file permissions).
Check the permissions for the account that is running the web application. It needs to be granted permissions to the share. It works with your account or the logged in user but that is probably not the same account that is running the package.
#user1826905 you were right, using a SQL Agent Job to invoke the SSIS package proved to be the simplest way of invoking the SSIS package from a web application.
This link http://msdn.microsoft.com/en-us/library/ms403355.aspx gives out two different way of invoking SSIS packages
using SQL Agent Job
using a web service
There is a third way of invoking SSIS which I was trying using stored procedures http://msdn.microsoft.com/en-us/library/ff878099.aspx but has an issue when working across multiple server hops kerberos delegation explained here
We are still struggling over using this approach to access the UNC due to accessing changing to Anonymous user after the hop
i am working in a client server envirnoment.. i have an SSIS package with xml configuration, when i configure it on a client and execute it, it works find, but when i copy that configured package and try to execute it from another client it is not executed and needs reconfiguration, after reconfiguration it works find...
i also try it with sql server configuration and the same problem was also there...
Is there any way that i configure the ssis package on one pc and can be executed from any client, means no need of reconfiguration when i copy it to another client....
thanks in advance....
When you create an xml file configuration, you provide a connection to that file. But when you move the package to the new client, you have to have the configuration connection as well. Let alone configuration, you need to have the connections set up properly for each and every object that you reference.
Thats the only reason I can fathom why your packages are failing.
executed from any client
Quite possibly not. You're going to need valid permissions (database, file system, ??) for the actions your package takes, and simply copying the package and configuration file won't create those automatically.
You might want to create an SSIS proxy account, grant the necessary permissions to the proxy, then run the package using the proxy. If this is all internal, you enable the proxy account on whatever client systems need to run the package. If you're distributing this to clients, give them instructions for setting up the proxy and they can do the same.
When I run VS2008 locally and open up a package that points to a remote database and run, I believe that the data, from the input file to the db server, is running through my PC, even if the data file is on the database server.
However, if the SSIS package is stored in SQL Server and I start the job through SQL Agent, my PC is out of the picture and that data does not flow through my PC and so I should get see a signatificant performance boost.
Is this the case? I just want to confirm. Currently, I do not have permission to save a Package on our development server and I am considering requesting rights to be able to do for the above reason provided that it is a valid reason.
What kind of access does one have to have to be able to save SSIS Packages on a SQL Server? Might there be a reason to deny me rights to do so perhaps because granting me such access would require giving an elevated access level that would also allow me to do other things that the DBA might not want me to do? As a developer, I think that I should be able to shuffle data from UAT, or so iother non production env into a DEV database without having to request that a DBA do it when he gets around to it.
Your understanding of where the package executes is correct, and performance will certainly be improved by moving execution to the server. At least, it will be if the server has more system resources than your workstation, especially RAM. And avoiding using the network unnecessarily is helpful too, of course.
There are specific roles created in the msdb database for managing SSIS packages so your DBA can let you deploy and run them without making you a sysadmin. However, as the documentation says, there is a possible privilege escalation issue if you run the packages from jobs so the recommended solution is to create a proxy account.