CS6 Installers

Since we moved to smb shares, we have started wrappering our AAMEE .pkg installers in dmgs and then using a script to extract the pkg and install it. This is/was a mess so I decided to test leveraging casper's caching mechanics to just 'cache' the contents of the dmg to the Waiting Room an let the jamf binary take it from there. 1) Allow Composer to index the JAMF application support folder. 2) Monitor the file system using Composer. 3) Touch the Waiting Room folder or cache something innocuous to make the folder and then stop monitoring. 4) Copy your installers into the folder and make DMGs one at a time. 5) Add the dmg to your Imaging configurations. 6) Add a one liner to install all cached packages at first boot. (sudo jamf installAllCached or something more specific for the pkg) This should prevent any JSS connectivity issues after imaging where your firstrun cannot call a policy to install cause is cannot see the JSS yet.

Version Control

Updating our update infrastructure. Currently things are pretty dumb, run system updates -> restart. The new system will take into account user authorization and will check for other updates to run: Browsers, Java, Flash, Adobe, System. I want to make sure that any update installer I push out doesn't clobber a newer version or bother trying to reinstall the same version again. The rough cut is a simple preflight script for each of the applications we are trying to push out.

#!/bin/bash
## preflight
##
## Not supported for flat packages
#these are set by JAMF Composer
pathToScript=$0
pathToPackage=$1
targetLocation=$2
targetVolume=$3

applicationName="Example.app"

currentVersion=$(defaults read '/Applications/'$applicationName'/Contents/Info.plist' CFBundleShortVersionString | awk -F'\.' '{print $1}')
upgradeVersion="20"

if [ "$currentVersion" -ge "$upgradeVersion" ]; then
    echo "Already at or above installer version" 1>&2
    exit 1
fi

exit 0
exit 1 This will fail out the installer if their browser version is already at or past the version of the upgrade.

JSS LDAP

While I was doing some internal housekeeping, it became apparent that information was not being synced to our JSS from our ldap server, even through the sync was working. After building a system to query our ldap server for a user that is assigned to a computer and submit the whole shebang to the JSS, I realized that you have to be explicit with the -ldapServerID flag on any recon commands for it to poll ldap.


      sudo jamf recon -ldapServerID #

I assume the # is the number of the ldap look up server you want this computer to use when looking the username user up, in display order. That assume is there because I am only using one ldap server at the moment.

MDM Profiles

Here is a simple but useful command for the jamf binary.

       sudo jamf mdmenroll

This will force a new mdm enrollment request from the JSS, removing the old MDM profile and any profiles installed, installing a new MDM profile, and pushing new Configuration Profiles. This is useful as it won't enforce the rest of the management framework, meaning policy won't keep profiles from being installed.

From what I can tell, this is wrappered into the jamf recon and jamf enroll commands. I think it is probably part of a management call that goes something like mcx, policy, mdmenroll, making profiles wait for everything else and/or removing them every other time the policy runs. It appears that having an enroll call removes management if there was management in place before.

If you have a policy that is filling the last user on a machine with jamf recon -endUser or something similar, add a -noManage flag to the policy so that you don't have to redo the mdmenroll. There will probably updates or follow ups on this topic as time goes on.