Error adding user to FileVault: Added users failed error.

What is it saying in the system log? Has this local user been added to FV2 before?

@ClassicII

Yes - the it.admin account existed prior and was a part of FileVault prior as well.

The idea is to create the user on systems that didn't have the it.admin user prior or to re-create the it.admin user if an end user decided to delete it.

According the "Creat IT.Admin Account" policy log...

Executing Policy Create IT.Admin Account...
Creating user itadmin...
Adding user itadmin to filevault
Error adding user to FileVault: Added users failed error.

Is this 10.9 or 10.8? Also what does it say in the local machines /var/log/system.log at the time when you try to add the account ?

How is your FileVault 2 disk encryption config set up? Are you using the management account as the primary FV2 account on the box? I'm not familiar with the "Enable user for FileVault 2" option you mentioned. This must be something new in Casper Suite 9, or perhaps only shows up if using the management account as the first FV2 account added to the system.

I have a suggestion, which is, after the account is created and added to FV2, consider changing the account UID to be below 500 and also setting MCX (or use a Config Profile) on your Macs so sub 500 accounts don't show up in the Users & Groups preference pane. That way users won't feel compelled to delete the IT Admin account and the home directory for the account won't show up under /Users You'll still be able to log into the account locally, use it for ssh (if you need it for that) and authentication, etc. It just won't appear to the end user other than at the FileVaul pre-boot screen (still no way around that) and so they likely won't go searching for it to delete it.
Rich Trouton has a blog entry on exactly how to do this, Take a look:
http://derflounder.wordpress.com/2012/02/22/hiding-an-filevault-2-enabled-admin-user-with-casper/

I know that doesn't solve your immediate issue, but it seems like the sole purpose of your policy is to work around the issue of an IT use account being deleted by end users. Eliminate, or at least greatly reduce the possibility of this happening and the need for such a policy will probably vanish.

Mike makes a good point about hiding the user to help reduce the likelihood of this scenario in the fist place. However, in the event we run into this scenario, the requirements for enabling a new user, specifically the management account, are a 10.9+ client OS and a valid individual recovery key stored in the JSS. If either of these requirements are not met the policy will fail.

Apple added a few new enterprise friendly features in 10.9 with the fdesetup binary that allow the JSS to better report and interact with FileVault2 encrypted machines.

@ClassicII - Haven't looked at /var/log/system.log ... yet - On my next round of testing in the lab I will check that out.

@mm2270 - Thanks for the tips - I will look into those - especially adding the user below UID 500.

@Sam.Fortuna - We are 10.9.x - FileVault2 is using an institutional recovery key stored in JSS. We do not use individual keys.

Since you're not using an individual key it will be impossible to add an additional account via the JSS with built-in functionality. Creating a new local account or simply enabling the management account for FV2 requires that a valid individual key be stored in the JSS. Perhaps you want to consider using both an individual and institutional key in the future.

Sorry for bumping this but i'm having the same problem here on some machines.
Were you able to fix this and if so, how?

We have machines exhibiting this behavior too. Haven't found any symptoms. I did find, though, that on one of the machines trying to manually add the account to the FileVault 2 enabled users through System Preferences fails also.

I'm also curious to see if there's a resolution to this before handing this over to support/support rep. I can add them to the 'enable user for FV' in system preferences manually, but I'd like to be able to do this via jamf when creating the new local admin account.

From what I've found, this is happening to us because the FV2 key is being stored locally and not being sent to the JSS. So it's not actually getting the FV2 Disk Encryption Configuration you're deploying and instead just turns on FV2 and adds the local user as the FV2 user and that's it. Which means you can't add other users to FV2 on the machine because it's not using the configuration you attempted to push.

Why this happens is still a mystery to me. We have about 9 computers that have this problem. The rest work just fine. No common variables between the machines to cause the encryption configuration to fail on initial setup.

Ahh makes sense about the FV2 being stored locally. This might turn into a little bigger project, but I guess we can turn off FV2 and then re-enable it via Jamf with individual keys being stored in the JSS. Not sure why only 9 of your machines has this issue but not the rest. Have you spoken to Jamf support to see if there's definitive answer to your issue?

Wondering what they have to say about it. I'm going to email them to get their best plan of action for this task.

Thanks emilykausalik :)

So far we haven't found a root cause. And it's tricky because since the user is the FV2 user you have to rely on the FV2 user to unlock the disk, then try it again.

@syunetsy Instead of turning off FV2 and re-enabling, you could try to reissue the FV2 key.

We've implemented the script found here from @elliotjordan & it has worked smoothly and saved us tons of time.

You need to set a config profile to "redirect FV2 keys to JSS" and then run the script. The script will prompt the user for their password and then escrows the key for you.

@merps I've heard of this magical script but haven't tried it yet… putting it on my list of things to do.

Awesome, thanks for sharing!