SSIS Deployment

I created a SSIS solution that contains multiple packages. Now I need to deploy the solution to another computer. I've read an article regarding creating a "package configuration", but is very confused with what I'm reading. I just want to deploy the solution to another computer and make sure it runs properly. The package configuration file I created, includes the "connection managers, properties, and pretty much everythiing else. Is this all necessary? I'm I making this more difficult then it has to be? Thanks in advance.

>The package configuration file I created, includes the "connection managers, properties, and pretty much everythiing else. Is this all necessary?
Yes, and the resulting .xml file it creates is difficult to read if you're not used to .xml files.

If the 'other computer' has access to the folder location that the first computer's Configuration file (*.dtsConfig) resides, any other deployment to other pc's should be able to link to it fine without any modifications.

Now if any of the paths/database names change between 'first computer' and 'other computer', then you'll need two separate *.dtsConfig files, that point to all the connections each needs, and the SSIS packages need to refer to the correct one.

I'm using multiple environments (Development/Test/Production) on multiple servers to manage the packages in their lifecycle.
Thus I've created the same folder structure on all servers and made sure the packages have the Protection level in the Properties set to "DontSaveSensitive" and the Package configuration has been set to a XML configuration file that's pointed to by a System variable.

Now make sure that the System variable with the XML configuration file is set properly and that the XML configuration file contains the proper connections for the environment.
Moving a package can be done in this setting by a simple file move.

Is the basic advantage to creating a package configuration file is when you're using variables? For a simple deployment, why not just copy the folder containing the project to the destination computer?

The advantage is the fact that all connections are stored in one (xml) file and moving the solution to another machine linking to another database will only have effect on the xml file.

The system variable can be set using a (dos) shell command and is used to pass the location of the config file to the solution. This can also be used for having multiple config files and dynamically switching between target databases.

What if you have to shut down the entire Citrix infrastructure for hardware maintenance, software upgrades or "the unknown"? I developed this plan for "the unknown" and hope that it helps you as well. This article explains how to properly shut down …