Software Updates for remote Macs encrypted with Filevault2?

Do it at logout, or when no user is logged in. Yes, it will reboot afterwards and sit at the FV authentication screen (or shut down), but the update will be done. Your users can then power up and login.

It seems like fdesetup authrestart process is your only choice to do what you want.

I use a similar process with PGP encrypted machines. When the processes are completed I then add an administrative bypass command through script that will bypass the PGP auth screen and allow the machine to boot to the logon screen.

So it appears the equivalent would be to run the fdesetup authrestart. When you say your operations team cannot do this, why not? If your company wants overnight maintenance, they might have to do this.

I hope it works out.

Aaron.

So it appears the equivalent would be to run the fdesetup authrestart. When you say your operations team cannot do this, why not? If your company wants overnight maintenance, they might have to do this.

Because maybe, since he's a Casper user, he has more than a dozen machines to consider...

All joking aside, the authrestart option is good for single cases, but since it's interactive, completely unfeasible for any large-scale deployments requiring reboot. You either need to settle for delayed reboots or rebooting to poa.

Still not understanding the actual issue here.

Consider this scenario:

FIleVault 2-protected machine is sitting at the loginwindow (no user is logged in).
Policy or softwareupdate runs and installs the 10.8.3 update, and reboots the machine.
Machine sits at FV2-unlock screen. After a while it shuts down.
Next morning, user powers it up and uses it.

Where is the problem?

Sorry. Old post that I'm finally catching up on. @gregneagle, our issue is that given the FV2 is preboot, I don't believe Casper can grab an inventory to report a) the successful OS X Update or b) allow remote access if additional work needs to be performed.

"given the FV2 is preboot, I don't believe Casper can grab an inventory to report "

Casper will (presumably) grab the inventory later, when the machine is booted. If not, Casper should be fixed.

"or b) allow remote access if additional work needs to be performed."

Yes. This is true. All things have trade-offs.
So you won't be able to do anything else until a user starts the machine up.
In my environment it has not yet been a big deal.

Regarding the first issue, the jamf binary should kick in pretty soon after booting up and capture new inventory, especially if the Mac had been shut down in the evening the night before and a user is booting it up in the AM of the next day.

That said, we developed something for special cases where we can deploy a package that installs a simple LaunchDaemon and script. The daemon calls the script at boot, and the script just runs a recon after booting up and then deletes itself and the daemon, so a one time use self destructing process. Maybe consider that if you're really concerned you won't capture inventory.
Lastly, installing something like an OS update actually does update the operating system to report the new version even before a reboot. Its true, try it out. Install 10.8.5 on a Mac running an older version of Mountain Lion, say from the command line installer and don't reboot once its done, then run sw_vers -productVersion and you'll see it reports 10.8.5 as the OS. So if you design it correctly, you should be able to have your installs done, then collect inventory at the end, with maybe a script activated at the very end of the process, then reboot the Mac.

Edit: Corrected embarrassing typo : o