Web Deploy: Majority of installations fail (Source file not found)

[linder]

Although I do appreciate the labor you've put into solving this puzzle, I don't believe I would conclude that there were no human beings behind the downloads. I did indeed get complaints from a handful of users that they were unsuccessful in downloading the Web Deploy version.

Okay, let's have a look on your server LOG in deep detail. On 19-03-2019 the SetupBuilder Web Installer downloaded cluster files in nine (9) different sessions.

1. IP 207.102.138.40 (Session 3)

From 04:19:58 - 04:21:03 this IP downloaded cluster files in the range of .00001 - .00053.

The IP belongs to Fortinet Technologies, Canada. It has been reported 15+ times for Hacking Brute Force, Web Bot Web activity, Web App Attach, etc.

2. IP 46.246.43.14 (Session 6)

From 05:20:59 - 05:23:14 this IP downloaded cluster files in the range of .00001 - .00053.

The IP reverses to "anon-43-14.vpn.ipredator.se". This should be enough information to guess what is behind this IP. Interesting to see that it downloaded again the same range of cluster files.

3. IP 185.189.94.31 (Session 11)

From 06:01:37 - 06:02:07 this IP downloaded cluster files in the range of .00001 - .00006.

The IP belongs to AVAST Software s.r.o. - Czech Republic. This says it all.

4. IP 67.137.36.66 (Session 35)

From 10:49:29 - 10:50:38 this IP downloaded cluster files in the range of .00001 - .00053.

The IP belongs to Integra Telecom Inc. It has been reported 14+ times for bad traffic, DDoS Attack Hacking, Email Spam Brute-Force, Fraud Orders, etc. And again the same .00001 - .00053 range of cluster files.

5. IP 47.13.117.202 (Session 88)

From 15:53:04 - 15:56:44 this IP executed eight (8) Web Installations to download the same .00001 cluster file eight (8) times.

The IP belongs to spectrum.com. I don't think we need any more background information here.

6. IP 47.13.117.202 (Session 94)

From 16:23:35 - 16:23:50 this IP started again eight (8) Web Installations to download the same .00001 cluster file eight (8) times.

The IP belongs to spectrum.com. See 5. above.

7. IP 24.55.129.30 (Session 96)

From 16:38:09 - 16:57:42 (in 19:33 minutes!) this IP downloaded the .00001 - .00005 cluster files.

As far as I can see, this IP belongs to the "Penn View Bible Institute". This machine had a very slow Internet connection. In 19:33 minutes they downloaded ~25 MB - this translates to 1.3 MB/min. That Internet connection needs 3-4 hours to download all your cluster files. So it's very well possible the session timed-out on your cluster file .00005 (which is 9.88 MB in size). Note: the AVAST IP (see Session 11 above) downloaded cluster files in the range of .00001 - .00006 (30 MB) in 30 seconds.

8. IP 104.242.15.134 (Session 111)

From 18:27:37 - 18:35:03 (in 7:26 minutes) this IP downloaded .00001 - .00005 cluster files.

In 7:36 minutes they downloaded ~25 MB - this translates to 3.4 MB/min. That Internet connection needs 2 hours to download all your cluster files. See 7. above.

9. IP 47.13.117.202 (Session 160)

From 23:56:44 - 23:57:41 this IP started again eight (8) Installations to download .00001 - .00005 cluster files.

This IP belongs to spectrum.com. See 5. + 6. above.

To sum it up: we have analyzed all nine (9) Web Deploy sessions from your 19-03-2019 LOG. Most likely, seven (7) sessions where automatically executed from within sandboxes. Two (2) sessions might have been timed out. Requests sent to the server—and responses from the server—can time out. This occurs when a low-bandwidth connection requires too much time to transmit the data. The default timeout for blocking receive calls in Web Installation HTTP actions is set to 10,000 milliseconds. You can increase this using the HTTP_TIMEOUT #pragma.

We have executed seven (7) of your Web Installations and all seven sessions succeeded without any problem (from different Internet connections). And even from machines thousands of miles away from your server.

Please don't get me wrong, and with all due respect, but I have to stop here. I have put quite a few resources into investigating this case. There is no "Source file not found" issue in Web Deploy. And it's simply not fair to say that your email campaign has turned out to be a disaster because (according to the LOG file) 8 out of 8 different users failed to complete the web deployment.