Setup Environment Variables in SQL Server Integration Services

By:   |   Comments (4)   |   Related: > Integration Services Configuration Options


Iíve created a SQL Server Integration Services (SSIS) project in Visual Studio. I added a couple of packages and now I want to deploy everything to the server. How can I change my connection strings dynamically? I donít want to update all my packages manually after theyíre deployed to the server.


Starting with SQL Server Integration Services 2012, we can use the project deployment model. In this model, we have environments and environment variables at our disposal. Together with parameters, they give us a convenient, flexible and powerful way to dynamically change the behavior of SSIS packages.

Do not mistake the SSIS environment variables of the project deployment model with environment variables of the Windows operating system. In SQL Server 2005 and 2008 we could use those variables to configure our packages as well, in combination with configuration files or tables. This is still possible when you convert your project from the project deployment model to the legacy package deployment model. For the remainder of this tip, we will work with the project deployment model, as it is easier to work with, more flexible and more robust.

To illustrate the use of environment variables, weíll follow this process:

  1. Configure a project connection manager with a project parameter
  2. Deploy the project to the catalog
  3. Create an environment in the SSIS catalog, along with a variable
  4. Link the environment to the project and the variable with the parameter
  5. Execute a package using the environment

SSIS Project and Package Set-up with Parameters

The easiest way to work with environment variables is first to use parameters in your packages. Parameters are like SSIS variables, except they cannot change value during the execution of the package. Parameters are excellent constructs to pass values into a package at the start of an execution and to control its behavior. You can have parameters at the package level and at the project level.

Suppose I have an SSIS project with some packages.

ssis project tree

When you double click on Project.params, a tab will open where you can create project parameters. Letís create a parameter that will hold the name of the server that holds the Wide World Importers database.

ssis project parameter

Setting the property Required to True means we need to change the value of the parameter after deployment. Failing to do so will result in an error when the package is executed. This avoids the scenario where packages are being run with design-time values and you are changing data on the wrong server. Now we can use this parameter to create an expression in the project connection manager. When the parameter changes its value, the connection manager will change accordingly. You can assign an expression to a project manager easily by right-clicking it in a package and selecting ParameterizeÖ


In the dialog, we set the ServerName property to our project parameter.

configure servername with project param

Now we can easily switch between servers by changing the parameter value. You can easily notice when a connection manager is configured by an expression: a little fx icon appears.

fx icon

Development is done, now we can deploy the project to the SSIS catalog. We can take a look at our project parameter by right-clicking the project and selecting ConfigureÖ

configure ssis project

In the dialog, we can see our project parameter. The value is empty because itís a required parameter and we need to explicitly specify a value after deployment.

catalog project parameter

By clicking on the ellipsis, we can configure the value. The default value is greyed out since the parameter is required.

environment variables ssis 2016 008

However, what if you have 5 different servers on which your package can run? Do you want to manually change the parameter value each time? Or create several T-SQL scripts to change it every time a package is being executed? To solve this issue, environments were created.

Create Environment in SSIS

You can look at an environment as a collection of configuration properties, much like a configuration file or table in the legacy package deployment model. In every folder, you can create one or more environments.

create environment

In the dialog, you can give the environment a name and a description.

create environment

If you want to create this environment on multiple servers (aka multiple SSIS catalogs), donít hit OK just yet. You can script out the necessary T-SQL using the Script option.

script ssis environment

The result looks like this:

tsql create environment

The problem is that the Script option only scripts out changes. So, the entire environment will be scripted at creation time. However, if you try this at a later point in time (when there are no changes), an empty query window will be opened. If you want to script out existing environments, youíll need to look at 3rd party tools or write your own using T-SQL, .NET or PowerShell.

The next step is to add an environment variable to the environment. When you go back to the environment properties, a tab will be added for the variables. Here we can add a variable to configure our project parameter.

create variable

Remember, if you want to script it out, you need to do so when you have just created the variables and you are still in the dialog!

tsql create environment variable

Configuring the Parameter with the Environment Variable

The last step is to link the environment variable to our project parameter. The goal is that when we execute a package, we can switch between environments and easily influence the behavior of a package.

First, we need to create a reference between the project and the environment. You can do this by going back to the project configuration. In the References tab, we can add a reference. This can either be a local reference or an absolute reference. Absolute references remain valid and keep pointing to the same environment, even if we move a project to another folder. Local references will search for an environment of the same name in the current folder.

create environment reference

The last step is to link the environment variable to the parameter. This is done in the Set Parameter Value dialog of the parameter.

set parameter to env variable

If you want your parameter to be configurable by multiple environments, all environments need to have an environment variable that shares the same name. Donít forget to script everything out if needed!

link environments and params

When we execute a package, we must now select an environment. By doing so, the value of the environment variable will be passed to the parameter. When the package runs, the value of the parameter will be used to set the project connection manager. If we would select a different environment, we can force the SSIS package to run on another server.

select environment

After the package has run, we can verify the value of the environment variable was used in the Overview report:

overview report


Using environments and environments variables we can dynamically configure the behavior of SSIS packages. The advantage of using environments is to have a central storage of all configurations which can easily be reused across different projects. By using multiple environments, you can implement different execution scenarios for your SSIS packages.

Next Steps

sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip

About the author
MSSQLTips author Koen Verbeeck Koen Verbeeck is a seasoned business intelligence consultant at AE. He has over a decade of experience with the Microsoft Data Platform in numerous industries. He holds several certifications and is a prolific writer contributing content about SSIS, ADF, SSAS, SSRS, MDS, Power BI, Snowflake and Azure services. He has spoken at PASS, SQLBits, dataMinds Connect and delivers webinars on Koen has been awarded the Microsoft MVP data platform award for many years.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips

Comments For This Article

Monday, September 21, 2020 - 4:09:24 AM - Koen Verbeeck Back To Top (86509)
Hi Thiru,
environment variables in the SSIS catalog are typically used for more project-level values. You could create a separate environment variable for each package of course and for each package parameter you'll need to link it to its own environment variable. You can script out the creation of an environment variable to speed things up.


Wednesday, September 16, 2020 - 4:48:33 AM - Thiru Back To Top (86487)
Very helpful Article. Thank you.

I have some user variables with same names in multiple packages in the same project and they all use different values and previously I was using Package Configurations -> SQL Server -> SSISConfiguration-> ConfigurationFilter to separate them out for each package. Is there a way to implement similar configurations in the Project Deployment Model and Environment Variables?

Friday, June 9, 2017 - 9:44:52 AM - Koen Verbeeck Back To Top (57012)

Hi Stephen,


there is no real benefit that I can think of. I needed an example to illustrate the interaction between parameters and environments and this was the first thing I came up with :)

That being said, I do like all my parameters/configurations to be centralized in one place.


Thursday, June 8, 2017 - 4:15:11 AM - Stephen Back To Top (56966)

Nice article.

I was wondering if there is a reason why you did not map your server name variable to the connection manager directly in the configure step; rather than configuring paramaters at design time to do this? This is the approch that I have taken and was wondering if there is a benefit to doing it the way that you have sugeseted?



get free sql tips
agree to terms