The biggest pain with configuration profiles is the fact you push the Ok button in your MDM of choice and the wretched things deploy (almost) immediately. All fine and good you may think, some users report a problem, you change a profile and hey presto! Right?

But what if you need profiles to deploy at a specific time or condition? Say, for example after your initial deployment process has completed. Say also that you have a deployment wifi and a corporate wifi, swapping from one to the other breaks things and if that happens in the middle of your deployment? Yeah that’s red face time.

You could use Tim Sutton’s wonderful tool Make Profile Pkg and deploy a pkg manually. I do like this tool for things that are static, but wifi tends not to be. Plus with the rumblings and rumours of future OS lockdown by Apple it makes sense to keep this as MDM oriented as possible.

I worked out a way of doing this for Jamf. The principles could be directly transferred to other MDM systems and i’ll leave that as an exercise to you all. The basic process goes something like this:

Deployment Process
First Boot
User Login
something happens here …
…
PROFIT!

Now let’s translate that into something more technical :p In my example i’m using the following tools: Jamf Pro, Joseph Chilcote’s outset tool and some custom bash of my own devising.

1. A script that runs after deployment process (in my case first user login) creates a zero byte file on a reserved part of the hard disk.
2. A Jamf extension attribute checks for the presence of this file and reports back “yes” or “no”.
3. A Jamf smart group reports on what devices have reported back “yes”.
4. Configuration profiles are deployed only to members of that smart group.

I use outset rather than create individual launchagents and daemons. It’s very handy and I use it exclusively for the stuff I want to run regardless of whether the device can contact Jamf or not. This is a good case for using it.

Outset v2.0.5 (which is what i’m using) has the ability to run scripts at login with privileges, which somes in handy for some of the things I want to do. The script itself has to run, check if it can connect to the JSS (pausing if not), write the check file and run a jamf recon to update the computer inventory record. And it looks like this:

#!/bin/bash

# Script to let JSS know that it's ok to install WiFi configuration profiles

# Where is the Jamf binary?
jb=$( /usr/bin/which jamf )

if [[ "$jb" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ ! -e "/usr/local/bin/jamf" ]];
then
   jb="/usr/sbin/jamf"
elif [[ "$jamf_binary" == "" ]] && [[ ! -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]];
then
   jb="/usr/local/bin/jamf"
elif [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]];
then
   jb="/usr/local/bin/jamf"
fi

# What's the JSS url?
jss_url=$( /usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url )

# Checking to make sure the JSS is available before proceeding
until [ "$check" = "TRUE" ]
do
   if [ $( curl -sqk ${jss_url}healthCheck.html ) = "[]" ];
   then
      check="TRUE"
   else
      sleep 10
   fi
done

# Create the flag file to be picked up by the EA later
touch /path/to/eadata/wifiready

# Tell jamf binary to recon, thus triggering the EA and scoped profiles.
$jb recon

I have pkgs that deploy outset, then the scripts. I popped that into my login scripts and made sure it deployed ok.

Now let’s start with the Jamf stuff. We are going to need a custom extension attribute and code and a smart group. Let’s start with the EA. Create one, set it to run a script and feed it this:

[cc lang=”bash”]
#!/bin/bash
# EA to check for wifi profile flag file

if [ -f “/path/to/eadata/wifiready” ];
then
echo “Ready”
else
echo “Not Ready”
fi
[/cc]

That’s a simple condition that we can easily check for with a smart group. What does the smart group look like? Glad you asked!

Pretty simple huh? It doesn’t need to be complicated, just to detect if the file is present or not. Now you just create your configuration profile as normal, but scope to that smart group plus any others you may require. For wifi profiles, I also scope an exclusion for virtual machines because they usually don’t have wifi adaptors and that makes the profile deployment cry.

Now you’re taking advantage of profile deployment’s immediate nature, but at a time of your choosing. Enjoy!