Move Macs to new JSS

kitzy
Contributor III

Due to a recent merger, we have had to move our JSS to a new server with a new domain name. I know there's absolutely no way around re-enrolling mobile devices, however I've been told that it's possible to tell Macs to check in to a new JSS using a policy. Has anyone done this before? Any advice?

8 REPLIES 8

gersteina1
New Contributor III

We're considering making our JSS available outside the firewall, so I think we're facing a similar challenge - hoping your answers apply to me as well.

rderewianko
Valued Contributor II

My Response when i contacted Jamf about this: (we dont have mobile)
However, since we are only OS X we should be able to get this rolling. We will bring up the new server with the new DNS name and restore a database backup to the new server. We will then modify the URL settings in both JSSes to point to the new DNS URL. We will leave both JSSes up and allow all devices to check into the new JSS. After all devices are talking appropriately with the new JSS, we can decommission the old JSS.

ctangora
Contributor III

I looked into this before we migrated. I think that I was able to get this to work with modifying the com.jamfsoftware.jamf.plist file in /Library/Preferences.

This did require the passwords to be synced correctly. I believe I tested this a few times, but ended up going with an alternate method of running a new recon to get them to the new server. So it may or may not work, but I think that method worked.

kitzy
Contributor III

I just did some preliminary testing on pushing a quickadd.pkg for the new JSS out to a few test clients enrolled in the old JSS. This seems to have done the trick. I'm planning to pull the trigger across the board tomorrow. I'll report back with my progress.

jarednichols
Honored Contributor

Depending on how your certificates are setup, you also import your jamfsoftware database tables and redirect with DNS. Once systems are checking in with the new box, you could then go about fixing the pref files properly.

kitzy
Contributor III

The re-enrollment was a success, but there are a few caveats. Here's what I've learned.

1) A re-enrollment by default will clear policy logs for that machine. In our case, this was actually a good thing because we had a number of policys that had to be tweaked and re-run anyway. That said, you can modify your db to prevent this behavior:

UPDATE management_framework_preferences SET flush_management_history_on_remanage=0;

2) The re-enrollment also clears out all location data from the inventory record. This was also not a problem for us as it all was outdated anyway.

3) The policy to push the QuickAdd.pkg out to the machines does not report back to the old JSS, so you can't use the policy log to confirm completion.

gersteina1
New Contributor III

Thanks for the update, John. It'll be good to know when we do it.

kitzy
Contributor III

Hopefully what I learned in the process helps you! Feel free to reach out to me if you want any more detail on what I've posted.