Hello, I have some SSIS 2008 packages that I am running from SQLAgent on the file system. I am atttempting to use XML Package configuration files to set variable values in my package. Most, if not all of the package variables are used within Expressions to set connection strings, file names and so on. The packages work fine locally in VS2008 BIDS, but when i copy them remotely they are always trying to use the values specified in my development configuration location. e.g. D:\MyLocalDevFolder\SomeConfigfile.dtsConfig This is what I have as the command in SQL Agent: /FILE "\\somePC\shared\MyPackage.dtsx" /CONFIGFILE "\\somePC\shared\SSISConfig\SomeConfigfile.dtsConfig" /CHECKPOINTING OFF /REPORTING E Basically the problem is that the values in the config file on the share is being completely ignored, any variable values set at design time are being used. If I manually open up the .dtsx file and change the ConfigurationString setting of the XML to be the desired location of my config file, the correct settings are picked up, but this is clearly not desireable. Therefore, what I would like to know is what setting do I need to tweak (or add) to the above command line to Force the running package to set the values of all Variables specified in the shared config file. Thanks, MrPedsDatabase and Application Developer

One thing to check: does the agent account or the proxy runny the job have access to the \\somePC\shared\SSISConfig\SomeConfigfile.dtsConfig file and its containing folder? Russel Loski, MCITP Business Intelligence Developer and Database Developer 2008

This may not help in this situation, but I have seen some best practices where there is only ONE 'item' configured via an XML file, and that is the Connection String of a SQL Server database that holds all the other configured values (other Connection Strings, Variables, Properties, etc). And that XML Config file is in the same location on all servers so when a package runs, it knows right where to get it, it doesn't have to be 'told' where it is vai a /CONFIGURE switch.Todd C - MSCTS SQL Server 2005 - Please mark posts as answered where appropriate.

I’ve experienced this before when I didn’t use a SSIS Deployment Manifest to deploy my packages and just copied the dtsx files. I never bothered researching why as I started using deployment manifests. Todd C has provided an alternative which is a good way of doing things if you don’t want to create SSIS Deployment Manifests every time you make a change Jeff Wharton MSysDev (C.Sturt), MDbDsgnMgt (C.Sturt) MCT, MCPD, MCITP, MCDBA, MCSD, MCAD

We are facing the same problem like MrPeds is facing. Todd, what do you mean by "there should be one item configured via an XML file"? In our xml config file, we have 1 configured value for flat files paths and 3 configured values for 3 different types of database connnections. But the packages that we want in Prod only uses the configured value for the flat files paths and one of the configured value for the database connection.

Mr. SSIS: This is how I have my stuff setup: The first Configuration listed is an XML File, and that contains the Connection String to a SQL Database. (Every package has this database as a Connection Manager). Then every OTHER Configuration that I want to store goes in the SQL Database (named SSIS_Configuration). Every Connection String gets its own 'Filter'. Every Variable gets its own Filter. Now when you design a package and say it uses a Connection manager that has been configured. You would go through the motions, but this time, you would click RE-Use when prompted. That 'connects' that new entry to the one already in the database. More here: http://toddchitt.wordpress.com/2008/06/27/ssis_config/Todd C - MSCTS SQL Server 2005 - Please mark posts as answered where appropriate.

Thanks for your reply Todd. In our case, we are not suppose to use any database tables to store the connection strings. We can only use xml for configuration purposes. So, in this case, what would you suggest?

Seriously? They would rather you store Connection String info (whcih might possibly contain Usernames and Passwords that have EXTNSIVE RIGHTS on the resources) in a file instead of a secure Database where you have much better control over who can see it? Wow, amazing! OK, then try this approach: Make the path to the XML file such that you don't need to tell it where it is when you move the package(s) from one environment to another. Make the path the same on all servers/environments.Todd C - MSCTS SQL Server 2005 - Please mark posts as answered where appropriate.

I know its pretty amazing!!! The approach that you suggested might not work because we have 2 config files, 1 for tst env and 1 for prd env. The paths for both the config files are different too. When we run the packages in tst env, we use the tst config. The path for the tst config is hardcoded in the "Package Configurations Organizer". We used this dtexec command to run the packages in tst env: dtexec /FILE "\\Nas1\ssis\Warehouse\Dev\ProjectName\Packages\Package.dtsx" /CONFIGFILE "\\NAS1\TESTETL\TST\Warehouse\Connections\TstConfig.dtsConfig" /CHECKPOINTING OFF /REPORTING EW When we move the packages from tst env to prd, we use this dtexec command to run the packages in prd env: dtexec /FILE "\\Nas1\ssis\Warehouse\Prod\ProjectName\Packages\Package.dtsx" /CONFIGFILE "\\nas1\ssis1\Warehouse\Production\_GlobalConnectionStrings\PrdConfig.dtsconfig" /CHECKPOINTING OFF /REPORTING EW However, the path for the config file is not being overwritten by the prd path. Therefore, we are not able to run the packages.

I am curious if it has something to do with the underscore in _GlobalConnectionStrings. Besides, just my 2c: you better off with coding the path to the config file in an Environmental Variable so this way you have to need in modifying the path anymore.Arthur My Blog

Arthur Z, I do not think its anything to do the the folder name. However, I did try using environmental variables and so far it seemed to be working. Thanks!