Thanks for the suggestion, but I am trying to get this running completely within SQL Server without the need for downloads, etc. This behavior is really weird, and I think it might be a network connectivity setting...very strange that it will generate inline XSD from an internet location, but when it comes time to run and hit the exact same url, it can't find the same location it was just at to get the XSD.

I have another update to post. I did a wireshark trace of network action during a successful run of the package in BIDS 2008 and of an unsuccessful run in SSDT 2012. These packages have the same settings (hitting the same urls, using the same database, etc.).

The successful run has GET requests similar to the following using the HTTP protocol:

208.87.234.180HTTP681GET http://corpslocks.usace.army.mil/lpwb/xml.lockqueue?in_river=AG&in_lock=45 HTTP/1.1

The unsuccessful run has no HTTP GET requests in the log...it looks to me like there are TCP requests generated in the logfile when it tries to go to "http://corpslocks..." urls, although addresses similar to the one shown in the above sample log entry are nowhere to be found. I see in the SSDT output log where it tries to get XML from (what I verify to be) valid URLs. This is a sample TCP entry where I assume SSDT is trying to get to the location of the XML:

10.1.13.103TCP27030585 > 62964 [PSH, ACK] Seq=7690 Ack=25761 Win=65024 Len=216

Is there some kind of intranet setting in SSDT that might be keeping it from going out to the Internet? Any other ideas? Thanks again for any help or suggestions.