This project assists with migrating from one JSS to another JSS. I will describe the setup process and logic of the script below.
I've added an additional workflow to this project to include some kind of option for 'migrating' FileVault keys to the new JSS.
The overall scope of this project is to:
- Mark the computer in the old Jamf environment as “unmanaged” – so you can easily track what has, and has not, migrated
- Remove the old Jamf Framework – which removes the main MDM Profile and all traces of Jamf related Config Profiles, MDM certs, etc
- Join computer to the new Jamf environment in a clean state
- Reissue a new FileVault Personal Recovery Key (requires a known FileVault Unlock Key)
In my testing, the overall process took, from policy execution to the script completing, roughly one minute and fifteen seconds.
Inspired by several discussions on JamfNation:
- https://www.jamf.com/jamf-nation/discussions/10866/un-manage-and-keep-in-inventory
- https://www.jamf.com/jamf-nation/discussions/10456/remove-framework-after-imaging
- And several other threads I've read regarding Jamf managed state recovery methods (See: rtrouton's CasperCheck)
Edit the jamfMigrator.sh
script and modify the following values:
newJSS
oldJSS
jamfAPIUser
jamfAPIPassword
- If you change the LaunchDaemon file and Label names, you'll need to update those in all files as well
- If your JSS has a self signed cert, you may need to add
-k
(--insecure
) to thecurl
command to disable SSL verification
API Permissions I needed were:
- JSS Objects > Update >
- Computers
- Users
Create a payload-free package with all three files and a QuickAdd package created for the new JSS instance
- If using
munkipkg
, add all files into the scripts folder - If using Packages, add the
postinstall.sh
script as the Post-installation script and all other files into Scripts > Additional Resources
Grab the reissue_FileVaultPRK.sh
script here
Upload these items:
jamfMigrator.pkg
to the old JSSreissue_FileVaultPRK.sh
to the new JSS
Create the following Policies:
- In the Old JSS
- (If needed) Policy to Create a FileVault Enabled User. Example
- Policy to deploy the
jamfMigrator.pkg
Package
- In the New JSS
- Policy with the
reissue_FileVaultPRK.sh
with a known FileVault Unlock Key. Example
- Policy with the
This script does the heavy lifting.
- Checks if it can contact the old JSS (uses
jamf checkJSSConnection
)- If successful, continues
- If an unsuccessful attempt to connect to the old JSS, quit and try again on the next interval
- Sends a generated xml file to the old JSS, via the API, to mark the machine as unmanaged
- The UUID is grabbed from the machine to associate it to its' Jamf Record
- Jamf Framework is removed
- QuickAdd package for the new JSS is installed
- Checks if it can contact the new JSS (uses
jamf checkJSSConnection
)- If successful, continues
- If unsuccessful
- If still attempting to connect to the old JSS, quit and try again on the next interval
- If it attempts to connect to the new JSS, but fails, quit and try again on the next interval
- Begins 'tearDown' -- cleans up all staged bits
After virtually every action, the Exit Code ($?
) is checked to see if it was successful; if it isn't, the script exists and will be launched again at the next interval.
Logs each process step to system.log
This is the LaunchDaemon that staged and loaded by the postinstall.sh
script.
- On load, the LaunchDaemon will execute the
jamfMigrator.sh script
as a child process - If the script fails, the LaunchDaemon will launch again in ten minutes
This script stages the bits to do the work. You can use it with any payload-free pkg creation method (munkipkg, Packages, etc).
-
On install of the payload-free package, it will stage the bits:
cp com.github.mlbz521.jamfMigrator.plist /Library/LaunchDaemons/
cp jamfMigrator.sh /private/var/tmp/
cp QuickAdd.pkg /private/var/tmp/
-
And then load the LaunchDaemon based on the OS Version
- if >= 10.11
/bin/launchctl bootstrap system $launchDaemonLocation
/bin/launchctl enable system/$launchDaemonLabel
- if <= 10.10
/bin/launchctl load $launchDaemonLocation
- if >= 10.11
This script issues a new FileVault Personal Recovery Key. It will require a known FileVault Unlock Key, which can be one of the following:
- A FileVault Enable Account with a known password
- Current FileVault Personal Recovery Key
Obviously, the easiest and most 'scopable' way to do this to have a FileVault Enabled Account. If you do not have a known FileVault Enable Account with a known password, then on ≤10.12, you can easily create one via Jamf before migrating to the new JSS. (Jamf cannot create a FV_Enabled account on 10.13+ machines currently.)
Add the script to a Policy in the new JSS and enter the known Unlock Key in the Script Parameter.
After migrating and after this policy successfully runs (i.e. the new JSS has a valid FileVault Recovery Key) the account can be FV disabled or deleted.