bill.lawler (6/21/2013)
It appears the best practice is to have a single package configuration file name with instances of the the package configuration stored on each server. This may have been part of my issue as I had the configurations stored on a file share with the source code.Has anyone tried to build a master package configuration file that all SSIS projects and packages could access? I suspect this is not feasible as an item referenced in one package that does not exist in another package will casue SSIS to error.
It's not really feasible. One of the main uses for configurations is to allow for environmental modifications without having to open the primary package. This allows for code to be 'hardened' in change control with only ini file equivalents needing modification. My current location uses SQL tables for config control, but I've never tried to keep a consistent configuration across multiple environments. I've always used it the exact opposite way, to keep the code consistent and adjust the configuration across environments.
If you think of configurations as .ini files, and not source code, it may make your life a lot easier.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA