I'm trying to get the MS Office 2011 update 14.3.9 package to deploy.
I downloaded it and tested it, it runs fine. I upload it through Admin, removing spaces, renaming per our convention, etc, and then push it - and it fails:
/usr/sbin/jamf is version 8.73 Executing Policy 2014-03-07 at 4:15 PM | gersteina1 | 2 Computers... Downloading BOM for Office-14.3.9.pkg... This Apple Package did not have a valid index.bom file. Assuming it is a flat file package. Downloading http://server_name:80/CasperShare/Packages//Office-14.3.9.pkg... Error: The package could not be found on the server.
One of the concerning things is the extra / in the path - but when I copy/paste that and try it in my browser, I manage to download the pkg file just fine - and it runs fine too.
We're running 8.73 for another week or two - but when I check the 9.23 release notes, I don't see anything specifically mentioning this, unless it's in the "other improvements" area.
My colleague seems to have put a DMG of 14.3.8 up, and that fails, but the 14.3.7 PKG I put up seems to be working fine.
So, any suggestions? I'm hoping that 9.23 fixes some other issues we're having, so I won't complain if waiting a little while longer gets this fixed to - I just need some light at the end of the tunnel.
make sure to force permission inheritance on your CasperShare. Sometimes on my JSS instance packages do not get uploaded with the proper permissions and forcing inheritance for the owner, group, and all ACLs on the Casper Share fixes the problem. All packages are accessible with all methods I use to access them (rsync via ssh, AFP, SMB, etc) after forcing this inheritance.
I'm running JSS v8.62 on Server 10.6.8. Soon to be upgraded to 8.73. v9.24 just doesn't seem polished enough yet.
Also, how are you creating your packages? Are you uploading .pkgs/.mpkgs straight from Microsoft or are you repackaging?
We've seen what @acdesigntech has stated on our Windows JSS a couple of times. Somehow, the share permissions got changed and although we could upload the packages, the CasperInstall account was unable to access them. Deleting the package and fixing permissions, followed by a clean upload fixed it. Good luck - this type of thing is very frustrating.
Deleted, re-uploaded, deleted, lather, rinse, repeat.
I have tried the .pkg right from the .dmg I downloaded from MS, and I've used Autopkg to make one - neither makes a difference.
What's killing me is that when I copy/paste the URL into a browser - on the same machine - it grabs the file just fine.
have you verified that permissions have been inherited for your casper user (whatever user is set up on the Settings > Servers > Distribution Points) on the package once it's uploaded via casper admin? It needs to have read permissions to that package.
Being able to download it via url in a web browser is not the same thing.
Permissions checked multiple times.
I would argue that since the agent is trying to get the file via HTTP, and I'm able to get it by copy/pasting it into a normal browser window, that it is the same thing.
Since the recent upgrade to Mavericks and 9.2.5, HTTP isn't working at all for anything, but I turned that off and AFP seems to be working for the time being.
@gersteina1, are you hosting you distribution point on a Mac OS X server or on something else? Can you deploy smaller pkgs (say less than 20MB) to the affected computer? I ran into a similar problem when hosting the distribution point on Mac OS X 10.7.5 server that had WebDAV turned on. Smaller sized packages would download fine via http but larger packages would occasionally error out with the same message. If you're using OS X server it might be worth it to check if WebDAV is enabled and if it is turn it off and test again.