Ok, I am going to sound like a useless msdn moderator here, but just bear with me.

A couple questions on the execution: are the packages running with a package protection level like DontSaveSensitive or EncryptWithUserKey? Those settings have their own special personalities, and they may work in debug but totally different in SQL Server as a scheduled job. Now I have learned that the AcquireConnection... error is more generic than I once thought: usually SSIS didn't find the password for that user name (wasn't saved in the Connection Manager).

EncryptWithUserKey is a setting that will not allow a package to execute UNLESS it was run by that user (security context of Active Directory account) on the machine it was created. See this explanation: http://msdn.microsoft.com/en-us/library/ms141747.aspx Useless for any kind of multi-server environment.

Then there is DontSaveSensitive protection setting: it wants to use a configuration file. That is a major project in SSIS, of course, with little documentation behind it. But try the Package Configuration Organizer which will help make the config file for you. Then you need to deploy it properly (no build errors in Visual Studio) if you want it to work as a scheduled job in SQL Server Agent Service. If you don't deploy correctly the job will appear to execute the SSIS package successfully, but if you look carefully in the job history text, you will notice errors like 'Failed to decrypt protected XML node "DTS:Password"' Anyhow, I mention that because it is common to have the execution results in SQL Server not match the results of debugging in Visual Studio using configuration files, with the error text you mention: 'AcquireConnection ... failed...'

Finally, check the version of SSIS, not SQL Server Database Engine, but the Integration Services component, installed once per machine, not instanced like other MSSQL Server products. Make sure Integration Services has the latest service pack that matches the version of SSIS project types you are editing in Visual Studio. If it is more recent, no problem, but if it is older, expect some issues trying to run new package versions on old version of SSIS server.

Sorry for the huge ramble. Hope it helps.