Enrolling existing systems to a new JSS server and version

[TinmanF1]

I have a series of 10.8.5 machines that are associated with an old JSS server (running 8.60). We've stood up new servers (running 9.24) to handle this role, and I was looking to enroll these machines into the new JSS before we decommission the old server. On two different client machines, I replaced the old Casper Suite with the new one, and then attempted to run Recon to enroll the systems and associate them to specific AD users. After running for a couple of minutes, it flagged an error message stating that "Recon failed during the submit process. No Computer ID Returned." I restarted the system and attempted again. After receiving the same error, I tried the same steps on a second machine, and was met with the same error.

Is there something additional that I should be doing to associate a system to a new JSS?

[ctangora]

We are doing almost the exact same thing (8.61 to 9.24). What we are doing is just running the QuickAdd package, seems to work for the most part.

In order to get the user data of out the old server to the new I have an API call that writes the user's name and the asset tag to a file on the computer (which is monitored by an EA). Only those machines that have an asset tag AND a user assigned to those fields can migrate over. Then in the new jss I just do a cat to each of those file and pass it to a recon and they populate the new JSS with the asset tag and the last known user (According to the old JSS).

[Snickasaurus]

@ctangora

Would you mind sharing your API call/script and perhaps a bit of your work flow for the EA's? We are getting ready to do the same thing.

[Aaron]

What I did was configure the JSS URL in "Global Management Framework Settings" to point to the new server. Clients check in, get redirected, and grab the new config/JAMF binary. I haven't had any issues so far, and I've got maybe 70% of the clients migrated over.

This way, you don't need to go around and manually re-enroll each machine. It's a pretty hands off process.

Edit: Oh, it might be worth mentioning. I got the new server up by replicating the v8 environment, copying the database across, and then upgrading to v9. That way all the client entries are already in there, they just need updating. Not sure how you're doing yours exactly.

[JPDyson]

@Aaron That's our current plan; to replicate the environment and upgrade, mainly because of FV keys.

[CSHGreenwich]

We are also looking at migrating to a new server and we ned to upgrade to OSX 10.9 as well.

We are presently at 10.6 and JSS 8.75.

@ Aaron what version of OSX and JSS was your old server ?

[Snickasaurus]

My problem is I'm using a different admin account on the new server. So this is becoming a bit more challenging.

[Aaron]

@CSHGreenwich - old server was 10.7 and JSS 8.73. New server is CentOS (I was able to manage a VM in our cluster with sysops) and JSS 9.32. I only had the one server to run JSS on, and I held off on upgrading as long as possible because I didn't want to upgrade production.

For me, it was just a case of set up the new server running 8.73, restore the database from the old server, and then upgrade to 9.32, it was actually all surprisingly very easy. Enrolled a few test Macs to make sure everything is working, then made the switch by editing the JSS URL. I'll be upgrading the 10.7 server to 10.9 soon to take advantage of the Caching Server (when I'm happy most of the clients have checked in to the new server - any after that I can just manually re-enroll... I'm not sure the 8.73 install will survive a 10.9 upgrade?)

@Snickasaurus - I don't think that will be a problem provided the "jssclient" credentials remain the same? Don't quote me on that, though.