I never updated my original post on using Box.com as a Casper Share after the Casper Suite 9.0 was released The process is still essentially the same as in 8.x, but instead of only posting updated screenshots I thought I would add in a couple of alternatives to relying upon Box Sync and Casper Admin as I had described before.
But first, something pretty important I’ve learned for anyone considering this workflow…
Single Sign On Considerations
WebDAV doesn’t work with SSO credentials. If you check out Box’s article here you can follow the instructions for setting up an ‘external password’ that will use the account’s email address and that password for authentication. If you choose to go this route consider setting password requirements that force the password to match or exceed what is used for SSO.
Now for putting it all together.
Setup the Casper Share Folder in Box
Before putting all of the settings into your JSS, make sure the Box folder you want to use is in place with the correct permissions.
Create a user account in Box that is just for read-only (viewer) access and invite it to that folder. By inviting the user you can have the ownership of the Casper Share rest with any other user in your Box account, located anywhere in their folder hierarchy, and it will still be a root-level folder for the read-only user.
Remember, you can invite as many other users are you need to for managing your packages, or you can get real crafty and do some fun stuff using Box’s automation tools they’ve introduced. Example:
- You have a folder in Box called “Package Staging”.
- Your IT staff upload a package here and it triggers a task to the party responsible for reviewing packages prior to distribution.
- If the task is marked as completed the package is then automatically moved to the Casper Share.
Nifty stuff. I won’t really dive too much into it beyond that, but you get the gist.
Now, inside the Casper Share create a new “Packages” folder. Because this is being treated as a traditional File Share Distribution Point the JSS will take the address and path we input below and then look for a “Packages” folder for the files to download.
The Box based Casper Share is now ready for use.
File Share Distribution Point Settings
In 9.x there was a change where the File Sharing tab for your File Share Distribution Point could not have empty values. In 8.x as I had previously described you could get around the File Sharing settings by never clicking on it. Even so, these settings are meaningless as we will never interact with this distribution point using AFP/SMB, so inputting junk values is acceptable.
The following screenshots detail the settings to use. Here is also a quick summary:
- General > Server Address: dav.box.com
- HTTP/HTTPS > “Use HTTP downloads” is checked
- HTTP/HTTPS > “Use SSL” is checked
- HTTP/HTTPS > Context: /dav/CasperShare — This can also be any folder you want instead of labeling it “CasperShare”
- HTTP/HTTPS > Authentication Type: Username and Password
Configure Your Network Segment
You may be in a position where you want to have specific network segments being directed to this distribution point, but generally you would want to use Box as the external catch-all for anyone who is not inside one of your offices. You Network Segment settings will look something like this to direct all external clients to download from Box:
- Starting IP Address: 184.108.40.206
- Ending IP Address: 255.255.255.255
- Default Distribution Point: Specific file share distribution point
- Default File Share Distribution Point: Your Box.com distribution point from above
Skip Casper Admin, Use a Browser and the API
In the previous article I had details how to setup Box Sync on a Mac, make the directory mountable allowing you to continue to leverage Casper Admin for package management.
You don’t really need to do that. Using the Box web interface works great for uploading even large files that are multiple gigabytes in size.
The one thing that was nice about Casper Admin was it created the package object for you in the JSS after you dragged it in and the app copied the file out to your master distribution point. You can easily do this yourself through the API and build out a workflow that works best for your staff. If you’re not familiar with the JSS REST API you can read my introduction post here. There are code example for how to interact with it.
The minimal XML you would use to post your package’s information into the JSS would look like this:
<package> <name>Twitter</name> <filename>Twitter.pkg</filename> </package>
That’s it. POST that to ../JSSResource/packages/id/0 and you’ll have a package you can assign to your policies. Of course, there are a lot of options you can set in the XML. You only need to include the elements that you want to specify in the JSS. Otherwise, everything not included in the XML will be set at their defaults (disabled checkboxes, no category, priority 10).
<package> <name>Twitter.pkg</name> <category>Social</category> <filename>Twitter.pkg</filename> <info>Repackaged on 2014-09-12</info> <notes>Packaged by Bryson</notes> <priority>15</priority> <boot_volume_required>false</boot_volume_required> <os_requirements>10.7, 10.8, 10.9, 10.10</os_requirements> </package>
There are also elements that are very specific to the type of package you’re working with.
If the installer requires a reboot, set that flag with this element:
If you’re using a DMG instead of a PKG you can set the “Fill User Template” options:
If you are still working in an environment with PowerPC Macs in the mix you can set the restrictions for the architecture and an alternative package to run:
Lastly, if you’re dealing with distributing software updates and want them installable only if they are listed in the Mac’s available software updates, you can enable that: