Error after migrating package from development to staging

I've migrated a package that has worked in our development environment. In both environments (dev & staging) I am in the BUILTIN/Administrators local group which is in the sysadmin server role.

In our staging environment, I execute DTEXEC command from the command line and get the following results.

D:\Reporting>"D:\Program Files\Microsoft SQL Server\90DTS\Binn\DTEXEC.EXE" /SQL "\MSDB\ProcessReportingDatabase" /SERVER USFKL16DB1CI01 /MAXCONCURRENT " -1 " /
CHECKPOINTING OFF /REPORTING V /SET "\Package.Variables[User::RunID].Value";65 /
SET "Package.Connections[RSAnalytics].InitialCatalog";"VR New Test 1 Dec28-FndPrj 1 Dec28"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.1399.06 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

Started: 1:46:43 PM
Could not load package "\MSDB\ProcessReportingDatabase" because of error 0xC0014062.
Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80004005 (Login timeout expired). The SQL statement that was issued has failed.
Source:
Started: 1:46:43 PM
Finished: 1:47:02 PM
Elapsed: 18.797 seconds

In addition to my login, all logins that access this package are in the sysadmin role; and I have gone back and included these logins in msdb's dts_operator role. Has anyone seen this before?

Thanks - Dave

I received the same error. In my case, I was using an environment variable to indirectly point to a configuration file that would update connection strings in my connection managers. It worked fine during development, but when moved to production, that's when the error occurred. After some trial and error, I found that if I removed the indirect configuration and allowed the connection managers to use the default connections I setup, it worked properly. That doesn't explain why it worked in development but not in staging. I have a hunch that the difference is in development the config file was locally on my drive (a C:\... path), but when moved to staging, it was changed to a UNC path on another machine. There is no security on the path or file on the other machine that would block the user (the share is wide open to everyone on the domain for testing purposes), so it might just be the fact that it's a UNC path. I'll have to test it out on Monday. Hope that helps.

Update: I ended up having enough time to try a few things. I tried a UNC path pointing back to my pc using the PC name (not just 127.0.0.1) and it worked ok that way. So it appears it's not necessarily that it's a UNC path. Whenever I attempt to access the remote path from Explorer I'm able to view the config file. I guess I'll start looking into the Component Service configuration on Monday. Although I think it would be easier to try to rethink of how to manage my configuration files so that I can keep them on the local machine.