Error: Could not connect to the HTTP server to download

[sirkyle]

We are experiencing an issue with JSS 9.31 while attempting to cache a large package to remote users over HTTP that are connected via VPN and possibly Wi-Fi.

If you review the policy error below, the package partially downloads then times out. The error is "could not connect to the HTTP server to download pkg." In this policy, an additional smaller package is also cached at the same time. As you can see, this OtherSoftware.pkg has no problem downloading and caching.

We are working with JAMF support, but I would like to know how others in the JAMF community distribute large software deployments to client workstations that may have poor network connections. Also, I was able to reproduce this behavior with a DMG as well.

Actions from policy log:

Executing Policy SomeSoftware Cache Package... Caching package SomeSoftware.pkg... Downloading SomeSoftware.pkg... This package is a PKG or an MPKG, and the index.bom file is not found. Attempting to open the package as a flat package... Resuming download of http://jss.company.com/CasperShare/Packages/SomeSoftware pkg... Error: Could not connect to the HTTP server to download SomeSoftware.pkg Caching package OtherSoftware-1.0.0.pkg.zip... Downloading http://jss.company.com/CasperShare/Packages/OtherSoftware-1.0.0.pkg.zip...

Has anyone experienced this issue?

[isradame]

Check if your web server is ok, by typing http://jss.company.com.
If you get a "browser can't connect to server", try restarting the apache service by typing this command without the quotes "sudo bash -x /usr/sbin/apachectl -k start". It works for me all the time.

[sirkyle]

Thanks isradame. Our web server appears to be working as expected. We are able to download the pkg by hitting the URL directly as well from a browser.

Any other ideas?

[njwinter]

I'm seeing something that looks similar:

Executing Policy Office for Mac 2011...
[STEP 1 of 2]
Downloading http://jss.zzz.com/CasperShare/Packages/MS%20Office%20for%20Mac%202011.dmg...
Error: Could not connect to the HTTP server to download MS Office for Mac 2011.dmg
[STEP 2 of 2]

[sirkyle]

njwinter, is this also happening on workstations that are remote and/or using wi-fi with poor network connectivity?

[njwinter]

@sirkyle This is happening with local machines both over WiFi and Ethernet.

The machine can definitely contact the JSS over HTTP. Recon works, re-enrollment works, direct download of pkg via web browser works. Self Service displays everything correctly and attempts to execute the policy but then fails.

[justinrummel]

Is there a space in your PKG name? I've seen issues when using Cloud Distribution points and them not interpreting spaces correctly as "%20".

- Justin

[CGundersen]

We are running 9.31 (clustered JSS, multiple distro points) and definitely seeing some of this sporadically. Servers/resources appear fine at this time. I don't have a very good view of network health in my role, but some packet captures are probably in order.

Executing Policy BLAH...
Downloading https://jss.company.com/CasperShare/Packages/GarageBand-10.0.2.dmg...
Error: Could not connect to the HTTP server to download GarageBand-10.0.2.dmg
Downloading https://jss.company.com/CasperShare/Packages/iMovie-10.0.4.dmg...
Verifying DMG...
Installing iMovie-10.0.4.dmg...
Closing package...
Downloading https://jss.company.com/CasperShare/Packages/iPhoto-9.5.1.dmg...
Verifying DMG...
Installing iPhoto-9.5.1.dmg...
Closing package...

[njwinter]

@justinrummel Yes, this particular package has multiple spaces in the name but we are't using cloud distro. It was working just fine until very recently. I will try removing the spaces.

The problem seems to be intermittent as well, as @CGundersen notes. My machine, for instance, can install this DMG 100% of the time. I'm beginning to wonder if this is a partial-download-resume issue.

[hcodfrie]

Got the same problem in my shop, also looking for a fix.
When those computers are connected @ work everything looks ok when connected @home that same policy fails.

[sirkyle]

This looks like this is a known issue and it hopefully will be addressed soon.

[tron_jones]

