I’ve spent the last two years refining our deployment process to make it as smooth as possible. While you may not be binding your Macs anymore, this post is meant to share our current workflow to copy or modify as you see fit. If you don’t happen to bind your Macs, that’s OK too, as this post is more focused on the automatic naming process we’ve employed which occurs prior to binding.
When we were still imaging (via Jamf Imaging & NetBoot, R.I.P.), we were naming our Macs as part of selecting the applicable Jamf Imaging config. This was prone to errors, which meant having to unbind, rename the Mac, and bind it again. Unfortunately, at the time we did not realize that the account we were using to unbind the Mac did not have sufficient privileges to remove the record in AD, so we were having to manually delete the incorrect records afterward. We subsequently implemented a workflow utilizing Jamf’s Encrypted Strings to more securely provide account passwords as part of scripts with an account that had the necessary privileges.
Below is the basic structure for this part of our large deployment workflow:
- A PreStage Enrollment configuration w/ DEP Macs assigned
- A web server with a CSV file or Google Sheet containing your Mac serial #s and associated hostnames
- A post-enrollment policy activated via custom trigger to automatically set our Mac’s hostname as listed in the previous file
- A script run at the end of the previous policy to verify the hostname and trigger either a manual rename policy (if verification fails) or another series of enrollment policies
- A second post-enrollment policy activated via custom trigger to bind the automatically named Mac
Giving credit where credit is due, this workflow in large part came out of the work by and discussions with an admin at Red Hook Central Schools. Here is that resulting A to Z guide for DEP enrollments with Jamf. The DEP setup & MDM configuration process is beyond the scope of this post. Additionally, a big shoutout to @haircut for creating the rename-comp.py script that makes our automated computer naming possible!
Step 1: PreStage Enrollment Configs
Coming from an imaging deployment workflow, the static or smart configuration was the basis for determining what software was installed on a given machine. With DEP, the PreStage Enrollment configurations are the new foundational layer that everything else uses to determine whether or not settings, software, configuration profiles, etc. apply for a given machine.
Having a standard naming convention for all of your PreStage Enrollments is important. Following the Red Hook Central Schools guide, it is most effective to name these based on largest to smallest grouping. Take the examples below:
By starting the naming conventions with
Mac-, it’s very easy to configure a smart group with a scope targeting all Macs by using the ‘PreStage Enrollment Method’ criteria which contains or starts with “Mac”.
A layer deeper is the next largest grouping, which could be a mobile cart, computer lab, etc. You can target all Macs at this level by specifying PreStage Enrollment Method that contains “Mac-Lab”. Depending on your organization’s size and needs, you may only need to go one more level to define the smallest Mac grouping: the lab, cart, etc. itself. Larger organizations may benefit from specifying the school as well.
In the case of our departments, we add
Dept so we can target all departments (PreStage Enrollment Method contains “Mac-Dept”) or just individual ones. And because we have separate PreStages for each department, we’re able to configure the applicable Jamf department and location information, rather than having to achieve this via other means. In our efforts to limit the overall length of these names, we’ve opted to include the division abbreviation in the smallest Mac grouping. Several examples are listed below:
Initially, it might not be immediately obvious why breaking your Mac groupings down to this granular level is worth the extra effort. In my experience it has avoided having to make major structural changes later in order to properly scope policies, software, printers, etc. However, it does mean that if you are repurposing Macs you have to be especially conscientious about what PreStage Enrollment a Mac is assigned to.
The only frustration I have with this process is the fact that Jamf does not let you reassign devices to a different PreStage Enrollment without first removing the device from its currently assigned PreStage. As a result, you either have to go to the device record or the DEP settings to access the currently assigned PreStage, remove it, and then navigate to the new PreStage and add it. There is likely room to script this process, but I also wish Jamf did not require this extra step.
Step 2: Web server with a CSV OR Google Sheet
Assuming you are using your Jamf Distribution Point for HTTP/S or munki which requires a web server to host packages, you already have the necessary mechanism in place for directing endpoints to a file with a list of serial numbers and hostnames. While there are certainly security concerns about having a single file with all your Mac serial numbers, there are well documented ways to ensure only your approved endpoints can access your local or remote web server.
While there is definitely a convenience factor using a Google Sheet for this instead, using a CSV on a web server means you can put it into a git repo and incorporate it into your change control processes.
For instructions on configuring this file – either as a CSV or a Google Sheet -, please refer to this blog post.
While the rename-comp.py script only utilizes the first two columns in the CSV or Google Sheet, we use subsequent columns to input additional notes like when Macs are decommissioned or not currently assigned to a user.
Step 3 & 4: Post Enrollment Naming Policy & Scripts
Add the rename-comp.py script to your Jamf scripts (per the previously referenced blog post). No changes need to be made to it, as the script assumes use with Jamf assigning the CSV or Google Sheet URL to parameter 4. However, you can change the default download location defined by the
CSV variable, if you wish (
Be aware that rename-comp.py uses the Python
urllib2 module, which does not exist in Python 3. As a result, changes will need to be made to this script if Apple decides to remove the now deprecated built-in Python 2.
While you can incorporate the script into a separate policy, we include this in our initial enrollment policy that all our Macs run which in turn triggers other enrollment policies. If you’re still binding your Macs, this triggering of another policy once the hostname has been changed is essential. If you include the bind setting in the same policy as your rename-comp.py script, the newly set hostname will not be used, as the hostname is only collected on initial policy run.
Because we’re human, it’s very possible that the configured CSV or Google Sheet may not contain a given machine’s serial number and/or hostname. It’s also possible that some unknown error occurs that prevents the script from grabbing your CSV file or accessing the Google Sheet. For my previous environment, this step was very important as the Mac’s hostname needed to match what was listed in AD in order to achieve Windows-like machine authentication (see this blog post for more info on that configuration).
To address these scenarios, at the very end of our initial enrollment policy we run a script which does several things:
- It checks that the file downloaded by rename-comp.py is where it was cached previously. If not, it redownloads it (if able).
- It verifies the hostname found for the Mac’s serial number in the file matches the machine’s current hostname.
- If the hostnames match, trigger the next enrollment policy via custom trigger (ex.
jamf policy -event <trigger>) to bind and finish provisioning.
- If the hostname does not match – either because the file couldn’t be downloaded, the Mac’s serial number wasn’t listed, or just don’t match what’s listed in the file -, this instead triggers a different standalone policy that presents the technician with a prompt to enter the hostname manually. Once a hostname is entered, so long as the policy does not produce a non-zero exit code it triggers the next enrollment policy just like if a hostname match had occurred to finish provisioning.
In this way, we verify the automated hostname is what we expect before we proceed other provisioning tasks, including binding the machine. Should something go wrong, we can manually remediate without having to stop the provisioning process for the Mac and fix the list later.
Below is the script we use in our standalone rename Mac policy:
Step 5: Post Enrollment Bind & Other Policies
Once the Mac has been named correctly, our subsequent bind and other enrollment policies automatically run and when completed begins the software installation process.
Reflection & Looking Ahead
The addition of automated computer naming to our DEP deployment workflow has resulted in an entirely hands-off provisioning process and removed the previous potential for error when completed by hand. The only piece in the entire process that is not hands-off is setting our unattended TeamViewer Host module password and assigning it to our organization account (discussed in a previous post). TeamViewer simply doesn’t supported this (that is unless you have a Corporate license and are deploying on Windows machines).
If you wanted to go a step further with this hostname automation, you might configure your Jamf instance to trigger a webhook when a machine was added to DEP which in turn triggered another process to take the serial number from the webhook event and add it to your CSV or Google Sheet. This would avoid having to manually enter new machine serial numbers to your file. Depending on your naming scheme, you may also be able to automate the associated hostname as well. At the moment though, this process works well enough.
If you found this post helpful, give it a like. Otherwise, post your questions and comments below.