Plenty of info on setting up indirect configurations in BOL and in other sites so I won't bother posting up info on how to get it all going.

In my case I like to hold the configuration info in SQL Server rather than XML files, so it is set up centrally in one table. I'll do a more detailed blog on this some other time but basically there is a separate configurations database in Dev, Test and Live which holds relevant connection info, so a package will automatically configure itself when placed on the deployment server - the so called "keeping packages in the dark" method.

So, what else to look out for?

(1) Make sure there is a unique index on the "PackagePath" column.
There isn't one in the table which is automatically created by the design environment. Perhaps it should be a composite constraint on "ConfigurationFilter, PackagePath and ConfiguredValueType" but in all likelihood the "ConfigurationFilter and ConfiguredValueType" will be constant anyway - it depends on how you use the table. Anyway, you'll need this unique constraint because sooner or later someone will add a duplicate PackagePath with a different ConfiguredValue with interesting consequences!

(2) Once it's set up, create a rollback trigger on this table.
Future entries can then only be entered by script with an initial explicit disabling of the trigger. Why? Because in some cases the configuration values can be written from a package into the table directly from the designer
without warning and the trigger will prevent this occurring. It also acts as an extra security on the table which will be the most crucial table for our packages.

(3) Don't store connection strings directly in the configuration file.

ie never have:

\Package.Connections[ServerName_DatabaseName].Properties[ConnectionString]

But instead have the connection string stored in a package variable and have the variable's value stored in the configuration file:

\Package.Variables[User::s_DatabaseName_ConnectionString].Properties[Value]

Why jump through an extra hoop and do it this way?

Well if the PackagePath maps directly to a connection manager which exists in Package A but not in Package B, Package B will error when running. However if the PackagePath mapping to the variable is missing, you'll just get a warning but no error so the package will run ok.

The one exception to this is the connectionstrings to the Configurations Database which are hardcoded for each environment (more on this in a blog on logging some other time).

I'm sure I came across other problems with using the SQL table, but I didn't note them down. If anything else comes back to me I'll pots it up in a comment here.