Try looking at this article. We were seeing this intermediately as well. Recreating the symlink fixed the issue.

https://jamfnation.jamfsoftware.com/article.html?id=116

We are running 10.9.3 mac server and this is the command specifically that worked for us:

sudo ln -s /Path/To/CasperShare/ /Library/Server/Web/Data/Sites/Default/CasperShare

[jarednichols]

Just for the hell of it, does it work okay if you flip the policy to distribute over AFP? If so, there may be a "stuck" download on the client side that needs clearing out. I used to see this more pre-9.

[Chris_abi-najm]

I've seen the same issue on my side, but what I did to fix it (temporarily) was to remove it from the policy, add it again and then rerun the policy. I, too, have spaces in the file name. I'll look to rename the packages.

[ronb]

We have been experiencing this same issue since moving to Casper 9.3 (now 9.3.2) earlier this year. It seems very intermittent. Sometimes you can just flush the same policy and it runs fine to the same machine that it had just errored out on (same error as described above). Other machines receive the "pkg" or "dmg" packages fine. We have a ticket in JAMF, and I am testing running a package now that consistently errors to one particular system with "DEBUG" logging right now. I will send that to them shortly.

Also, we cache the vast majority of our installation policies, and "pkg" files, specifically from Adobe, will not download at all anymore. It used to be intermittent as well in Casper 8. Now we have to package it up in a dmg and then a packaged script (utilizing "PayloadFreePackageCreator" has been great) to run the installer after the fact.

[Jedberg]

We were seeing the issue as well, below are some notes as to what we experienced and where we are now in our testing.

Server Config w/HTTP issues:
• Mac OS 10.9.3 w/Server 3.1.2 • JSS 9.3.1
• Performance Mode Enabled http://support.apple.com/kb/HT5359

*** Notes:
- A reboot seemed to clear our issues up for a few days or more.
- Memory slowly getting eaten up, appears to be a memory leak (10.9.4 Update appears to clear up the memory issue). The Server would show 95%+ memory utilization.
- App Nap was kicking in for the Finder and for Server app. Not sure of the impact on the HTTP issue, but we decided to test against it, because it is a possible variable.

TESTING SCENARIOS
Test Scenario 1 - Server has delivered all packages as of 7/11/14. App Nap was disabled and Server Rebooted. The memory consumption seems to be a little better after App Nap disable, maybe 80%+ utilization.
Server Config with no issues as of 7/11/14
• Mac OS 10.9.3 w/Server 3.1.2
• JSS 9.3.1
• Performance Mode Enabled http://support.apple.com/kb/HT5359
• Disabled App Nap "defaults write NSGlobalDomain NSAppSleepDisabled -bool YES"
• Rebooted
*** We plan to update this Server to 10.9.4

Test Scenario 2 - Server has delivered all packages as of 7/11/14. App Nap was disabled, OS Updated to 10.9.4 and Server Rebooted. The memory consumption is way better and showing only 20-35% utilization in comparison to 95%+ in 10.9.3 after Server had been running for awhile.
Server Config with no issues as of 7/11/14
• Mac OS 10.9.4 w/Server 3.1.2
• JSS 9.3.1
• Performance Mode Enabled http://support.apple.com/kb/HT5359
• Disabled App Nap "defaults write NSGlobalDomain NSAppSleepDisabled -bool YES"
• Rebooted

[ronb]

We are on Mac OS 10.9.3, but no memory leakage. We have not tried rebooting the server, but had noticed that after an unrelated Tomcat restart things were better, for a bit.

We have a ticket in to JAMF right now on this, and they are looking thru our debug log now.

[hcodfrie]

I just fixxed my could not connect to http server problemen, in my case the permissions on the dmg or pkg file was wrong i did a chmod 755

[jkuo]

I'm still experiencing this issue as well, but with an amazon CDP. Initially, doing a chmod 755 fixed the issue, but it's popped up again and it's pretty regular. Sometimes it works, but oftentimes it doesn't. Does anyone have an idea how to fix this?

