Migrate devices from 1 Jamf Pro environment to another (DEV to PROD)

Are you planning to migrate live Macs enrolled onto the dev environment to the prod? Can you not deploy a quick add on the dev server to the Macs that you want enrolled onto the prod one? Re FV2 keys, just add another policy to check for invalid keys to re-escrow back to the JSS. Don't forget 10.13 Macs need scoping separately for the redirect.

Just to add the only account on the FV list is the end-user. From my understanding we wouldn't be able to re-escrow because of this...

From what I done in the past, we escrowed it but it prompts the user to enter their passwords and then re-directs the key. Literally a pop up box going 'hey - please enter your password bla bla' and after that was it...

You would need to wipe and re-DEP enrol iOS devices if you want them supervised - there is no way around that. However, macOS devices, you would just need to push or install the QuickAdd package for your production instance and it would un-enrol the device from your dev instance and enrol into the prod. You would then create a policy to re-issue and escrow the FV key to run at enrolment complete. This should help you work out how to achieve this with only the end user as a valid FV user:

https://github.com/homebysix/jss-filevault-reissue

Hope that helps.

Thanks @cddwyer already testing the re-issue script.

@MLBZ521 is correct. Although Jamf support says that simply pushing a QuickAdd should get everything over, it leaves the other servers MDM profile in place, which leaves the machine in a non MDM manageable state. I've run into this personally when working with a client that recently purchased Jamf Pro and was running a cloud based dev/test environment and then needed to migrate the test enrolled systems into prod later.

I ended up pulling the QuickAdd into Composer and added a preinstall script to it that would check the conditions on the Mac, and if necessary, would do a jamf removeMdmProfile command (among other things) beforehand, which would wipe away the previous MDM profile and then enroll the Mac, which pulled the correct one down.

@MLBZ521 Well, that has not been the case in my experience. I've performed JSS/Jamf Pro migrations, and the enrolment method I use is to use the existing Jamf Pro server to deploy/scope out a quick add package to enrol the clients in the new Jamf Pro server.

If running a quick add package doesn't work for you then there is something unusual/problematic with your deployment, even with my own experiences aside, I doubt Jamf would recommend a method they hadn't tested and deemed to be sufficient/efficient in a real world scenario.

I appreciate everyones responses...
@MLBZ521 in the process of testing out your migration script. Looks awesome!
@mm2270 Thanks for the heads up on the removal of the mdm profile
@cddwyer when you have done migrations in the past were the machines DEP'd in the old JSS?

@MLBZ521 A mixture of user initiated and DEP enrolled machines, some originally enrolled with a Quick-Add and recon as well.

Nice to
Know there is a cleaner way to
Migrate however quick add works just fine including certs and MDM use, I’ve done it on thousands of macs with no issues at all.

@mm2270 and @MLBZ521 are correct in the fact that the quickadd package does not remove the previous servers MDM profile. If you look at the contents of the quickadd's postinstall script there is no logic in there to remove a previous servers info or settings. This is easily confirmable by just running the commands locally and looking at the MDM profile not changing. And MDM profiles have the JSS url hard-coded within it so it has to be changed for it to communicate with the new server.

The jamf binary commands in there (createConf and enroll -invitation) will overwrite previous jamf settings on the computer for the server it connects to (jamf createConf) and pull down a new device cert (jamf enroll) but you will still have to remove the older MDM profile (jamf removeMDMProfile && jamf mdm) before the new one comes down since you cant actually overwrite an MDM profile, they need to be removed and replaced.

Beware that removing the mdm profile will remove any WIFI profiles pushed via MDM as well so you may have to establish connection (or establish different connection prior to migration) in order for the enrollment to the new server to complete.

Thanks Everyone for the guidance. https://github.com/MLBZ521/jamfMigrator and https://github.com/homebysix/jss-filevault-reissue FTW!
@MLBZ521 I pinged you an issue on git

Thanks for confirming @mike.paul .

Glad my migration script may help.

Hi all! I'm the maintainer of the jss-filevault-reissue workflow referenced above, and I've got a quick update that may be of interest to you.

My team has published a new tool called Escrow Buddy, which regenerates FileVault keys at the loginwindow, thus avoiding the need to prompt users for their password later. It should be suitable as a drop-in replacement for my previous jss-filevault-reissue workflow at most organizations.

You can read more in this announcement on the Netflix Tech Blog, and this post on my site specifically covers migrating from my old workflow to Escrow Buddy. Escrow Buddy's source code and installer are available on GitHub.

Thanks!