The example given works fine.  However, I have experienced issues with using the Dynamic Properties Task to set database connections in nested DTS Packages.  Sometimes it worked, sometimes it didn't.  With a complex environment, there is also a good opportunity to miss setting a connection that could cause large problems.  I have found that storing UDL's local to the different machines worked more consistently for connections. 

In my opinion, a DTS package is not portable unless the server from which it is moving can be taken completely out of the picture. This actually creates more overhead, in my opinion, because now you have a whole database that you have to copy over to a new server if you are moving a dts package and you have to manually edit the .ini file to satisfy complete removal of the other server.

By his own admission, the author states that a requirment for his process to be successful is that "Be executed from a client machine as well as on the server – Does not reference any local files or connections.". Yet his whole process relies on the existence of a "Local Connection" withing the DTS Package that is pointing to a local mapped drive to the .ini file. So there are two local aspects in his equation and therefore does not satisfy his requirement.

Take a look at the series of posts I'm putting together on my blog about a very similar technique.