Web Deploy gets blocked calling back to server

[spicymikey]

I'm sure this isn't an InstallAware problem but wanted to see if anyone had any insight into why our webdeploy setup (which has worked for hundreds of customers since deploying it) will not work for this one customer.

The Symptom: The Setup starts fine, goes through the menus fine, but when it tries to start the install and make calls back to the webserver for the media blocks, it can't connect.

Of course there are a lot of stupid things that cause this, permission issues on your webserver, etc. But keep in mind this is a mature installation process that has run for 6 months. Its just this one customer. No proxy server, no bad temp cache directing to obsolete links, etc. Just won't work.

Here's a first question. Hope someone can answer it at least and even offer other ideas: How does the InstallAware app communicate back to the mediablocks on the server? Is it all port 80 stuff or is there something more sophisticated with dynamic port allocations etc. ? I ask this because I'm wondering if a closed down firewall could possibly cause this.

Any ideas would be appreciated.

Thanks
Mike

[FrancescoT]

Dear Mike,

... really nothing of special on how InstallAware app communicate back to the mediablocks on the server.

Just a question (that probably seems very stupid),
if you try to download a file over internet, what happens?

Regards

[spicymikey]

Thanks Francesco. Yes, assume I've tried all the obvious. I can browse the folder where the media blocks are from IE. I can manually download the .7zip files. The problem only occurs programatically in the setup app when it is trying to download the first .7zip file. That's why I was wondering if there was anything besides pure permission or access rights that could trip it up (e.g. special TCP or UDP ports, etc.). FYI: It happens to be the media file for Crystal Reports but I don't think thats anything special other than it being the first one.

[FrancescoT]

Dear Mike,

the download process in InstallAware is done using the IE engine ... that's the reason why I asked to test to try downlod directly from IE.
So, no special TCP or UDP ports, etc

Very very strange!!!

I do not think that can be that particular media causing the issue ... even if with our job sometimes seems everythings could happens.

Possible obvious suggestions that comes to my mind:
- A possible antivurus ... have you tried to disable it (if any)?
- could you create a test setup that just tries to download a file?

I know ... my suggestions are not amazing .

Regards

[spicymikey]

Actually your virus software idea is a good one. Of course, I checked for that stuff on the local pc. However, this is a large corp. They may have something running at the network level or have some strange group policies blocking programs from making outside connections over the internet. I'll have to pursue that and post back anything that I ultimately find.

At least i know there's nothing ultra sophisticated going on in the setup app with TCP communication or ports. I write software with a lot of transaction communication, remote procedure calls, dynamic port allocations, etc. So in my mind that was my first suspect. If everything is just funneling back through HTTP port 80 then we cannot have a firewall or router issue.

I'll post anything I ultimately discover. Thanks for the thoughts.

[FrancescoT]

Dear Mike,

I really hope you will able to find out what happens.

Let me know .

Regards

[spicymikey]

In the end it turned out to be a network based product for monitoring Web traffic called "WebSense". We suspected that might be the issue early on but they assured me it was not blocking the installer from making calls back to our server to get the media blocks.

So nothing really to be learned here other than remember to look for spyware and general web monitoring software like WebSense when you have these type of connection issues.

Thanks for the help Francesco.

[FrancescoT]

I'm happy that you solved.

Regards