New Deployment or Migrate?

You should be able to perform a manual backup of the current database, then import that backup once the new JSS has been set up. Prior to this backup, make sure that you've upgraded your current JSS to the latest version.

Jeff Johnson
Professional Services Engineer
JAMF Software

Hi Steve,

I've done migrations as you've outlined & they have worked well.

Only thing I'd suggest is to change the Casper URL from server02.company.com to jss.company.com.

That way if you need to migrate again you'll be able to forgo this DNS issue as you could just migrate the JSS to a new host then update the DNS.

Yea, then disable all policies on the old JSS except one that installs the new QuickAdd, so clients are rerouted to the new JSS.

The old JSS won't "know" that the client was rerouted to the new JSS, since QuickAdd stops reporting to the old JSS once it's redirected, but this is easy to track/reconcile with Excel. :)

Don

Thanks all!
@ bentoms- We have a (silly) corporate policy on server naming (can't reuse a name) & dns so server02.company.com is what we have to go with. And server01.company.com is bound to so many other super cranky functions besides the jss it's not worth it (IMHO) to try and down the entire thing, build a new server01.company.com and reinstate all those things on the new server01.company.com. And a few of the functions currently on server01.company.com need to be migrated to the care and feeding of other teams who have their own timeframes...

@ donmotalvo - yeah the idea I was going for was basically build the new one in parallel, then cut over via new quick add/ policy. and then eventually stop the old jss.

THanks again!

Might want to keep the old JSS running indefinitely, to catch the stragglers, unless you know for sure all the Macs made it over to the new JSS.

Too bad the company policy won't let you make this change - I tend to use server names based on services offered (mail.company.com, jss.company.com) - these are actually CNAMES (dns aliases) to the particular server/VM (server01.company.com, server02.company.com, etc.).

General words on JSS migration... if you were able to use a name like jss.company.com, change the URL in the Management Framework settings (and re-do any certs)... let the change replicate... then do a database backup/restore, CasperShare sync, and point DNS over to the new server, and you're good.

Alternatively, where you can't do that, Don's suggestion is a good one. After doing a database backup and CasperShare sync to the new server, delete/disable all policies on the "old" JSS, create a single run-once policy that runs this command:

jamf createConf -server server2.company.com

As clients check in with server1, they will be redirected to server2. Of course, depending on your certificate settings, they may not actually communicate with it correctly, but, if possible, this is one way to get clients moved from server1 to server2...

Redirecting the Macs alone might not work, since the enrollment certificate won't be trusted.

Just a question:

Are you moving ALL of the JSS services (i.e. Tomcat, MySQL, FileShares etc...). or just some of them? If you're only looking to move the JSS instance (i.e. the Tomcat/Apache web service) you don't have to do anything to the MySQL database. There's a file (database.xml) that you'll modify in the webapps folder of tomcat and everything would point right back to your original MySQL DB. Not much work required... (OK, firewall permissions as well)

The CJA is still fresh on my mind. Dusty had us do a lot of this sort of thing in class. Something like this took maybe 10 min to setup once you had the box running TC.

*Ditto on the certs mentioned above*

@ Chris - we're moving all jss related services. The current box is old, and loaded up with a few other non-jss functions that would be best broken out onto their own boxes as well. The jss is the first to be relocated.

What we did was Copy the database from the old server to the new.
Had machines re-enroll (which kept their filevault data / other data)

The problem we ran with was, when we switched DNS (it was casper01 and we went to casper) we lost functionality on the APN network due to the machine not having the proper certificate for casper.

What we did was Copy the database from the old server to the new.
Had machines re-enroll (which kept their filevault data / other data)

The problem we ran with was, when we switched DNS (it was casper01 and we went to casper) we lost functionality on the APN network due to the machine not having the proper certificate for casper.

Do you manage iOS or just use the APN service for the OS X Clients?

I would have re-enrolled all of my clients when I did a server move recently, but I couldn't re-capture the FileVault recovery keys so that was a no-go.

We ended up moving the database to a new JSS instead and set up a cname for the old host pointing to the new one. However, now clients that enroll with the new server are bound to that new server name, so I wish I had handled it differently and simply re-used the old name (which would have been against policy, but oh well, it's just a hostname).

Not many of us can't say that! At the very least your users were just fine though it is extra work on your side. Either way, now your transferred!

update-
So we managed to move everything over to server02.company.com from server01.company.com - enrolled some test systems and everything works except the MDM & our configuration profiles- our test 10.8 systems don't even show up as being MDM capable..

How did you get existing Macs over? Did you leave the old server up and use a policy to install a new QuickAdd to get them over to the new server? Or did you redirect the URL, if so do they accept policies, check in and report properly?

left old server up, generated a new quickadd.pkg for server02 - Deployed as policy from server01 - this ran, and they do check in on 02- I ran a Software Update policy on them successfully from 02 to test, but no MDM on the clients and from server02 the test units are not seen as MDM capable, and thus no config profiles..

Update:
Exported DB from server01 to server02 - this seems to have gone off w/out a hitch.
Created a quickadd.pkg for server 02
Created policy on server01 to install the quickadd.pkg pointing the clients at server02- this appears to install correctly:
• Clients check in now at 02- recon to 02, if you run an enroll, it's pointed at 02 and shows no errors
• They check in on schedule
• made some policies on 02 and they execute correctly on the redirected Macs.

BUT:
in the JSS on 02 NONE of the converted Macs show up as MDM capable. We use Configuration Profiles so this is a big deal. On one of the client macs, while digging through the Keychain, we see that there is a JSS issued cert, under System- "my company.com JSS Built-in Certificate Authority" inspecting it is shows that it was issued by server01.company.com- if we delete this and re-enroll the Mac, we get the same server01 issued cert.

Just wondering here...

What if you tried regenerating the built-in certificate by going to Settings -> General Settings -> Server Configuration -> "Replace with certificate from the JSS's built-in CA"?

Maybe server1 cert came along with the DB restore?

I thought I'd revive this old thread by mentioning a great talk I saw at #JNUC2015:

Make your JSS feel new again with the help of API

The author wrote a JSS Migration Utility that runs in bash and lets you do it one step at a time.