* is not available on the HTTP server.

[Asnyder]

Starting to get a lot of "is not available on the HTTP server." all of a sudden.
I know this was an issue for some people before but I'm not quite sure why its happening to me now. Running self-hosted 10.1.1 on Ubuntu 14.04.

The packages are indeed in my Casper share and they have been indexed. I double checked that apache is running and it is. The packages in question can be downloaded from a web browser just fine.

[Asnyder]

I've tried accessing my caspershare from a browser using two different machines, both freshly imaged the same way. One allows me ot view and the other gives the "you do not have permission to view this folder" message.

[Asnyder]

Another update as things are getting even more odd.

When uploading a package via Jamf admin it's saying I don't have permission to. Nothing has changed though.

[Howard_Trevor]

Have you figured this out yet? I’m having the same issue with all of my Adobe CC apps. Seems to be like your issue where it started out of nowhere.

[Asnyder]

This ended up being a DNS issue. For whatever reason our dns entry changed IP's. I figured this out by trying localip/caspershare and externalip/caspershare and one would work but the other wouldn't.

[donmontalvo]

For HTTP downloads, the jamf client has a resumable download tolerance of 5 minutes,

If there is an anomaly or disruption in download, it'll keep trying until/unless the disruption lasts more than 5 minutes, then it'll give up and the policy will fail.

Jamf Support explained it has to be that way so one download doesn't cause a backlog of other policies (which can include critical time sensitive deployments like security patches, etc.).

This is why I hate Wi-Fi...it can be disrupted/disconnected if the computer goes to sleep, or if the screensaver kicks in, etc...sucks when it comes to deploying big payloads.

We actually are getting ready to create a workaround, thanks to Apple's dev team (who dropped the ball on High Sierra combo updates, where Jamf's advice is to push out the latest full High Sierra updater):

1. curl down our Apple_InstallmacOSHighSierra_10.13.3.dmg from the nearest DP (nice having a bunch of load balanced RHEL DPs)...this would be through a Launch Daemon and script we would deploy via policy.
2. Once DMG is downloaded, verify it, mount it, thencp the installer to /Applications/Install macOS High Sierra.app and make it invisible, then rm the DMG.
3. Create a Smart Computer Group (SmCG) using an EA to confirm the /Applications/Install macOS High Sierra.app is in place and ready.
4. Have a policy to run the Install macOS High Sierra.app installer.

If/when I come up for air and set this up, will post results.

[aamjohns]

I recently ran into this issue. I've had this issue randomly for a long time. Here recently I noticed any package that had a download failed. The log looked like:

[STEP 1 of 5] Executing Policy x (4.0.7906) [STEP 2 of 5] Downloading x-4.0.7906.pkg... Downloading https://x.x.edu/CasperShare/Packages/x-4.0.7906.pkg... The network connection was interrupted while downloading the package from https://x.edu/CasperShare/Packages/x-4.0.7906.pkg. Attempting to reconnect... Downloading x-4.0.7906.pkg... Downloading https://xedu/CasperShare/Packages/x-4.0.7906.pkg... Error: x-4.0.7906.pkg is not available on the HTTP server.

In my case, it was an expired IIS SSL certificate. I use SMB over HTTPS on Windows Server for distributing packages. IIS was using a self-signed certificate and it had expired. Once I found this and replaced it, my packages started working again. I just wanted to mention this as it was not obvious until I looked.

Thanks,
AJ

[Quagmire]

@aamjohns Where in IIS did you find that expired cert? I'm having a similar issue but not as familiar with IIS.

[aamjohns]

@Quagmire Open the Internet Information Services Manager. Expand under the Connections menu (on left side) until you expand Sites and then highlight your IIS site that you are using for JSS. With the Site name highlighted, on the right click 'Bindings' and then edit the HTTPS binding. At the bottom you will see 'SSL Certificate' and you will see the name. If you click the view button to the right, you can see the details of the certificate and its certification path.

The name you see should be the friendly name. Write that down. Open the MMC, File>Add/Remove Snapin>Certificates>Computer Account.

The certificate you are using for IIS should be listed in the Certificates>Personal>Certificates. You should be able to see the same friendly name. If there is no friendly name, you should still be able to find the certificate from the information you gathered from IIS bindings.

Does that help?

Later,
AJ

[MatG]

See this quite regularly, even if the .pkg its trying to get is about 30k (just a png)

Any ideas?