I'm in the process of setting up a new JSS instance in our environment to migrate to (from Server 2012 R2 to CentOS 6.8). We only have 150 clients and after reading many of the threads here, moving to a new instance doesn't appear to be a big deal. Especially as it lets me tidy up policies, groups, clients, etc that have become stale.
However, as we use individual FileVault 2 keys per Mac, its now occurred to me that we have stored all the keys in the old server's DB. What is the best way to migrate these out (if possible)? Or would we have to generate new keys for every encrypted Mac? We are running about 35 percent El Cap and and rest are Yosemite.
Solved! Go to Solution.
Unfortunately, we're trying to avoid doing that. We're trying to start from a clean install and import things that we need from the old server. The clients will all enrol to the new instance via a policy from the old server.
I know that 9.92 introduced an option to generate a new FileVault key, which will work for some clients - but not all. My questions I guess is asking more if there is a way to export the FileVault keys and the machine associations.
No, there's no way to export FV2 Recovery keys, either in a static list/csv form or in a database format that you can import back into the JSS. If you're starting over with a new database, you're going to need to re-issue all your Recovery keys because it won't be possible to migrate them into the new one, without doing a wholesale db migration.
I had a feeling it wouldn't be and the security reasoning makes sense. I'll snapshot the VM and then import the DB to test against. Although we don't have a huge number of clients - our users, like many others, are very difficult to get their Macs back for something as simple as generating a new key.
@dgreening, I thought of that too but like our Windows clients, we don't allow the management user in FileVault 2 for security reasons. We can't have a local account (where the password doesn't change often) to have access to unlock a drive that leaves the building.
We've seen odd behaviour from the old server and the DB - a few tickets have been raised in the last 6months with JAMF support. Performance recently dropped right down and we found the Tomcat instance was running but not accessible - full server reboots fixed this.
I had suggested to my manager that maybe we could start a fresh and migrate clients over slowly. I've now migrated the old DB into the new server and will just go through it thoroughly and purge all the guff we don't want or need.
@bmarks, thanks so much. We have a similar but much more basic version of that process that we used to originally enrol encrypted Macs to the original Casper instance. This looks much cleaner and nicer from a user point of view. I'll give this a go too - we're still a few weeks away from migrating the new server to production.
Thank you again all for your suggestions.