I have about 35 Macs in a old Jamf cloud and will be moving them to a new Jamf cloud. I have access to both and wanted to see if I could write a script to unenroll them and then reenroll them info the new Jamf. Majority of them are not DEP only 3 are in DEP. I thought I could have a script remove the MDM profile and jamf framework. Then do a enrollment through the shell with a enrollment only account. Thoughts about if this will work or not.
Solved
Move from 1 Jamf to another
+17Best answer by stevewood
@kericson No, you would not want to remove them from the old Jamf first since you will use that old Jamf to install the QuickAdd.
- Create a QuickAdd package from your new Jamf instance.
- Upload the QuickAdd to your old Jamf instance.
- Create a policy in your old Jamf instance to install the QuickAdd and scope properly.
When the machine runs the policy and installs the QuickAdd, the Mac will now be pointing at your new instance.
There are two cautions (forgot to mention one of them in earlier post):
10.13.4 and above systems will NOT have user approved MDM (UAMDM) profiles so you will need to ask your users to approve the profiles after the computers have moved over to the new instance.
If you use ISE or any 802.1x profiles that are pushed from your old instance, you may not be able to do this. When you run the QuickAdd, the configuration profiles from your old Jamf instance will get removed, which basically drops the network connection for the Mac. When that happens your computers would not be able to communicate with the new Jamf and they would become unmanaged.
The second caution there can be mitigated, either with the tool that Jamf has that I mentioned, or by manually installing a configuration profile for 802.1x (ISE) before running the QuickAdd. However you would want to test that very thoroughly to make sure you do not interupt your users. And honestly, for 35 machines, unless they are spread across the country/globe, it would almost be easier to walk around and manually enroll them using Enrollment URLs.
+38@kericson reach out to your TAM and see if they can help out. Jamf PS has a product they wrote in house for this, but it may only be available to certain support customers.
Otherwise, you can simply send a QuickAdd from your new Cloud using a policy in your old Cloud. We've done that in the past and it has worked fine (we've migrated well over 3,000 devices from other Jamf instances into a cenral instance).
There is no way to get around UAMDM regardless of the method you use. If you have 10.13.4 and higher devices, they will all need to have the new MDM profile approved. Your only option, that I am aware of, would be to send out an enrollment URL to your user population, assuming they are admins on their machines.
+38@kericson No, you would not want to remove them from the old Jamf first since you will use that old Jamf to install the QuickAdd.
- Create a QuickAdd package from your new Jamf instance.
- Upload the QuickAdd to your old Jamf instance.
- Create a policy in your old Jamf instance to install the QuickAdd and scope properly.
When the machine runs the policy and installs the QuickAdd, the Mac will now be pointing at your new instance.
There are two cautions (forgot to mention one of them in earlier post):
10.13.4 and above systems will NOT have user approved MDM (UAMDM) profiles so you will need to ask your users to approve the profiles after the computers have moved over to the new instance.
If you use ISE or any 802.1x profiles that are pushed from your old instance, you may not be able to do this. When you run the QuickAdd, the configuration profiles from your old Jamf instance will get removed, which basically drops the network connection for the Mac. When that happens your computers would not be able to communicate with the new Jamf and they would become unmanaged.
The second caution there can be mitigated, either with the tool that Jamf has that I mentioned, or by manually installing a configuration profile for 802.1x (ISE) before running the QuickAdd. However you would want to test that very thoroughly to make sure you do not interupt your users. And honestly, for 35 machines, unless they are spread across the country/globe, it would almost be easier to walk around and manually enroll them using Enrollment URLs.
+17Thanks yeah talking to my client the will just enroll into the new environment by hand. Thanks for this info as it’s very helpful for feature.
+20@kericson Maybe useful if you want to migrate some Jamf data, you can even migrate the inventory data of your Computers!
https://github.com/jamf/JamfMigrator
+7Agreed with @txhaflaire Jamf Migrator is the tool you need. Available on GitHub or the Jamf Marketplace:
https://marketplace.jamf.com/details/jamf-migrator-3
+25@stevewood While the Jamf tool you're referring to for migrating a Mac from one JSS to another does allow the installation of a temporary profile to use during the migration process it specifically states in the docs that profile can't be used for 802.1x.
+38@sdagley yep, fully aware of what the docs say, but I have it working in two different locations with two different Cisco ISE setups. :-)
It's a house of cards situation for sure. I'm just hoping the wind doesn't blow too hard. Fortunately we're done with one migration, or close to down (300 machines migrated) and have just 90 or so at the other location.
+25@stevewood Now you've got me feeling rebellious and wanting to try an an 802.1x profile despite the warning in the docs. :-) Are you using the profile to install a cert+network config for Wi-Fi 802.1x auth, or something specific for Cisco ISE?
+38@sdagley cert+networking config for 802.1x wired and wireless. We leave the profile in place afterwards, but you could come back and remove the one installed by the migration tool. I would do that via a LaunchDaemon or something just to be safe.
+25@stevewood Does removing a config profile still nuke any Wi-Fi config for a SSID of the same name even if it's not the config that profile installed? I haven't tried that in a while, and if it does the temporary profile would be less useful than I'd hope.
+38@sdagley that I am not certain of, sorry. I do not recall what our tests revealed in those cases. We chose to leave the temp profile in place, for now. We're hopeful ISE might go away at some point. Doubtful, but one can hope.
+25@stevewood Is the profile you're installing computer level or user level? A side benefit of the migration process for me is removing a non-compliant computer level 802.1x profile that was part of our High Sierra deployment process. Users who need an 802.1x profile (we have a large number of users that work from home so it's not required) can install a user level one via Self Service. That's covered in the migration instructions being sent to users so I think having the migration tool install a temporary profile won't be a great benefit for me (luckily I don't have to deal with ISE...yet)
+8If you have two instances: Why not create an enrollment-invitation on the new Jamf and send
defaults write /Library/Preferences/com.jamfsoftware.jamf.plist jss_url https://new_jss
jamf enroll -invitation 123456903867xxxxxxx
from the old one?
Of course the UAMDM challenge stays the same...
You can trigger User Approval for DEP/ADE machines with
profiles renew -type enrollment
+14Use the Jamf Re-Enroller app. It's built for this exact purpose
https://github.com/jamf/ReEnroller
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.