[sirkyle]

This defect (D-005954) was not addressed in 9.5.

[ronb]

We've been working with JAMF on this issue for a while now. I keep thinking it must be something in our environment. But it is a very intermittent issue. We typically get right around 5-6 errors per day. All other systems have no problems that day. The next day it's typically different computers with the problem, but still only a handful. And of course we're seeing everyday for the "all managed" scoped policies that run daily. Very finicky problem to nail down. But other policies we run once may, or may not see the problem at all.

[RobertHammen]

I have run into this... is there a partially-cached version of the download in /Library/Application Support/JAMF/downloads or /Library/Application Support/JAMF/Waiting Room? Clearing out those folders periodically seemed to help.

[palitech]

I am having this same issue. It just started happening Friday, but i also noticed I get an issue for CasperAdmin. Say it cannot connect to my CasperShare.

[jkuo]

The thing that worked for us is to convert all .pkg files to .pkg.zip files. This fixes the permission issue and the failure to find a BOM file.

@palitech - for the failure to connect to CasperShare, double-check that it's not still mounted from a previous session, and eject it before trying to open CasperAdmin again.

[palitech]

Thanks @jkuo- I got on a webex with JAMF and they had me re-create the symlink. This resolved the issue of the share not mounting. But I am still getting the HTTP error. Will try the .zip method. Also waiting oN JAMF for another webex. Thanks again.

[RobertHammen]

Check the clients for partially-cached files in:

/Library/Application Support/JAMF/downloads
/Library/Application Support/JAMF/Waiting Room

Purge them. Now try. Does this fix the issue?

[donmontalvo]

@sirkyle][/url Looks like D-005954 wasn't addressed in 9.6 either. :(

@RobertHammen that might fix the problem on one Mac, the pressing concern is the issue effects users across our global environment. Hoping JAMF addresses the defect soon.

[RobertHammen]

@donmontalvo I've seen this issue intermittently and it's frustrating. Often the Macs where it doesn't work, purging those folders fixes the issue on that machine. Thinking about a script to purge those and a weekly policy to do so, but have to be careful it doesn't hose any caching policies (I tend not to use those much)...

[Jason]

I've started seeing this issue as well

From jamf.log

jamf[16404]: Executing Policy Cisco NAC Agent 4.9.5.3 (Install)... jamf[16404]: Error: Could not connect to the HTTP server to download Cisco2AC-0X1.39EC0BFF39EECP+0gent 0xbff39ec0kg

From running sudo jamf policy -verbose

Downloading Cisco%20NAC%20Agent%204.9.5.3.pkg... 2014-10-30 15:47:10.896 jamf[16404:332f] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9812) This package is a PKG or an MPKG, and the index.bom file is not found. Attempting to open the package as a flat package... Downloading https://<SERVER>/CasperShare/Cisco%20NAC%20Agent%204.9.5.3.pkg... 2014-10-30 15:47:10.906 jamf[16404:332f] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9812) Error: Could not connect to the HTTP server to download Cisco2AC-0X1.39EC0BFF39EECP+0gent 0xbff39ec0kg

Opened a case with JAMF referencing this thread. The D-005954 relates specifically to caching packages i was told, where they do not resume if connection was interrupted. So i don't believe that relates to what I am seeing as it's a direct install w/o interruption. It does appear to be garbling up the name though, not just with the %20 spaces, but on that final line. I'll update if i get something more helpful to share from my case.

[mm2270]

Just wanted to chime in that, although we're not using Casper Suite 9 just yet, I have been seeing this issue, because I've been assisting another admin with their version 9.5 JSS. I began seeing problems with an Office update policy that was generating these same errors. The package is valid and is definitely up on the share points. It also contains no spaces, just alphanumeric characters and periods.
I've had to come up with scripted workarounds for some policies due to this issue. It definitely is an annoying one, because there's seemingly no rhyme or reason why its failing.
I can check on permissions at some point, or try creating zipped versions of the files (actually I think the pkg I created automatically became zipped when I uploaded it?) to see what may help.

