Hi
An age - old question I know, but I'm trying to help a client currently with a historic set up overcome a limitation, and at the moment I can't think past the brick walls - perhaps because there isn't a way around it.
The current configuration set up, for many SSIS packages that ideally should not be changed, follows the pattern of
1) Load a Connection manager's connection string from an environment variable
2) Use that connection to fetch various settings and connections from a SQL Server table
The dev hardware architecture currently shares few app servers (SSIS) between many database servers. As a result, using one app server requires the use of several service accounts, each with it's own user environment variable to separate the configurations
being picked up for step 1) above allowing simultaneous executions to take place.
Ideally, without changing the packages in any way, we want to allow the passing in of the connection string at runtime (from the job engine) to avoid having to use environment variables at all. This we have achieved easily enough by removing the environment
variable and passing in a command line /CONN in the DTEXEC command. Since the environment variable is not found, it is not used (just produces a warning) and the /CONN value is used. The application order of configurations does not have a negative
affect since the design time re-load at the final phase again does not find a env variable, so does nothing to override that passed in by /CONN. /SET would behave similar in this respect, and overall we have achieved the effect of removing the env variable
reference without having to touch any packages.
The issue arises when using this technique in the OAT environment, where the OAT service account does not have permissions to the connection strings as saved in the package at design time. Therefore:
1) Phase 1 loads the design time env variable (no longer exists, nothing is changed). Then attempts to apply the settings from the SQL table using the saved dev connections (gets permissions error)
2) Phase 2 loads the /CONN value, succeeds
3) Phase 3 changes nothing as the env variable doesn't exist, and re-uses the /CONN setting. All good.
The package then runs it's tasks successfully, but returns an overall failure result to the job engine due to the permissions error generated during phase 1. Adding the env variable back of course does not help unless it is correct (defeating the object).
We can't use a "generic" config here either as ultimately it is the one that gets applied in phase 3.
Any ideas on how this can be worked around, without modifying the many packages (or granting permissions on Dev servers to OAT accounts). Unfortunately the SuppressConfigurationWarnings package property does not help with errors - but if there was
a way just to ignore config errors this might be acceptable.
Thanks for any help!
