It’s that time again, you’ve probably been putting it off for a while, your somewhat old, so far reliable hardware is nearing the end of it’s service life. You’ve gone from a single distribution point, to multiple distribution points, and fail over distribution points too.. Now the Tomcat server needs a refresh, you might also want to change the management url to provide services outside the firewall. Looking around the documentation is pretty thin, and doesn’t appear to cover all the steps. You might be using configuration profiles and be worried about certificate based communication..
These are the steps I used to migrate without interruption to users the JSS to a new tomcat server, and change the management url at the same time. Just a warning this took a lot of preparation and testing, even though I was able to make it work, I would still suggest a heavy test plan specific for your installation in case you are using features I’m not.
I’m assuming you’ve already built your new server and have a working installation of tomcat, connections to your database, and hopefully some monitoring of services too.
Schedule a long change window with full outage to Casper services…
- Stop Tomcat on the old server
- Stop Tomcat on the new server
- Backup the database used by the old server
- Restore the old database backup to the new database
At this point a note.. You like myself may have a separate database host, unfortunately with this procedure you will need to have two databases.. database old and database new – as you will need both the old and new JSS running for the migration.
- If both databases are on the same host you might need to increase the max connections in the my.cnf file and restart mysql
- Open a mysql session and truncate these tables: mobile_device_management_framework and certificate_authority_settings
The reason for truncating these tables is to ensure the built in CA correctly refers to your new management url. If you aren’t changing the management url.. ignore…
- Start Tomcat on the new server
- Change the JSS URL
- Restart Tomcat
- Acquire a new certificate from the built in CA
- Update the change management path (if you are changing server OS like I did)
- Restart Tomcat
- Request a new APNS cert
- Disable any policies or configuration profiles not wanted on the new server
- Create a quickadd package with Recon pointed to the new server
- Start Tomcat on the old server
- Upload the quickadd package to the old server and sync distribution points
- On the old server create a policy to install the quickadd package, and in the advanced tab run the command “jamf manage”, and disable update inventory.
- Scope the policy to a few computers on the everyHour trigger
- Test the migration – even if you’ve done it before, test again – you’ve just restored the database and replaced certificates so a test is good for peace of mind
- On the new server create 2 smart groups, one for computers with the old management url, the other for the new
This allows you to see the migration process – how many still to go.. how many have come across.
- If the policy test was successful widen the scope
- Disable staff logins for the old server (keep yours active) you don’t want computers accidentally enr0lled to the old JSS
- Refreshing the members view of the smart groups you should gradually see the clients coming across to the new server.
- Don’t forget to make sure your new database is backed up with both nightly dumps and to tape!
Some points to consider…
My environment is heavily reliant upon certificates deployed with configuration profiles. There is a small period of time whilst enrollment to the new server is completed that all profiles are dropped from the client. If your network is reliant on certificates for authentication and other services, you should ensure these are deployed by other means prior to attempting the migration.
To work around this, a configuration profile was packaged, deployed to clients via policy, then installed via policy with the profiles command. This was to ensure should a client have a messy migration the user would be able to continue working. This would also ease repairing a computer if necessary as the support staff would still be able to remotely access a computer. Might sound like extra work, however with users all over the world as much as I’d like a trip to the Sydney office.. It’s probably better if I don’t visit because my migration took the users offline!
I hope this is helpful, ask questions, or share your tips on migrations.
For those interested the JSS was migrated from OS X Server and is now happily running on an Ubuntu virtual machine hosted on esxi.