Don’t have permission to create a file in Whitebox Packages.app?

If you get an error that you cannot create a file inside a folder when building in Whitebox Packages, take a look at where the original file is located.

If the file is located within your user folder, you might check and see if you’ve given permission to your ~/Documents or ~/Downloads folder. Or perhaps you’ve given Full Disk Access even.

Somehow, even with these permission set I continue to get this error. I am currently running Big Sur 11.2 and Packages 1.2.9, current as of this writing. I have found that a good workaround is to stage the files I am using in my package in the /Users/Shared folder. The permissions are more open in that folder as its intended for multiple users to access. If I shift the location of the files to be used into that folder I can successfully build.

From Hands-on to Zero Touch (JNUC2020)

Hi folks! If you’ve found your way here for more detailed information from my session at JNUC 2020, From Hands-on to Zero Touch, welcome! I’ve detailed the steps here outlining the process that took us to being able to support zero touch when suddenly everyone was remote.

Initially we were using DeployStudio to image our Macs. The workflow was to erase the machine and push down static image known as a Gold Master. DeployStudio worked with netboot, which is no longer available as an option on new Macs. It was also able to install packages, and truthfully we were installing many items from packages for multiple workflows. Most of you know that this is no longer the preferred method, and hasn’t been for some time due to changes in Apple’s security and macOS. We initially were modifying the Default User Template and found that certain things were no longer working when customized. We started seeing permissions issues crop up, and with certain updates machines weren’t getting firmware updates.

One of the biggest reasons to move was the changes with User Approved Kernel Extension Loading (UAKEL) and User Approved Mobile Device Management (UAMDM). These two settings specifically require approval at each machine unless you enroll with DEP/ADE. We migrated to using Jamf Imaging, which was similar in some ways. We wiped the drive, but used a blank OS image created with AutoDMG and installed all applications and settings individually with packages. This was an important setup step to allow us to more easily move to a Device Enrollment Program, or DEP, (now known as Apple Device Enrollment or ADE) workflow. By having a workflow with packages we were able to migrate and test easily a new automated workflow.

But this spring, suddenly everyone was remote. We still had new employees starting who needed computers. I made sure our package repository was available in the cloud by replicating our on-prem repo to Jamf cloud. I ensured that new users would have NoMAD and VPN installed to make sure they could access network resources and sync their password to their AD credentials even when off campus.

Here’s a short list of the major steps needed to make sure we were ready to deploy zero touch:

  • Sign up for Apple’s Device Enrollment
  • Ensure our JSS and package repo is available off campus
  • Configure Prestage Enrollment
  • Utilize Inventory Preload
  • Configure setup with DEPNotify and DEPNotifyStarter.sh
  • Use NoMAD to sync a local password with the user’s AD password
  • A backup plan in Self Service in case our DEPNotify workflow doesn’t start because of the enrollmentComplete trigger failing

And here is a list of important tools I used in the process:

  • DEPNotify: a great utility to make it look nice while installing your standard software
  • DEPNotify-Starter: A bash script you can customize to run an array of policies and display output to DEPNotify
  • NoMAD: An alternative to binding to AD, allows a local user account maintain a kerberos ticket and sync your password with an AD account password.
  • Outset: A utility that allows scripts to be run at various times, login or boot and with options for running once or every time. Useful to set some specific user settings without modifying the user template.
  • Dockutil: Allows for modification of the dock using a script.
  • Desktoppr: Allows changing the user’s desktop background without asking for additional permissions as osascript does.
  • Whitebox Packages: A GUI application to build package installers. Alternately, you can use Jamf’s Composer.
  • Profile Creator: A GUI application to build granular profiles and optionally sign them.
  • the MUT: This is a GUI tool for uploading information to Jamf using the API. Allows you to move devices between different Prestage enrollments, update device inventory information and clearing inventory or EA data for specific machines.
  • Jamf API: scripts written using this to grab inventory data to customize the system

Signing Up for Apple’s Device Enrollment

Setting up an account on Apple School Manager or Apple Business Manager is the first step. I found it to be generally stress free. A simple form to fill out, followed by a call to my boss to verify things. Once enrolled, I was able to link our Apple Customer Number to the account and import all our purchases to assign to our Jamf Pro instance.

A fairly simple form to fill out

Apple Business Manager and Apple School Manager recently changed their interface, but I initially was able to upload and assign machines using a csv exported from my inventory system.

Ensuring Jamf is Available Everywhere

We had migrated to Jamf Cloud some time ago already, but were still using a local package repository. I was able to take that repository and replicate it to our cloud storage and set that cloud storage as our main repository. While time consuming, it worked eventually. I just had to ensure my machine did not fall asleep during that initial replication, for this I used the caffeinate command.

Just one button to click in Jamf Admin

I followed this with keeping our on campus distribution, and and I created a Network Segment to direct traffic to the local package repository. I also found that you cannot immediately replicate a package you’ve uploaded, and you must wait for a short while before a cloud package can be replicated.

