Category: Mac OS X

Occasionally the Caching service on macOS will stop working due to a network outage or a glitch on Apple’s end.

It’s a simple enough fix — all you have to do is turn the service off and on again. But how do you know that it’s offline? It’s easy if you use MunkiReport with the Caching module enabled.

Just save the code below as a script on your MunkiReport database server and set it up as an hourly cron job. It looks for caching activity reported in the last two hours, and kicks off an alert if no results are found. (Be sure to read the notes below.)

#!/bin/bash

cachingactivity=`/bin/mysql munkireport -e "select \
collectiondate from caching where collectiondate > \
timestampadd(hour, +6, now()) order by \
collectiondate desc;"`;

if [[ $cachingactivity == "" ]]; then
     echo "Caching service may be offline."
fi

Considerations:

• The user who runs the script needs to have a MySQL credential stored in their .my.cnf file.
• Make sure cron is able to send you alerts. (Working MTA, and MAILTO=”user@domain” appears before this job is listed.)
• You may need to modify the timezone offset (+6) to something suitable for your location. I’m at UTC-8, so +6 means my script looks for caching server activity reported within the last two hours.
• Depending on how many clients there are, and whether any of them are on 24/7, you may need to adjust how far back your cron job is looking for records to avoid false error reports. Or only schedule it to check weekdays but not weekends.
• Obviously this doesn’t provide up-to-the-minute alerting, but it should still help you notice if something is wrong before anyone else does.
• With multiple caching servers, one could go down and you would not be alerted. The true purpose of this script is make sure that the caching service is working somewhere. It’s not concerned about calling out individual servers.

If you have Macs that were cloned from an already-activated system (either via monolithic imaging, or one-off machines that were migrated or experienced hardware failure) you will find that your Office 2016 activation is broken. You will also find that Munki doesn’t know it needs to re-run the Office 2016 serializer since a receipt already exists for it.

I was able to work around this by adding a couple scripts to the serializer’s pkgsinfo. First I added an installcheck_script that looks for a file in /Users/Shared which contains the serial of the computer on which Office was activated. If it doesn’t match the computer’s serial, or if it doesn’t exist, then the serializer package will run. Then we use a postinstall_script to write the serial number of the current computer to this file so we know it’s been activated on this machine and doesn’t need to run again.

installcheck_script:

#!/bin/bash

machineserial=`system_profiler SPHardwareDataType | awk '/Serial/ {print $4}'`

activatedserial=`cat /Users/Shared/.office2016activatedserial`

if [[ $machineserial == $activatedserial ]]; then

exit 1

fi

postinstall_script:

#!/bin/bash

system_profiler SPHardwareDataType | awk '/Serial/ {print $4}' > /Users/Shared/.office2016activatedserial