@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.
@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)...
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.
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.
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.
@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
@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?
Probably not....
But I have "Use HTTP downloads" checked with all the right settings as far as I know.
@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.
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
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.
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.
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.
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!
@Look @jkuo What version of the JSS are you running? On 9.62 or 9.63 and haven't seen this error recently. Have really not changed anything on the web servers. Client I was seeing this at most often was on Server 2008R2 w/IIS. Been decent since on 9.62...
@RobertHammen - I'm running 9.63. In new development, switching affected clients to use an AFP share instead of SMB navigated this particular issue (all on Linux). But that still doesn't address what happened or our users that are using a cloud distribution point. Any other thoughts?
Hi there,
Seeing this in a 9.62 environment with JSS and DPs running RHEL 6.6.
Executing Policy Install Canoscan Toolbox...
Downloading https://jssfiles2.aaa.ccc/CasperShare/Packages/CanoScanToolbox_5.0.1.2.pkg.zip...
Error: Could not connect to the HTTP server to download CanoScanToolbox_5.0.1.2.pkg.zip
Retrying using distribution point CasperShare Main [oggb]...
Downloading https://jssfiles.aaa.ccc/CasperShare/Packages/CanoScanToolbox_5.0.1.2.pkg.zip...
Error: Could not connect to the HTTP server to download CanoScanToolbox_5.0.1.2.pkg.zip
Submitting log to https://jss.aaa.ccc:8443/
That is despite the fact I can immediately run curl to download the same packages:
mac-16:~ xadmin $ curl -o CanoScanToolbox_5.0.1.2.pkg.zip -u user:pass https://jssfiles.aaa.ccc/CasperShare/Packages/CanoScanToolbox_5.0.1.2.pkg.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10.9M 100 10.9M 0 0 10.0M 0 0:00:01 0:00:01 --:--:-- 10.0M
mac-16:~ xadmin$ curl -o CanoScanToolbox_5.0.1.2.pkg.zip -u user:pass https://jssfiles2.aaa.ccc/CasperShare/Packages/CanoScanToolbox_5.0.1.2.pkg.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 348 100 348 0 0 467 0 --:--:-- --:--:-- --:--:-- 467
mac-16:~ xadmin $
@nzmacgeek, double check that the username & password for the HTTP DP is correct or present in the JSS.
Hi everyone,
Seeing something similar on our 9.64 JSS. Saw it before in 9.32 and 9.6. Maybe 5-10% of clients that receive a policy requiring HTTP download of a package can't connect to the distribution point. But manually connecting using curl on those machines works fine. Distribution points also working fine. Oftentimes a flush will allow it work in a second execution of the policy, but sometimes not.
Has anyone else found a solution? I can try switching to smb, but would really rather not because of clients external to our network.
We just this week began experiencing the Error: Could not connect to the HTTP server to download... on one of our Distribution Points running Yosemite. After digging around awhile I noticed in File Sharing in Server App that our CasperShare permissions for Everyone had changed to none. Switched back to read only and stopped and started service and http downloads started connecting again. We suspect recent Security update 2015-002 which installed I installed on 3/18 may have been culprit because all was fine before then.
Hate to necro this thread, but I just ran into this issue in 9.81... Has there been any official response on this at all?
Our initial problem with this had been resolved with an earlier version of Casper. However, we did get this problem again after a Mac OS Server upgrade. In this case it was easily resolved by commenting out a single line in a plist "#listen 8443" -
The Fix:
In terminal, run the command:
sudo nano /Library/Server/Web/Config/Proxy/apache_serviceproxy.conf
In the second section of this file, which looks like this:
/Library/Server/Web/Config/Proxy/apache_serviceproxy.conf
listen 80
listen 443
listen 8008
listen 8800
listen 8443
listen 8843
We will comment out 'listen 8443' so that the Server App is not trying to serve responses on that port:
/Library/Server/Web/Config/Proxy/apache_serviceproxy.conf
listen 80
listen 443
listen 8008
listen 8800
"#listen 8443" (without the quotes)
listen 8843
Then CTRL + X to exit, Y to save, and Enter to exit.
Restart the Websites feature in Server.app and then restart Tomcat.
This was from another thread found - https://jamfnation.jamfsoftware.com/discussion.html?id=17110
I'm running this on Windows Server 2012, but I'll take a look to see if IIS is listening on 8443 (doubtful, but good to check.)
Thanks for hopping on to help.
Hi - Has anyone had any luck fixing these issues? I'm now working on self enrolment in El Capitan. My JSS has a self signed certificate and our test machine is unable to download policies which include packages. Navigating manually to the .dmg location is successful.
Mon Dec 14 10:22:56 client-name jamf[6365]: Executing Policy Google Chrome 46.0.2490.80...
Mon Dec 14 10:22:56 client-name jamf[6365]: The network connection was interrupted while downloading the package from https://server-name/CasperShare/Packages/googlechrome-46.0.2490.80.dmg. Attempting to reconnect...
Mon Dec 14 10:22:57 client-name jamf[6365]: Error: googlechrome-46.0.2490.80.dmg is not available on the HTTP server.
Make sure the PKG is on that server and make sure permission is set to 755 (if Windows similar).