Network segment for on campus addresses directed to the on campus server.

Configure Prestage Enrollment

There are a few things to keep in mind here, if you apply a profile at this point you’ll need the machine to still be in scope. If you deploy a package with prestage enrollment you initially needed a cloud repository as your main, and it needs to be signed. This has since been amended to allow on-prem to host a prestage package, but this could be problematic if a machine is powered on and connected off campus.

There are customizations you can make to the setup assistant like skipping options, or adding profiles and packages.

Skipping options to speed up setup.

Utilize Inventory Preload

First you’ll need to make sure you have Buildings and Departments populated. This can be done manually, or with an API script to upload. I use these to scope specialized software and printers based on location or department (as some departments may be in more than one building on campus). You will get an error if you try to use a building or department that does not yet exist.

There are many fields available for Inventory Preload

Once the file is prepared you can upload it, in the settings area. After uploading you can view your data.

Your view will include the fields you choose, but this is a good way to verify your data.

Configure setup with DEPNotify and DEPNotify-Starter

I configured DEPNotify with a series of policies to install software scoped to all machines, or some to just specific departments or buildings.

Most importantly here is making sure you have policies for all the software and user customization you will apply. I deploy outset, dockutil and desktoppr and scripts utilizing them with the outset logon-once folder so they run once to create a basic setup for each user. Edit: here is a post with some sample scripts to set user settings with outset, dockutil and desktoppr.

Policies sorted with a name for DEP and a trigger with DEP to make it easier to see

The main customization with DEPNotify-Starter was to create my own array of policies and display text. I have one version of this script and each policy is scoped based on things like the department and building that we set in inventory preload.

Array of policies with custom triggers, and display text for DEPNotify

I also deploy software for things like security, our basic applications like web browsers and Microsoft office. I have multiple policies so they can be scoped as needed to departments, academic facilities, or specific labs. I utilize the Jamf API with scripts to customize, as detailed here. These API scripts are one of the reasons I use inventory preload, I can assign a machine to a user based on the serial number and use it to set up with the appropriate building and department.

Use NoMAD to sync a local password with the user’s AD password

Fairly straightforward here, we push NoMAD, the launch daemon and a profile to configure the software. Once the user’s account is configured, if they are on campus they can log in and sync their password. If they are off campus, they can do the same once they log in via VPN.

Profile Creator has presets for NoMAD to create profiles you can upload to Jamf.

A backup plan in Self Service

A custom trigger on the DEPNotify-Starter policy allows me to set it in Self Service to kick off in case the enrollmentComplete trigger doesn’t work for some reason.

Using the jamfEvent script I detailed here.
Configured to display in Self Service

Hopefully this clears up some of the steps required to pivot to a modern deployment workflow that is compatible with zero touch.

Setting up FileVault with a Self Service button

Using some of the scripts I’ve mentioned I created a policy to enable FileVault encryption with a button in Self Service. In macOS 10.15 Catalina a new feature called the Bootstrap Token was introduced, which gives a newly created AD mobile account Secure Token access delivered from the MDM. This gives permissions to enable FileVault without a user who initially set up the computer standing over someone’s shoulder to input a password.

The policy is set up in a few parts. There is a one policy to enable encryption, a static group to which that policy is scoped, a profile to lock the FileVault pane in System Preferences, and a Self Service policy to kick it off.

The Self Service policy itself is simple. First it adds the computer to the static group, then it runs the the encryption policy by its custom trigger. The profile to lock the FileVault pane in System Preferences scoped to the static group.

This method does require a user to log out and then log back in for it to enable encryption, but with new T2 based systems the encryption is instant. Newer pre-T2 systems on SSD are pretty quick as well.

Installing with choices.xml

Some application installers have a lot of options or install additional software you may not use. You can create a choices XML file and customize the installer in many cases. Unfortunately, Jamf Pro does not natively support using a choices.XML file. There are a few ways to go about distributing software using one with Jamf Pro. You can repackage the software and run the install with a post install script

installWithChoices.sh assumes that you have cached the installer and a completed choices XML file to a staging location, in this case /Library/Management/ and runs the installer with the options, then deletes the cached files. The variables used are for the package name and the choices XML file name.

installer -applyChoiceChangesXML "/Library/Management/${choicesName}" -pkg "/Library/Management/${pkgName}" -target /

rm -rf "/Library/Management/${choicesName}"
rm -rf "/Library/Management/${pkgName}"

I deploy both Office and Cisco AnyConnect VPN and modify the installation as we do not utilize all the applications included. The reason this works for me is I can create a policy to cache the Office or AnyConnect installer and a separate choices XML to install only the required applications at the time. I may have a group that wants Outlook, while most installs do not, or a group requesting OneNote. Having one package for the installer for Office that is kept up to date and can be installed with the required options lets me create multiple policies that can reference a single installer that I can keep up to date without needing to update multiple policies.