Tiny Deathstars of Foulness

The Caching Server in OS X Server 5.2 (for Sierra) does content, apps, and software updates. The Software Update service is hidden by default indicating it will likely be removed from the Server app in a future update, although when is kinda’ up in the air. The Software Update service can still be enabled for now, which we’ll look at later. The Caching service on the Server app works like a proxy. When 10 of your users download that latest Nicholas Sparks book and movie, you only sacrifice your WAN pipe to download it once, and the other 9 people piggy-back off that. And when 10.12.1 ships, you only need to download it over the WAN once, and the other local users will pull off that spiffy Caching server sitting in your office. Pretty sweet, right?

So, how do you use this ultra-complicated service? It looks and feels kinda’ like an iPad app. Which is to say that as far as server stuffs go, this thing is pretty darn easy to use. To get started, open the Server app and then click on the Caching service in the sidebar of the Server app.


Here, click on the ON button. OMG, so hard. But wait, there’s more! Click on that Change Location button and you can select a larger volume for your updates that are cached. You’ll likely wanna’ do this because the entire series of the HBO drama OZ is kinda’ big (and yes, creepy, but really well written)…

If you do change the location, you’ll see a window to change the volume you’re caching to. That’s pretty much it. Other than the waiting for the updates to move. By default, the Caching service allows for unlimited space. Use the spiffy slider to reduce the total amount of space that the service can occupy on the hard drive. This can be a good thing if it happens to be your boot volume and there are other more mission critical services hosted on that thing.

Overall, this all seems pretty straight forward. So what else might you need to know. In case you get a corrupt asset, or in case your volume fills up, there’s a Reset button, to reset the cache.


The service can be controlled from the command line as well. To start it, use the serveradmin command along with the start verb and the service name (oddly, that’s caching).

sudo /Applications/ start caching

To stop the service, use the stop verb along with the service name:

sudo /Applications/ stop caching

To see a list of settings, use the settings verb with the service name:

sudo /Applications/ settings caching

The settings are as follows, mostly available in the Server app:

caching:ReservedVolumeSpace = 25000000000
caching:CacheLimit = 350000000000
caching:ServerRoot = "/Library/Server"
caching:ServerGUID = "DEE63BBB-9F32-428B-B717-E3941F82E2DC"
caching:DataPath = "/Library/Server/Caching/Data"
caching:LocalSubnetsOnly = yes
caching:Port = 0

One setting you might choose to change is the reserved volume space, as this can keep you from getting the service started on smaller volumes. In the above example, the setting is 250 gigs. To change that to 100 gigs:

sudo /Applications/ settings caching:ReservedVolumeSpace = 10000000000

A new setting in Server 5.2 for macOS Sierra is defining other servers that can access your Caching server. This is like providing a proxy for a proxy. Basically if your devices can cache updates onto the server from other servers then the updates are caching much faster than if your server caches the updates from Apple. This is called Peering Permissions. To define Peering Permissions, click on the Edit Peering Permissions… button.


At the Caching screen, click on Only Local Subnets if you want to let the server identify which subnets are local, or Only Some Networks to define which ranges of addresses have servers that can cache content and update from your server.


Click on the plus sign to add a network and then click on “Create a new network”


At the Create A New Network screen, provide a name and then the first and last IP


Click Create and then add all of the appropriate subnets. Click OK when you’re done. Restart the service and viola, you’re finished.

September 24th, 2016

Posted In: Mac OS X Server

Tags: , , , , , , , , ,

Just got to do my first troubleshooting for the iBooks app in OS X. Wasn’t a ton of info, so went digging for the debug menu that has become a staple of so many Apple apps. And it turns out that it was there. Looking at the plist for iBooksX prefs:

defaults read

This shows that we can go ahead and deploy a key to suppress the welcome screen (nice little deployment note made there) and a few other things. But what I was looking for is that BKShowDebugMenu key

BKAlreadyDisplayedWelcomeExperience = 1;
"BKBookshelfCategoryManager~012384" = 1;
BKBookshelfViewControllerFilterAction = 5;
BKBookshelfViewControllerSortAction = 1;
BKShowDebugMenu = 0;
BKSimulateCrashDuringMigration = 0;
LibraryCountDate = "2013-11-03 03:26:26 +0000";

Let’s just turn that sucker on:

defaults write BKShowDebugMenu -boolean TRUE

And then viola, the next time iBooks opens there’s a nice little Debug menu. Here, I was able to click Migrate from iTunes again (the option in the File menu didn’t work for me) and before you know it, all the titles that didn’t migrate over the first time magically appeared.

Screen Shot 2013-10-26 at 10.27.06 PM

Hope this helps someone. Also, if you want to suppress the “welcome experience” in iBooks during deployment:

defaults write BKAlreadyDisplayedWelcomeExperience -boolean TRUE

Finally, if you’re looking for a key that you can use to verify that a computer has actually logged in with an iTunes account in iBooks (could be helpful for keying off things in scripts or whatever), note that a CachedStorefrontID key (and a couple of other cached keys) is created when iBooks accesses the store or an AppleID for the first time.

October 27th, 2013

Posted In: Mac OS X, Mass Deployment

Tags: , , , , , , , , ,

For many iOS deployment projects, iTunes is used as the primary deployment vehicle for the devices. iTunes can be used to “Backup” and “Restore” an iPad, similar to how you image desktop and laptop computers.

The actual deployment process is straight forward. First we’ll create a backup in iTunes. Then we can deploy the backup using the Restore option within iTunes. Provided the backup is encrypted, the Restore option will maintain the maximum amount of data available. For example, if a device has been activated then the fact that it has been activated is maintained across a restore. As are the applications that are installed on the device.

Create iTunes Backup

To Create an iTunes Backup:

  • Open iTunes and dock the device with the master configuration.
  • Check the box to “Encrypt local backup.”
  • At the Set Password screen, provide a password for the encrypted backup.
  • In order to ease restore, check the box for “Remember this password in my keychain (passwords are set to user names).
  • Control-click on the name of the device in the DEVICES section.
  • Click on “Back up”.
  • If prompted, click Set Password (subsequent backups will not require passwords).

Restoring with iTunes

To Restore an iTunes Backup:

  • Open iTunes and dock the device to be restored.
  • Control-click on the device.
  • Click “Restore from Backup”
  • At the “Restore From Backup” screen, select the name used in the previous backup.
  • Click Restore.
  • If prompted, enter the Password.
  • Rename the iPad once the restore process is complete.
  • Once the Restore is complete, if prompted to “Set Up Your iPad”, uncheck the Automatically sync songs and videos to my iPad box and “Automatically sync apps to my iPad”, putting the students Active Directory name in the Name field and clicking Done

August 9th, 2012

Posted In: iPhone, Mass Deployment

Tags: , , , , , , , , , , , ,