Evil Kraig F (8/1/2014)
Lynn Pettis (8/1/2014)
You could also use a system variable to contain the same information regarding the location of configuration files. We went with the XML file as it was easier to maintain and allowed us to expand locations depending on information in the package as well. IIRC when using a system variable you can only point to one location. You would have to verify that to be sure.This is correct. We use that in our environments as we use a dedicated SSIS Server with the configuration table on that. You can, however, have multiple system variables setup and have the configuarions link differently. I don't use XML configs however, but I know I've setup multiple data sources for the configurations via 3 different environmental variables, then had the rest of the configs read from different sources based on which data source they inherit from.
The only XML file we had was the one on the C: Drive (actually in its own directory on the C: drive). All the other configuration information was stored in a dedicated SQL database on each server. One thing we hadn't implemented was encryption for the passwords. Most of the connections in the configs, though, were trusted configs. Not sure if that was any better, but the only people who knew the passwords were the DBAs. Network servers had no access the any of the SQL Server instances on the servers we supported. Granted, they could change a password or add themselves to the DBA group in AD and gain access, but I wasn't go to tell them that.