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.

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?

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]

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

@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.

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

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...

@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.

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.

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

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

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.

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.

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.

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

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.

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

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?

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

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.

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.

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.

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.

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.

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?