Working in end-user device management, focusing on onboarding, configuration, security, and updates, is easy. After all, getting everyone working is critical! But what happens at the end of a school year or employment contract? What about managing the sudden departure of a staff member or student with a BYO device? Do you have an end-user device offboarding process in place? Do you have licensed software to recover? Configurations to remove and permissions to reset or restore? What about the removal of the framework itself? In this article, I’ll guide you through the basics to complete these tasks and let those devices go with comfort and ease and, most importantly, satisfied end users.
In most circumstances, our users initiate device offboarding via Self Service. The policy becomes available when their computer record is scoped to our voluntary offboarding department. All institutionally licensed software and configurations are removed. Local student user accounts are elevated back to administrator from standard permissions. Configuration profiles and HelpDesk services accounts are removed, and the Jamf Pro computer record is deleted. Users are left with some chosen software titles they can continue to utilize freely or otherwise acquire personal licenses for (e.g. Adobe Creative Cloud).
There are many ways to accomplish this task, and this is one way to do so. It works and is simple enough. This will get you there if you don’t already have a good process. If you do, maybe I can give you an idea to improve yours. With any luck, a great discussion could ensue, and we all learn more!
Planning
What’s been done should be undone, mostly. More specifically, you should have a specific plan for offboarding. After all, you can’t remove it if you forget about it. Make a list of the following items installed during the onboarding and a list that your users or subgroup of users may be able to add optionally via Self Service, departmental deployment, or some other method.
- Added accounts
- Adjusted account privileges
- Configuration Profiles
- Institutionally licensed software
- Launch Agents/Daemons
- Legacy items… What did we forget that we might have let the user install a long time ago?
- MAS (Mac App Store installs)
- Optional/free software
- Specialty tweaks (modifying OS defaults, etc.)
Once you have those listed, we can review and create our offboarding policy. This is an excellent time to know if you will leave some software or institutional tweaks. For example, Adobe Creative Cloud and other Adobe products are licensed through our user's Google accounts. Once their Google accounts are deactivated, their license is removed and remediated. Leaving the software installed allows them to use a new login from their college/university or purchase a license while maintaining user preferences.
Preparation
Local User Account Permissions (if modified):
A new BYO Apple user will begin onboarding as a full local admin user with a secure token. Student user accounts are demoted to “standard” accounts during enrollment, and our Jamf management account and a HelpDesk access account are added. Because the original secure token user gets set to standard-level privileges, it must be elevated back to admin before modifying IT’s access or removing our accounts. Suppose we were to fully offboard a machine before returning admin access to the original secure token-enabled account; In that case, the user would inevitably need to wipe and restore the laptop to regain administrative access. I prefer to do this early in the offboarding process before running the rest of our uninstallers. If a user has an offboarding issue offsite, it is generally easier to help them finish the process if they have admin access.
Launch Agents/Daemons:
Launch Agents or Launch Daemons are typically unloaded and removed when utilizing a supported uninstaller provided by the software’s creator. You shouldn't have to worry too much, whether it’s an uninstaller package or a local uninstaller that you call using a bash command. Just be sure to test your uninstallers and ensure they work as expected. If you’ve added Launch Agents or Daemons, or if the provided uninstallers are insufficient, you may need to unload and remove them separately before uninstalling the associated software.
In our case, we installed a single Launch Agent for our users to keep the uniFlow Cloud Printing Agent running in all circumstances. Since the provided uninstaller doesn’t expect this to exist, it won’t attempt to unload and remove it. To resolve this, we’ve built an “empty” package in Composer and added a “preinstall” bash script that unloads and removes the LaunchAgent. Afterward, we can run the supported uninstaller to complete the removal.
Uninstallers:
With any luck, you already have a method for uninstalling each application that is not supposed to leave with your user. If you don’t, you must find a method for each. I find that it’s easier to maintain separate uninstallers as packages or scripts to call when needed. These could be:
- Official uninstaller apps or packages
- Official uninstaller script(s)
- Custom-made scripts or packages
- A .pkg or .dmg that has been indexed with Jamf Admin
- Other methods
I’ll avoid going into deep detail about how to create various specific uninstallers. I prefer to use official uninstaller packages whenever I can get them. These can be quickly and easily uploaded and added to a Jamf Pro policy. Otherwise we have to come up with another process. Perhaps the software’s author has a supported removal process or script. For anything less obvious, there may be a need to do a bit of research or consult our fellow IT admins.
Remove Configuration Profiles:
When we remove the Jamf Framework, any profiles installed via your Jamf Pro instance should be removed. Yet, I’ve heard of a few folks who have experienced a few misses in the past, so we script the removal of all configuration profiles. Since we clear all previous configuration profiles during onboarding, we know we don’t have to worry about leaving any behind. You can individually remove profiles rather than wipe them all clean if necessary. Your circumstances and needs will be unique to your deployment.
Remove additional accounts:
If you’ve added any local service accounts (whatever the reason), they will also need to be removed. This is very easy to add to a Jamf Pro policy or a script.
Scripting the rest:
I’ll admit that my scripting skills are not the strongest. I try not to rely on unique, personally written scripts. I keep it simple or find more professionally developed, tested, and community-supported scripts. The good news is that this final script is pretty basic, though it accomplishes a few critically important tasks. Your script should be loaded into the /tmp directory early in the process and called at the end of the policy process using the Execute Command function of the Files and Processes section of the offboarding policy. This way, the Jamf components can be removed without interrupting the process, and the /tmp directory will be cleared during the reboot. Since almost all customizations are now handled by Configuration Profiles, the script has become very simple. I will call it the “finalization script,” and it accomplishes the following tasks:
- Clean up empty directories left over by other uninstallers
- Reset the legacy software update ignore list
- Remove or adjust the Jamf device record
- Quit Self Service
- Remove the Jamf Framework (This is critical). It’s not tricky. Just run this command:
- /usr/local/jamf/bin/jamf -removeFramework
- Remove legacy support accounts
- Remove all remaining configuration profiles
- Reboot the device
Let’s put it all together!
- Create a policy for this offboarding/unenrollment. We’ve coined the term “De-Brewsterization” for our process.
- Set the frequency to Once per computer, and check the box to Automatically re-run policy on failure.
- Add items you need to install before offboarding, such as the finalization script I’ve mentioned above.
- This .pkg deploys the finalization script into the /tmp directory for later use.
- Add any uninstaller packages to the policy. Make sure you have Install selected.
- Add packages or you’ve indexed for removal after uploading in Jamf Admin. Add them to the Packages category of the policy, and make sure you have Uninstall selected.
- Add any scripted uninstallers. Be sure to set Before and After as appropriate.
- In this case, the script promotes the logged-in user to admin. It is set to run Before the other items in the policy. We have another script set to run After the other items in the policy. That script calls the supported uniFlow smart client uninstaller, which needs to run after we unload the Launch Agent.
- Remove additional service accounts. Add these to the Local Accounts section of the policy, making sure to select Delete Account and Permanently delete home directory along with the Username. Do this for as many additional accounts as you need.
- Call the finalization script by adding the path to the script in the Execute Command function in Files and Processes.
- Set your scope.
- Here we set our scope to a department explicitly created for offboarding students. In this instance, “Students-to-De-Brewsterize” and “Students-to-De-Brewsterize-DEPARTED.” This lets us control what machines can offboard and when simply by setting their department.
- Add your Self Service settings as desired, then save and test the policy.
- After testing, we clone this policy, remove the Self Service information, and set the trigger to Recurring Check-in with a frequency of Once per computer, then check the box to Automatically re-run policy on failure. This will only be scoped to the “Students-to-De-Brewsterize-DEPARTED” department. Devices that need to have offboarding automatically enforced are set to this department.
Closing
And there you have it. Two policies allowing for both Self Service and automatic offboarding. The process is clean and straightforward for the user. Self Service just runs a policy as usual, and then the machine reboots fully separated from licensing, configurations, and management. Users who miss the period for voluntary offboarding are provided several on-screen notifications before the automated policy is enabled.
I’m experimenting with some tools for better user interaction. Perhaps a method allowing them to select software or configurations they’d prefer to keep or license post-offboarding. I’m rebuilding our onboarding process using (Setup Your Mac) from @dan-snelson . I can also see using it for offboarding, but I haven’t put any time into it yet. Fortunately, it would continue to utilize the uninstallers and other items already gathered here. We could also initiate the offboarding policies using something like S.U.P.E.R.M.A.N..
Here’s to happy offboarding!
3 Comments