Start Over or Migrate to New JSS Server

[JimAllsop]

We just got our new blade server and VM set-up, and the systems team has made me a new JSS linux server. Here is the dilemma, migrate everything or start from scratch?

The systems manager wants to start from scratch. I'm the help desk manager and I am leaning towards migrating the system over.

Here are the particulars of our enterprise.

- 435 managed macs, very mixed bag from 13" MBP, 15" MBP, iMacs, mac mini, and mac pros. - 25 ios devices. (more coming) - 10 locations across our metroplex. - 50-95 Network printers
- 120 or so policies.
- NO Configuration profiles.
- NO Managed preferences. - 1 File Share.
- No JDS instances.
- No Netboot.
- Self Service is up and running with printers, drivers, some software, and some maintenance task.

My Take:
- Removing JAMF from all the computers so that we can reenroll them in the new JAMF seems like its not worth it. - The issues that we are having with the file share dropping off line should be resolved on the new server. - The HTTP issues can be fixed with the new settings from systems and network. - This will leave all the printers, policies, and self service in tact and our users will/should see little impact. - Additionally I will not have to remove and reenroll all our users. I think the staff will not be thrilled with us having to do this.

What say you all?

[evanmellichampe]

You should be able to generate a QuickAdd.pkg from the new JSS and use your existing one to install it via policy, thus enrolling all of your machines without having to remove framework.

[localhorst]

Looks like you have invested quite some time in setting up all these objects like policies, printers, etc. I would try to assess how much time it would cost you to recreate all this in the new JSS as proposed by the systems manager as opposed to simply migrating the hosts.

I would lean towards a migration, possibly simply by replacing the old JSS with the new name on the same DNS name as this is the easiest way to change infrastructure. If you systems manager wants to change the DNS name, you could still run two JSS instances either as a cluster against the same DB whilst migrating the hosts from the old DNS name to the new one.

Having said all that in favour of a migration, I would like to note that starting from scratch is a unique opportunity to review and refine the existing set-up. We did this 40 months ago and got rid of a lot of quirky patches and took the time to standardise even more.

[ToriAnneke]

I re-did everything from scratch.

As Localhorst mentioned, I got to clean up a lot of old scripts, policies, packages, MCX, etc. as well as refine our implementation.

Unlike OP, I deal with 120 machines in one location. So it wasn't such a chore to set up from scratch for me.

[JimAllsop]

if we start over I can re-import my packages with out any issues correct? I really don't want to redo that many things.

@localhorst the time is a huge concern for me. All our network printers are not the same, and even those that are the same they done all have the same options installed. So just because it is a MP4502A one might have a 3100 finisher and LCT while another might have 3200 finisher and no LCT.

On the flip side there are some goofy things going on in the set up and that might be better served starting over. Its just a tough choice I feel.

What I want to do is say migrate it over, if after 2 weeks we are still having some of the glitches, blow the VM away and we start a whole new JSS.

[rderewianko]

If your going with a new jss @brysontyrrell has a great program written to help... http://bryson3gps.wordpress.com/2013/12/17/promoter-downloads/

[stevewood]

I would echo what Marko (@localhorst) said, it's an opportunity to get rid of old policies/scripts/etc. And you don't have to necessarily migrate all of them at once, unless you just want to. You could do one location at a time (you mentioned 10 locations) and take your time.

I wind up re-doing our JSS from scratch with about every other major release of the JSS. Right now, with version 9, I have my old JSS and new JSS running side by side, and I'm migrating machines as I have to touch them. It gave me the opportunity to get rid of old scripts, and to change how I do things in some cases (using lpadmin to add printers instead of Casper Admin).

You could script your printers instead of using Casper Admin. This would allow you to copy and paste the code, change the few things that need to change, and move on to the next.

Just give your new JSS a different URL, grab the QuickAdd from it, and deploy that to the select machines you want to change to the new JSS via a policy on the old JSS.