So far a framework to build and bring into Jamf has been created but who wants to keep manually wiping devices to reprovision them?
The reprovisioning process can be automated to deploy the correct, DEP or Non DEP, workflow from Jamf. A few extra components are required for this which are detailed here.
this process uses Graham Pugh's Erase-install script. This is used to download and maintain a local copy of the macOS installer and to wipe the device to reprovision it when required.
As mentioned in Non DEP Start the same options can be used with this script meaning the DEP and Non DEP process can be also driven entirely from Jamf with a few additional components.
How this is used is explained later.
Two new EAs are required.
The first is an Installer Valid EA. This is based upon a part of the install-erase script and is used to determine whether the installer is required to be downloaded. This is decided by whether the installer is;
- Downloaded or not.
- A valid version - Greater or equal to the installed OS version.
The EA is available here. In Jamf create an Ea of String and type as script
The second determines whether the devoce is capable of using DEP. This is critical to scoping in the process. This is a simple EA using the profiles command;
#!/bin/bash
# set default answer to "no". only want to set to "yes" if it's true
result="no"
# use profiles to see if the device is in Apple. if it is 1 is returned, if not 0
configURL=$(profiles show -type enrollment | grep ConfigurationURL | grep -c http)
if [ "$configURL" = "1" ]; then
result="yes"
fi
echo "<result>$result</result>"and is available here
A package is required for the workflow. This is a single package containing the two packages used in Non DEP workflow. A single package is made to deploy them only. They do NOT get installed untill the device wipe is initiated.
The path used to deploy the packages to is the default path the erase-install script uses, this can be modified if required.
This process requires four smart groups to control the policies.
The first smart group controls if the installer download is required, this is based upon the installer-valid EA above.
In the example macOS of 10.13.4 is used to scope out non --eraseinstall capable devices, if there are non APFS devices with 10.13.4 then scope these out as well.
The second smart group controls whether the extras package is required on the device because it is a Non DEP machine.
It uses the state of the installer valid and the DEP Capable EA to determine whether it is required.
There are two Erase Ready groups required.
One for the DEP devices;
One for the Non DEP devices;
These are used to scope the Erase policy when all pre-requisite items are in place.
This process allows for Non DEP devices to be moved into DEP This can happen when taking over a fleet that has been purchased from many sources and arranging with the vendors to add those devices into DEP when they hadn't been originally.
If this is happens the deploying the extras package will end up with the non DEP workflow being deployed to DEP devices. To prevent this a final smart group is required;
This looks for devices that have the Extras package downloaded but are DEP capable.
Now the smart groups are ready the policies can be built to deploy the mechanism.
Irrespective of the workflow only one macOS installer download policy is required.
This is scoped to the Download required group. It runs the erase-install script and can be OS version locked if required.
Because of the way the EA and smart group are set up this policy will always ensure a valid installer is downloaded to the device.
The extras package is deployed to members of the extras package required smart group, i.e. the Non DEP capable devices.
The remove Extras policy is used to remove the Extras package if a device moves from Non DEP to DEP.
It runs a simple script to delete the package and the Jamf receipt;
#!/bin/bash/
# removes the extras files required for non dep builds if a device becomes dep ready
rm -Rf /Library/Management/erase-install/extras
rm -f "/Library/Application Support/JAMF/Receipts/jnuc_erase_install_extras.pkg"Then runs an inventory to update all the groups
The final policy is the Erase Policy. This could actually be several policies or one policy with differing methods of calling it, Self Service, policy trigger from jamf binary, timed policy push etc.
This policy is scoped to the Erase Ready groups.
This framework provides the basics for a Jamf policy driven reprovisioning method. Extra workflows can be added into the method easily.
If all devcies are already in Jamf then the initial wipe may not be needed and the method can be applied directly onto the devices for use next time they require reprovisioning.