Moving to New JSS

[Treger]

Hi Guys,

I have a bit of a weird issue, I am moving to a new JSS and I am trying to do a IP range recon, this keeps failing with a socket error, I have tried to push a quickadd and this has failed too through ARD. If however I do a single recon to one of the machines that does not work in the IP Range add, it works...

Anyone have any ideas?? I have checked my PKI etc they all seem fine. If it was a network issiue, I would have thought that the single recon would not have worked...

[ega]

What happens if you take the quick add.pkg for the new jss, upload to the old jss and deliver it using a policy on the old jss?

[mm2270]

Are you looking to migrate computers over as new entries in your new JSS? Or were you looking to migrate the db from the old JSS into the new one? If the former, then doing what @ega mentioned should work. Essentially, set up a policy for all your Macs still pointed to the old JSS to send the QuickAdd.pkg built from your new JSS to install on them, which effectively moves them (as new records) to the new JSS.
If you wanted to move over the db then of course this wouldn't be the way to do it.
However, I assume since you mentioned trying to use Recon.app to recon the Macs into the new JSS that you're making a clean break from the old one. If so, I would look at the process outlined above instead of trying to do a network Recon scan.

[Treger]

Ok, thanks guys, I will try with the quick add, the issue with the older server it that the machine DB is badly corrupted, not all the machines are reporting in correctly. I was trying to get them over floor by floor gradually so that I can limit stress on the helpdesk if there are any issues. Seems to me that easiest way to do this may be with a CNAME from the old server to the new, I have turned off a bunch of the policies so that they can be scoped correctly after all the machines have been added in and then I will set them back to how they were...

[anickless]

I feel for you, I had a bad DB as well. I Used recon to scan ranges and individual computers. Also emailing out a quickadd.pkg might be a possibility as well.

[stevevalle]

I have recently started moving machines over to a new Casper server. Corrupted DB and too many issues, so it was easier to install and start from scratch than resolve ongoing issues!

I created a QuickAdd package from the new server and distributed either via a Self Service policy or Casper Remote. The enrolment from the new server overwrote the existing enrolment.

I assume the machines still have the management account? Casper Remote might be your best bet.

[donmontalvo]

Migrating to a new JSS...ugh...lots of work. This is where having sound logic saves the day. So your Once-Per-Computer policy to install Adobe-CC-Whole-Enchilada doesn't kick in again. Desired state, etc.

Exporting EAs is possible, we have so many. Not sure about Smart Computer Groups, although a little birdie told me @jhbush1973 might know a way. :) Static Groups ain't gonna happen, since the computers won't yet be in the new JSS. But then, sound logic, maybe not so important.

It would be great to have a tool that lets you cherry pick what you want to bring over, and leave the trash behind.

Don

[Treger]

Hi guys, thanks again, yes to all the above, I have actually managed to get the Recon with IP range working by cutting it down into smaller batches of 100 with the range scanner, I think the max thread pool on Tomcat had something to do with that...

In the past when doing a new JSS from a corrupted one I have usually just built a brand new JSS and then put in a CNAME to redirect the machines from the old JSS to the new, they auto enrol themselves and if you have a place where your machines do not leave for extended periods of time you could have them all enrolled with in a couple of days to a week. In this case I tried something new, I took the old SQL database and truncated out the machine table, restored this to the new JSS and then just went through and reconfigured the new server names network segments etc. This is the first time I have tried this the server seems to be quite stable and the old DB pointed to an issue with the machine table. Cherry Picking option for a JSS would be a great feature in some cases moving onto a new JSS and being able to select what data you would like to come across would be sweet!

I did not want to rely on the old server distributing the quick add as the machines were seeing errors when doing a terminal jamf policy - which was quite disturbing, a machine would report in and then details on it in the JSS would not update. The Casper Remote was deploying packages successfully but then would it would register a failure at the end of running it, looking at the log there was no failure at all so could not work out why Casper Remote was doing that and actually looking at the package deployed , it would have installed. I think I can safely say that the old DB is well and truly Rest in Pieces....

[Matt]

@donmontalvo

I can't stress how important that is!!! Make sure you don't forget to export your EA's and especially your scripts. The older versions saved the scripts directly to the CasperShare but now the DB is the script "repository". Nothing like having to import an old SQL backup to grab a few scripts and EA's. Plus, its just a good habit to form, when backing up export, export, export!!!