I hope this gets addressed soon, because its almost a showstopper. If packages fail to download, most deployment policies become useless unless you're pushing a script that's contained within the JSS 9.x database. Those seem to work just fine. Its only when accessing a package from an http share that I see this failure message.

[wstewart3]

Also experiencing issues with HTTPS

Executing Policy VPN Install... [STEP 1 of 1] Downloading https://x.x.x.x/CasperShare/Packages/x.dmg... Error: Could not connect to the HTTP server to download x.dmg

We made an IIS instance to run the HTTPS download share.
If I put:
https://x.x.x.x/CasperShare/Packages/x.dmg
into a browser, it immediately pops up asking for credentials, which I provide and it downloads without any issue what so ever.

But once I try it in self service it fails to mount.

[donmontalvo]

@mm2270 wrote:

I hope this gets addressed soon, because its almost a showstopper.

To be honest, it actually is a show stopper for environments that need to deploy software to remote users (combinations of small pipe, latency, VPN, Wi-Fi, etc.).

HTTP offers resumable downloads. So where a deployment is staged (cache package; install package), Casper has to ensure the download is complete before running the policy. In our case it looks like Casper tries to run the policy before the package is fully cached, then fails, never tries to run again.

We had a talk with some JAMF folks yesterday; they know it's serious and they're putting resources on fixing it.

Don

[donmontalvo]

@wstewart3 wrote:

But once I try it in self service it fails to mount.

Shouldn't try to mount if the policy is using default HTTP only protocol?

[wstewart3]

Probably not....

But I have "Use HTTP downloads" checked with all the right settings as far as I know.

[Kaltsas]

@wstewart3 are you using a self signed certificate? I was never able to get HTTPS downloads working with a self signed certificate. HTTP downloads work fine.

[donmontalvo]

In JSS 9.x the default is to use HTTP. When you added the package to the policy, did you select Distribution Point > Specific file share distribution point > File Share Distribution Point > (DP name) > [x] Force file sharing over AFP/SMB?

external image link

external image link

[wstewart3]

That was actually the issue I think.. sort of...

Our certs are not self signed, but I think that was part of the problem. In "General" under "File Share Distribution Points"

We had set:
Server
Hostname or IP address of the distribution point server
To our servers IP address. But once I changed it to our actual host name instead it worked perfectly with HTTPS and username and password credentials.

[themacdweeb]

we continue to have this problem here as well despite working with jamf for weeks on the issue.

our set up:
hosted JSS with jamf running JSS 9.52.29190.c
VM Win2012 server hosting our CasperShare in our DMZ
no other distribution points
clients spread out around the globe

what we've tried:
+ forcing file sharing over afp/smb
+ forcing http by unchecking the afp/smb options
+ flushing the policy errors to re-run and hope for best

what we've not tried:
purging data in /Library/Application Support/JAMF/downloads & /Library/Application Support/JAMF/Waiting Room

and we won't try that. jamf needs to get their shit together. this functionality is THE CORE SERVICE they provide. i don't want to have to hack around it to make it work. that takes time and effort. and if i'm going to invest my time and effort, it will be on the phone with every jamf VP i can talk to.

this. is. ludicrous.

[Look]

We have been getting this for quite a while now, it's probably 10% of machines in a big deployment (all internal so WiFi or Ethernet). It's managable but I just wish there was retry options on policies so you you didn't need to flush failed machines before they retried, it would be lovely if they just retried again 24 hours later.
Haven't tried clearing local client cache files, might add that to weekly maintenance and see if it helps.

[jkuo]

Hey all - I'm still encountering this same issue on a small percentage of computers, regardless of what distribution point/method they are using. I don't see anything in /Library/Application Support/JAMF/downloads & /Library/Application Support/JAMF/Waiting Room and no phantom volumes. Any ideas what else I can try?

Thanks!