Hello, I've recently upgraded (in-place not side-by-side) a SQL Server 2005 instance to SQL Server 2008 R2 and I'm now in the process of migrating the SSIS packages. The packages that have not yet been migrated are (apparently) running successfully, but the newly migrated packages are suffering from a problem of not knowing where their dtsconfig files are. I use the dtsconfig file to specify server specific values (where to log to, where a file is, etc.) so that I can use one package on multiple servers by switching the dtsconfig file. When I built the package I put in some dummy information to act as place holders untill the dtsconfig file is read to supply the correct values. The packages are held in the file system (...\100\Packages\...) and not in msdb. To run a package I an creating a SQL Server Agent Job and am specifying a dtsconfig file here, but it doesn't appear to be being used. I am currently unable to deploy the packages via the manifest so I have been simply copying the dtsx file and dtsconfig file from my build environment to the live environment. Is there a setting in the config file that is changed during deplyment to set my selected dtsconfig file as the primary config file? Is there anything else I should be considering as to why the config file is not being used? Mike

AFAIK the config file is used in order of adding. If you give it during the calling to the package, that will be used, if not, package will look inside to the given path. If it don't find some, it will use the values inside the package. Are there any messages in the logging file?

Configuration application rules changed from 2005 to 2008 (and remained the same in R2). John Welch has a good blog post detailing this, and what you can do about it. In no version of SSIS does the application of configurations rely solely on the order in which they're defined. Talk to me now on