I appreciate that... thank you.

xp_cmdshell was the hint I needed...

I ran that and low and behold there's that value that keeps haunting me.

Bouncing the SQL Service was my next step, was going to do it first thing this morning before everybody got to work but my boss told me I had to have the Windows admins do it, even though its dev.

I'll get to work on scheduling the SQL bounce.

I think Environment Variables are great if you don't have to ever change them. And that was our intent when we first started using them.

The thing w/ Config files is that the deployment utility tries to package them up and if the DBA doesn't hack the Manifest to not push the config file, you overwrite your prod config. We use config files for data related variables. But we don't want app devs even knowing where their production SQL server is. Ideally using environment variables to store SQL Server names would let us (DBAs) promote app dev developed pacakges to QA and Prod with out having to change a single line of code or config file. But since we hosed our QA SSIS server and could run pacakges from it anymore, our work around was to run QA and dev pacakges from our dev SSIS server, hence the env var value shell game.

Anyway... thanks for the help gang. I'll follow up once I get the SQL service restarted