Apple’s release of Yosemite has brought with it the ability to use an Apple ID to unlock and reset a forgotten account password to log into a FileVault 2-encrypted Mac. You can use this ability in a couple of ways:

1. By setting up your iCloud account as your account on the Mac in question.

2. By associating your local or mobile network account on the Mac with an Apple ID, and selecting the option when enabling FileVault 2 to use your Apple ID to unlock the disk and reset your password.

Note: This method uses Apple’s services to store the needed FileVault 2 recovery key. If your Mac’s FileVault 2 recovery key is not being stored by Apple, you will not be able to use an Apple ID to reset your account’s ability to log into a FileVault 2-encrypted Mac.

For more details, see below the jump.

Here’s the procedure for resetting a forgotten account password using an account’s previously-registered Apple ID.

1. At the FileVault 2 pre-boot login screen, select the account in question.

2. Click on the question mark icon.

3. In the options displayed, click on the …reset it using your Apple ID option.

4. The Mac will reboot to your Mac’s recovery partition and access a Reset Password wizard.

5. When prompted, log in with your account’s associated Apple ID.

6. Depending on what type of account you have, the next few screens may be slightly different.

iCloud account

A. The Reset Password wizard will check the locked disk

B. The Mac will communicate back with Apple to match the iCloud user against the FileVault 2 recovery key that was stored with Apple.

C. The iCloud account will be re-enabled for FileVault 2

D. You’ll be prompted to restart. On login, your iCloud account password will be able to log in at the FileVault 2 pre-boot login screen.

Local or Mobile Network Account that’s associated with an Apple ID

A. The Reset Password wizard will check the locked disk.

B. The Mac will communicate back with Apple to match the Apple ID against the FileVault 2 recovery key that was stored with Apple.

C. You’ll be prompted to reset your account’s password to a new one.

Note: This may break the password sync for a mobile network account between the network account’s cached password on the Mac and the directory service.

D. You’ll be prompted to restart. On login, your now-reset account password will be able to log in at the FileVault 2 pre-boot login screen.

Apple has been warning folks for the past few OS releases that the /etc/hostconfig file was going away and it looks like they decided that Mavericks was the hostconfig file’s last hurrah.

As of OS X Yosemite, /etc/hostconfig is no longer installed as part of the OS.

Thanks to Dan O’Donnell for the heads-up:

A new feature that appeared in VMware Fusion 7 Pro was its new ESXi management. This included the ability to upload VMs from Fusion directly to an ESXi server. However, when I tried to upload OS X VMs something seemed to go wrong. The upload would work, but the OS X VM would then hang on boot.

Non-OS X VMs were uploading fine, so the problem was specific to OS X VMs. Since I could still build OS X VMs using the Windows vSphere client, I didn’t invest a lot of time into solving this issue. Fortunately, Calum Hunter was more motivated in this regard and found a solution.

There are a few things to know about if you want to upload an OS X VM to an ESXi server running 5.5, so I’ve put together a procedure for those who want to leverage Fusion 7 Pro to upload OS X VMs. See below the jump for the details.

There’s three issues to be aware of when uploading OS X VMs to ESXi 5.5:

1. ESXi 5.5 supports up to VMware’s Hardware Version 10.

2. VMware Fusion 7 Pro will build VMs by default using VMware’s Hardware Version 11.

3. The upload process to ESXi 5.5 will not tranfer the necessary smc.present = “TRUE” attribute from the Fusion VM’s .vmx configuration file. This attribute allows the VM to check and detect that it’s running on Apple hardware. Without this check succeeding, the VM assumes it’s running on non-Apple hardware and will then hang during the boot process (which is why I was seeing the hang in my previous upload attempts.)

Pre-requisites:

• VMware Fusion 7 Professional
• A fully-updated ESXi 5.5 server running on Apple hardware. As of October 31, 2014, the latest version should be ESXi 5.5 Patch03 (ESXi550-201410001).

Setting Fusion-built VMs to use Hardware Version 10

1. Create a new VM and choose an appropriate OS.

Note: If you’re planning to upload a 10.10 VM, choose OS X 10.9 in this window. VMware Fusion’s setup process will not allow a 10.10 VM to use Hardware Version 10. In my testing, 10.10 runs fine even when the VM’s selected OS is 10.9.

2. Once the VM is created and you’ve set your preferred memory, processor and memory settings, shut down the VM and then go into the VM settings.

3. In the VM settings, go into USB & Bluetooth

4. In the USB & Bluetooth settings, set it to use USB 2.0 instead of USB 3.0. USB 3.0 is a new feature with VMware’s Hardware Version 11 and not supported on Hardware Version 10.

5. Go back out to the VM settings, then select Camera.

6. In the Camera settings, click the Remove Camera button.

7. When prompted, confirm that you want to remove the camera by clicking the Remove button. The camera is a new feature with VMware’s Hardware Version 11 and not supported on Hardware Version 10.

8. Go back out to the VM settings, then select Compatibility.

9. Change the Use Hardware Version: setting to 10 and click the Apply button.

At this point, your OS X VM should be set to use Hardware Version 10 and ready for uploading to ESXi 5.5.

Connecting to ESXi 5.5 from VMware Fusion 7 Professional

1. Launch VMware Fusion 7 Professional if needed.

2. Under the File menu, select Connect to Server…

3. In the login window that appears, enter the server address of your ESXi server, username and password as appropriate.

Exporting VMs from VMware Fusion 7 Professional to ESXi

1. Shut down the Fusion VM that you want to copy to your ESXi server.

2. Connect to your ESXi server if you hadn’t previously.

3. Right-click on the shutdown VM and select Upload to Server…

4. If prompted, select your destination server and click the Continue button.

5. A new Upload Virtual Machine window will appear.

6. Select the ESXi datastore that you want to upload your Fusion-built VM into and click the Upload button.

7. The selected VM will upload to the ESXi server.

8. Once the upload is completed, the newly-uploaded VM will appear in your ESXi server’s list of VMs as a powered-off VM.

Editing the OS X VM’s .vmx file

Before booting your VM, you will need to edit the uploaded VM’s .vmx configuration file to add the smc.present = “TRUE” attribute back to the .vmx file. There’s a few ways to do this, but I used SSH and Cyberduck’s ability to edit remote files.

With TextWrangler set in Cyberduck as my preferred editor, here’s the procedure I used:

1. Connect to the ESXi server with Cyberduck via SFTP

2. Navigate to /vmfs/volumes/datastore_name_here/uploaded_vm_name_here/

3. Select /vmfs/volumes/datastore_name_here/uploaded_vm_name_here/uploaded_vm_name_here.vmx and click the Edit button in the Cyberduck browser window.

4. At the bottom of the uploaded_vm_name_here.vmx file, add the following entry:

smc.present = "TRUE"

5. Save the changes in TextWrangler. That save process will then enable Cyberduck to write the changes back to the uploaded VM’s uploaded_vm_name_here.vmx configuration file on the ESXi server.

6. Disconnect and then quit Cyberduck.

If you’re more comfortable editing these changes with the Windows vSphere client’s editor, first make sure you’re running the vSphere 5.5 Update 2 client. Once that’s sorted, you’ll need to add the following setting to the uploaded_vm_name_here.vmx configuration file:

Name: smc.present

Value: TRUE

Once the VM has been uploaded and the VM’s uploaded_vm_name_here.vmx configuration file has been edited, your ESXi-hosted OS X VM should now be ready to go.

I’ll be speaking at MacTech Conference 2014, which is taking place from November 5th – 7th in Los Angeles. I’ll be talking about documentation and the various lessons I’ve learned over the years that I’ve been writing it.

You can see the entire list of speakers at http://www.mactech.com/conference/sessions. If you’ve been on the fence about attending, it’s not too late! Come attend a great conference; seats are still available.

I’ve noticed that the Server.app installers for Mavericks and Mountain Lion have now vanished from my list of Purchases in the App Store, and searching for “OS X Server” will only give you the option of Server.app 4.0 for Yosemite. However, Server.app 2.2.5 for Mountain Lion and Server.app 3.2.2 for Mavericks are still available. You just need the right Mac App Store URL.

As of November 1, 2014, here are the Mac App Store URLs for Server.app 2.2.5 for OS X 10.8.5 and Server.app 3.2.2 for 10.9.5:

• Server.app 2.2.5: https://itunes.apple.com/us/app/os-x-server-2.2.5/id537441259?mt=12
• Server.app 3.2.2: https://itunes.apple.com/us/app/os-x-server-3.2.2/id714547929?mt=12

To help safeguard against a day where they may not be available at all, I recommend downloading a copy of the Server.app installer packages from the MAS.

JAMF Software has posted the session video for my virtualization session from JAMF Nation User Conference 2014.

For those interested, the JNUC session videos are available on JAMF Software’s site. For convenience, I’ve linked my session here.

Update: The session videos are also now available on YouTube, so I’ve linked the YouTube video as well.

For those who wanted a copy of my documentation talk at at MacTech Conference 2014, here are links to the slides in PDF and Keynote ’09 format.

PDF – http://tinyurl.com/MT2014DocPDF

Keynote – http://tinyurl.com/MT2014DocKeynote

I’ve been working with the folks at Peachpit to create a FileVault 2 training video, geared towards Mac admins that want to learn more about FileVault 2. I’m happy to say that they’ve let me know that it’s now available and can be purchased from the following link:

http://www.peachpit.com/store/filevault-2-for-mac-os-x-decoded-learn-by-video-9780134095844

This video covers OS X Mavericks, as Yosemite was still covered under NDA at the time I was working on this. That said, the vast majority of the FileVault 2 information covered in the video will also apply to Yosemite.

Michael Lynn was good enough to pull together the complete (at least as of tonight) list of Twitter and Instagram photo posts from MacTech 2014.

Since it’s rather a long list, I’m putting it below the jump. Enjoy!

Twitter

Instagram

Back in OS X 10.8.x, one of the newly-created fdesetup tool’s functions was to enable users for FileVault 2. To do so, you needed to provide both the username and password of either a previously enabled account or an admin account, as well as the password of the account you want to add.

One interesting twist was that the admin user in question did not themselves need to be enabled for FileVault 2. In my testing on 10.8.x, I found that an admin user could authorize the enabling of other accounts even if the admin account wasn’t enabled. An admin account could also enable itself using this process, by being both the authorizing admin account and the account being enabled.

In Mavericks and later, this behavior changed. If you’re using Mavericks or Yosemite, the fdesetup tool included with those operating systems now prevents non-enabled admin users from enabling other non-enabled users.

That seemed to close the book on non-enabled admin accounts being able to enable users for FileVault 2, until Google’s Macintosh Operations Team posted a script that they said would make a Mac unbootable.

As part of the discussion about that script, something really interesting was discovered. For more details, see below the jump.

At the time of posting, the script was designed to do the following:

If the Mac’s boot drive was FileVault 2-encrypted, the script:

1. Adds a new user called fde_locked_user with a random password.
2. Adds this user to the list of users who can unlock the disk.
3. Removes all other users.
4. Shuts down the machine.

If the Mac’s boot drive was not FileVault 2-encrypted, the script:

1. Renames /sbin/launchd to /sbin/launchd_disabled
2. Shuts down the machine

Unfortunately, as it was set up, the “If the Mac’s boot drive was FileVault 2-encrypted” part of the script didn’t work as intended when run on Mavericks or Yosemite. The reason it didn’t work as intended was that the script relied on Mountain Lion’s fdesetup behavior, where a non-enabled admin user (in this case, the root user) could enable the script-created “fde_locked_user” user account for FileVault 2.

When the script was run on Mavericks or Yosemite, non-enabled admin users could no longer enable accounts for FileVault 2. Testing on Mavericks and Yosemite showed that the “If the Mac’s boot drive was FileVault 2-encrypted” part of the script failed because fdesetup was not being provided acceptable authorization to enable the new fde_locked_user account that was being created by the script.

After some additional discussion and testing, it was discovered that it was possible to have the script work again as written on Mavericks and Yosemite, with one addition: the 10.8 version of the fdesetup tool.

As long as the 10.8 version of fdesetup is being used for the enablement process, it is possible to return to the Mountain Lion behavior of non-enabled admin users being able to enable accounts for FileVault 2. To take advantage of this, Google’s Macintosh Operations Team is now bundling the 10.8 fdesetup binary as part of the installer package that installs and runs their script.

Using the 10.8 fdesetup tool on 10.9.x and 10.10.x has been tested and verified to work on 10.9.x and on 10.10.0 / 10.10.1. It may break in future versions of OS X.

Update: I’ve opened a bug report with Apple about this behavior. For those that want to dupe it, the bug report ID is 18985048. For those interested in the details of the bug report, I’ve also posted the bug report to Open Radar:

http://openradar.appspot.com/radar?id=5306791864827904

Update 2: To presumably address any software distribution legal issues, Google has replaced the 10.8 fdesetup binary with a new Google-produced fdeadduser binary that has the same behavior in terms of enabling users for FileVault 2.

I’ve updated the create_vmware_osx_install_dmg.sh script which I had previously posted about here. The script now includes support for Yosemite, so the script can now be run on 10.7 – 10.10 to create custom OS X 10.7.x, 10.8.x, 10.9.x and 10.10.x installers for VMware Fusion and VMware ESXi. See below the jump for the details.

Downloading the script and support files

Download a .zip archive containing all needed files from my GitHub repo. This will give you both the create_vmware_osx_install_dmg script and a directory named support which contains files that the script will be copying into the completed disk image.

Both the create_vmware_osx_install_dmg script and the support directory must be stored in the same directory in order for the script to work properly.

Once you have the .zip archive download and uncompressed, go into the support directory and unzip the First_Boot_Package_Install.zip file. First Boot Package Install.pkg is used by the script so it’ll need to be unzipped and available before running the script.

Note: The First Boot Package Install.pkg included with this script will automatically install all available Apple software updates following the OS installation, but provide no other customization for the VM.

Creating a customized first boot package

If you want to have a first boot package that installs other packages at first boot, I’ve written a tool named First Boot Package Install Generator.app that will generate a first boot package that works with this script.

NOTE: The customized OS X installer will have an upper limit of 350 MBs of available space for added packages. This is sufficient space for basic configuration, payload-free or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers to this installer.

For details on how to use First Boot Package Install Generator.app to generate your first boot package, please see this post:

http://derflounder.wordpress.com/2014/10/19/first-boot-package-install-generator-app/

When using a first boot package with this script, the script has the following hard-coded requirements:

1. That the first boot package is named First Boot Package Install.pkg
2. That the first boot package is stored in the support directory.

Running the script to create a customized OS X install .dmg file

Once you have the first boot package available and configured to your preferences, run the create_vmware_osx_install_dmg script with two arguments:

1. The path to an Install OS X.app or the InstallESD.dmg contained within.
2. An directory to store the completed disk image in.

Example usage:

If you have a 10.10.0 Yosemite installer available, run this command:

sudo /path/to/create_vmware_osx_install_dmg.sh "/Applications/Install OS X Yosemite.app" /path/to/output_directory

When the command is run, you will be asked to choose whether or not you want to create an .ISO file for use with VMware ESXi.

If you had chosen to not create the .ISO file, this should produce a DMG file inside your selected output directory which is named something similar to OSX_InstallESD_10.10_14A389.dmg. This DMG will install both OS X 10.10.0 and the first boot package.

If you chose to create the .ISO, you should have two disk image files inside the chosen output directory which are named something similar to the following: OSX_InstallESD_10.10_14A389.dmg and OSX_InstallESD_10.10_14A389.iso

Creating a VM with the customized OS X install .dmg file

1. Launch VMWare Fusion 7.x

2. In VMWare Fusion, select New… under the File menu to set up a new VM

3. In the Select the Installation Method window, select Install from disc or image.

4. In the Create a New Virtual Machine window, click on the Use another disc or disc image… button.

5. Select your customized OS X install disk image file and click on the Open button.

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the disk image file you want is selected, then click the Continue button.

7. In the Choose Operating System window, set OS as appropriate then click the Continue button.

In this example, I’m setting it as follows:

Operating System: Apple OS X

Version: 10.10

8. In the Finish window, select the Customize Settings button if desired. Otherwise, click the Finish button.

9. Save the VM file in a convenient location.

The VM is now configured and set to use the customized OS X installer disk image. To install OS X and the packages included with your first boot package, start the VM and then do nothing. The VM should begin automatically installing OS X on the VM’s boot drive, followed by the installation of the first boot package.

If you want to build a customized version of this script, the script and its associated files are available on Github at the following address:

https://github.com/rtrouton/create_os_x_vm_install_dmg

When I updated to 10.10.1 yesterday, as part of the restart process I noticed that I was seeing the Diagnostics pop-up window appear on login.

I had previously suppressed this window as part of setting up this machine, but it looks like the LastSeenBuddyBuildVersion value in /Users/username/Library/Preferences/com.apple.SetupAssistant.plist had the build number for 10.10.0 stored and it needed to be updated with the build number of 10.10.1 in order to suppress the Diagnostics pop-up window again.

Fortunately, this can be addressed by setting up an automated run of my iCloud / Diagnostics suppression script with Casper. This should automatically update the LastSeenBuddyBuildVersion value in /Users/username/Library/Preferences/com.apple.SetupAssistant.plist with the build number for the current version of 10.10.x. For more details, see below the jump.

To help automate this process, I first added the iCloud / Diagnostics suppression script to my Casper server.

After adding the script, I set up a Casper policy that automatically runs this script at startup.

To help ensure that this script also runs when the Mac cannot contact my Casper server, I’ve set Execution Frequency to Ongoing, as that allows me to select the Make Available Offline option.

The policy is scoped to a smart group that contains only 10.10.x Macs.

One of the pop-up windows you get on first login to Yosemite is the Diagnostics & Usage pop-up window. This window requests permission for the following:

1. Send diagnostics and usage data to Apple
2. Share crash data with non-Apple developers

I’ve been suppressing this window without setting those diagnostic reporting settings, but Mac admins may also want to apply those settings as part of building their machines. Thanks to investigative work by Tim Sutton, it looks like it’s possible to control those settings by setting the correct values in the /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist file.

<key>AutoSubmitVersion</key>
<integer>4</integer>
<key>AutoSubmit</key>
<false/>
<key>ThirdPartyDataSubmitVersion</key>
<integer>4</integer>
<key>ThirdPartyDataSubmit</key>
<false/>

For more details, see below the jump.

An important side-benefit of setting these values is that it also appears to suppress the Diagnostics & Usage pop-window, since the pop-up window appears to allow those settings to be chosen. In my testing, I verified that applying these settings to a unconfigured factory-fresh 10.10.0 Mac before the first login prevented the Diagnostics & Usage pop-up window from appearing. The Diagnostics & Usage window also did not appear after upgrading the Mac to 10.10.1.

I’ve built a script to assist Mac admins with applying the desired settings for their own shop. It’s available from below, and also from my GitHub repo.

This script sets whether you want to send diagnostic info from Yosemite and later back to Apple and/or third party app developers by setting the appropriate values in /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist.

If you want to send diagnostic and usage data to Apple, set the following value in the script for the SUBMIT_DIAGNOSTIC_DATA_TO_APPLE value:

SUBMIT_DIAGNOSTIC_DATA_TO_APPLE=TRUE

If you want to send crash data to non-Apple developers, set the following value in the script for the SUBMIT_DIAGNOSTIC_DATA_TO_APP_DEVELOPERS value:

SUBMIT_DIAGNOSTIC_DATA_TO_APP_DEVELOPERS=TRUE

By default, the values in this script are set to send no diagnostic data, either to Apple or to non-Apple developers:

SUBMIT_DIAGNOSTIC_DATA_TO_APPLE=FALSE

SUBMIT_DIAGNOSTIC_DATA_TO_APP_DEVELOPERS=FALSE

To change these settings in the script, comment out the FALSE lines and uncomment the TRUE lines as appropriate.

When VMware released VMware Fusion 7 Professional in September 2014, among the new items included in the Features list was this one:

The ability to access virtual machines running on VMware vSphere, VMware ESXi, and VMware Workstation directly from VMware Fusion Pro including:

• Remote display, keyboard, and mouse control
• Ability to select media for CD, DVD, floppy devices, including files on your Mac
  
• Ability to power virtual machines on and off and configure the network they connect to
  
• Ability to move virtual machines from your Mac to a remote location by dragging and dropping
  
• Ability to move virtual machines from a remote location to your Mac by dragging and dropping
  
• See the state of your remote server with at-a-glance health summary based on Activity Monitor

What this new feature meant for Mac admins was that they now had a native Mac application which they could use when managing virtual machines (VMs) on VMware’s ESXi or vSphere services. The capabilities are not as full-featured as you may find in the Windows VMware vSphere client or the vSphere web client, but they are equivalent to the ESXi or vSphere management capabilities that VMware has been building into VMware Workstation for Windows. For more details, see below the jump.

Accessing ESXi servers using VMware Fusion Professional

To get started, you can use the following procedure to connect to an ESXi server from VMware Fusion Professional:

1. Launch VMware Fusion 7 Professional.

2. Under the File menu, select Connect to Server…

3. Enter the server address, username and password as appropriate.

4. If your ESXi server is using a self-signed certificate, you’ll be warned about it.

5. Next, you should see a new section appear under the Virtual Machines list with the name of your ESXi server.

Once you’re connected, if you click on the name of your ESXi server, you’ll be given information on the status of your ESXi server.

Clicking on the individual VMs will give you the ability to access the VM’s settings, as well as power on, power off, restart, suspend and make snapshots.

One important thing to know is that the VMware Tools need to be installed in the VMs in order to get full management functionality. For example, if the VMware Tools are not installed in a particular VM, the function to power off that VM will not be available in the ESXi management options in VMware Fusion Professional.

To remotely administer an ESXi-hosted VM, double-click on one of the listed VMs. A console window should open up and give you direct access to the VM.

Exporting virtual machines between VMware Fusion and ESXi

As mentioned previously, one of the new capabilities in VMware Fusion 7 Professional is the ability to move virtual machines to and from your ESXi server. To upload a VMware Fusion-built VM to your ESXi server, use the following procedure:

1. Launch VMware Fusion 7 Professional if needed.

2. Verify that the VM that you want to copy to your ESXi server is shut down.

3. Connect to your ESXi server if needed.

4. Right-click on the shutdown VM and select Upload to Server…

5. If prompted, select your destination server and click the Continue button.

6. A new Upload Virtual Machine window will appear.

7. Select the ESXi datastore that you want to upload your Fusion-built VM into and click the Upload button.

8. The selected VM will upload to the ESXi server.

9. Once uploaded, the VM will appear in the list of your ESXi VMs as a shutdown VM.

Once uploaded, the selected VM can access media stored either locally on your Mac or on the ESXi server. As an example, here’s how to attach an ISO disc image file stored on your ESXi server to an ESXi-hosted VM.

1. Launch VMware Fusion 7 Professional if needed.

2. Connect to your ESXi server if needed.

3. Open your VM’s settings

4. Select CD/DVD from your VM settings

5. Select Choose a remote disc image… from the drop-down menu in the CD/DVD settings.

6. Select the datastore on your ESXi server where the desired ISO disc image is stored.

7. Once the desired ISO disc image file is found, select it and click the Open button.

8. Verify that the desired ISO disc image is selected and that the VM is configured to use it.

9. Check the Connect At Power On checkbox. This step is very important, or the ISO disc image will not mount or otherwise be available to the VM.

To download an ESXi-hosted VM into VMware Fusion, use the following procedure:

1. Launch VMware Fusion 7 Professional if needed.

2. Connect to your ESXi server if needed.

3. Shut down the ESXi-hosted VM that you want to copy to VMware Fusion on your Mac.

4. Right-click on the desired VM and select Download from Server…

5. Select where you want to save the downloaded VM and click the Save button.

6. The selected VM will be downloaded to your Mac.

7. Once downloaded, the VM will be added to your list of virtual machines in VMware Fusion Professional.

There are three issues to be aware of when uploading or downloading VMs between VMware Fusion and ESXi 5.5:

1. ESXi 5.5 supports up to VMware’s Hardware Version 10 for hosting virtual machines.
2. VMware Fusion 7 Pro will build VMs by default using VMware’s Hardware Version 11.
3. For OS X VMs: Upload and download processes involving ESXi will not transfer the necessary smc.present = “TRUE” attribute for an OS X VM’s .vmx configuration file.

The smc.present = “TRUE” attribute allows a VM with OS X as the guest OS to check and detect that it’s running on Apple hardware. Without this check succeeding, the VM cannot verify it’s running on non-Apple hardware. Unless that check succeeds, OS X VMs will not complete startup successfully and will appear to hang.

Linux and Windows VMs do not need the smc.present = “TRUE” attribute, so those VMs running those OSs are unaffected by this issue.

Note: Uploading an OS X VM to an ESXi server assumes the ESXi server in question is running on Apple hardware. VMware does not support running OS X VMs on non-Apple hardware.

It is possible to address the VMware Hardware Version issue in VMware Fusion before uploading VMs to an ESXi 5.5. server. To enable Fusion 7-built VMs to use Hardware Version 10, use the following procedure:

1. Launch VMware Fusion 7 Professional if needed.

2. Verify that the virtual machine you want to edit is completely shut down. In this example, I’m using an OS X VM.

3. Open the VM settings and go into the USB & Bluetooth settings.

4. In the USB & Bluetooth settings, set it to use USB 2.0 instead of USB 3.0. USB 3.0 support is a new feature with VMware’s Hardware Version 11 and not supported on Hardware Version 10.

5. Go back out to the VM settings, then select Camera.

6. In the Camera settings, click the Remove Camera button.

7. When prompted, confirm that you want to remove the camera by clicking the Remove button. The camera is a new feature with VMware’s Hardware Version 11 and not supported on Hardware Version 10.

8. Go back out to the VM settings, then select Compatibility.

9. Change the Use Hardware Version: setting to 10

10. Once you’ve verified that the VM is set to use Hardware Version 10, click the Apply button.

At this point, your OS X VM should be set to use VMware’s Hardware Version 10, which will allow it to be uploaded to an ESXi 5.5 server.

If the VM in question is an OS X VM, you will need to edit the uploaded VM’s .vmx configuration file to add the smc.present = “TRUE” attribute attribute back to the VM’s .vmx configuration file before the VM will be able to boot. There’s a few ways to do this, but I have used the open-source Cyberduck FTP / SFTP applications’s ability to edit remote files in order to do this.

Here’s the procedure I have used to edit an uploaded OS X VM’s .vmx configuration file using Cyberduck. In this case, I have set the TextWrangler text editing application in Cyberduck’s preferences as my preferred editor:

1. Verify that my ESXi server is running on Apple hardware

2. Verify that the uploaded OS X VM is shut down on the ESXi server.

3. Verify that SSH is enabled on the ESXi server.

4. Connect to the ESXi server with Cyberduck via SFTP

5. Navigate to /vmfs/volumes/datastore_name_here/uploaded_vm_name_here/

6. Select /vmfs/volumes/datastore_name_here/uploaded_vm_name_here/uploaded_vm_name_here.vmx and click the Edit button in the Cyberduck browser window.

7. At the bottom of the uploaded_vm_name_here.vmx file, add the following entry:

smc.present = "TRUE"

8. Save the changes in TextWrangler. That save process will then enable Cyberduck to write the changes back to the uploaded_vm_name_here.vmx configuration file on the ESXi server.

9. Disconnect and then quit Cyberduck.

Once the VM has been uploaded and the VM’s uploaded_vm_name_here.vmx configuration file has been edited, your ESXi-hosted OS X VM can now be started and will boot normally.

If you have downloaded an OS X VM from an ESXi server to VMware Fusion Professional, you will also need to edit the downloaded VM’s .vmx configuration file to add the smc.present = “TRUE” attribute back to the VM’s .vmx configuration file before the VM will be able to boot.

Here’s how you can add the smc.present = “TRUE” attribute using the editing tools available with VMware Fusion Professional.

1. Launch VMware Fusion 7 Professional if needed.

2. Verify that the virtual machine you want to edit is completely shut down.

3. Select the VM you want to edit.

5. Hold down the Option key on your keyboard and right-click the virtual machine.

6. Select Open Config File in Editor in the menu that appears. This will open up the VM’s .vmx configuration file for editing.

7. At the bottom of the VM’s .vmx configuration file, add the following entry:

smc.present = "TRUE"

8. Once your edits are finished, go up to the File menu and select Save to save your changes.

As a Mac admin who leverages virtualization, I have found that VMware’s addition of these new ESXi management features to Fusion Professional has made managing ESXi much easier. Being able to manage ESXi servers that are using either VMware’s free ESXi license, or a paid vSphere license with a native application, eliminated a considerable amount of overhead for me with regards to ESXi management.

Where previously I would have to devote time and resources towards having a Windows PC or VM available to manage a free ESXi server, I can now open VMware Fusion Professional and be able to manage my ESXi servers using the same tool that I’m already using to run my virtual machines on my Mac. That has made ESXi management an easier and more seamless experience for me. Hopefully, it will do the same for you.

Additional links

VMWare Fusion documentation center

VMware Fusion – Upload a Virtual Machine to a Remote Server

VMware Fusion – Download a Virtual Machine from a Remote Server

VMware Fusion – View the Status of a Server or Remote Virtual Machine

VMware Fusion – Enable a CD/DVD Drive on a Remote Virtual Machine

VMware Fusion – Enable a Floppy Drive on a Remote Virtual Machine

With the release of Sophos Anti-Virus 9.x, Sophos changed how their antivirus solution for Macs was installed. Where previous versions of Sophos used an installer package, Sophos has now switched to using an application to install their antivirus.

This switch was a problem for Mac admins who wanted to deploy Sophos Home Edition 9.x for personal use, as there was not an available installer package to simplify the task of deployment. Sophos Home Edition 9.2.x added additional complexity by storing many of the installer’s files and other components outside the installer in a separate Sophos Installer Components directory.

However, after doing some research and testing, it looks like it is possible to repackage Sophos Home Edition 9.2.x for personal deployment. For more details, see below the jump.

Sophos’ installer application can be run from the command line using the InstallationDeployer tool and include both install and remove switches. Here’s how to install and uninstall Sophos 9.x using the free Sophos Home Edition installer application:

Install:

/path/to/Sophos\ Anti-Virus\ Home\ Edition.app/Contents/MacOS/InstallationDeployer --install

Uninstall:

/Library/Application\ Support/Sophos/he/Installer.app/Contents/MacOS/InstallationDeployer --remove

With these commands, it’s possible to add the Sophos install application and the Sophos Installer Components directory to an installer package and run the needed command(s) as a postinstall script.

Once I had this information and understood what was going on, here’s how I repackaged Sophos Anti-Virus Home Edition 9.2.x so that it could be deployed via an installer package.

Prerequisites:

• Packages
• Sophos Home Edition 9.2.x install application and the associated Sophos Installer Components directory.

1. Set up a new Packages project and select Raw Package.

2. In this case, I’m naming the project Sophos Anti-Virus Home Edition 9.2.2.

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

• In the Post-Installation Behavior section, set On Success: to Do Nothing.
• In the Options section, check the box for Require admin password for installation.

5. Click on the Scripts tab in your Packages project.

6. Select the Sophos Home Edition install application and the associated Sophos Installer Components directory, then drag both into the Additional Resources section of your Packages project.

7. The last piece is telling the Sophos install application to run. For this, you’ll need a postinstall script. Here’s the one I’m using:

8. Once you’ve got the postinstall script built, run the following command to make the script executable:

sudo chmod a+x /path/to/postinstall

9. Once completed, add the postinstall script to your Packages project.

10. Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by taking it to a test machine where Sophos is not installed and install it. The end result should be that Sophos Anti-Virus Home Edition installs properly.

Note: If you’re installing Sophos Home Edition, it should be for personal use only. I would not recommend using Home Edition at a business because that’s not what it’s meant for. For more information, the governing EULA here is Sophos’ End User License Agreement for Consumers (see the RIGHTS AND RESTRICTIONS section):

http://www.sophos.com/en-us/legal/sophos-end-user-license-agreement-for-consumers.aspx

In 10.10.0 and 10.10.1, I’ve noticed an issue when enabling FileVault 2 via System Preferences when using an institutional recovery key.

In Mavericks and earlier versions of OS X, the behavior of System Preferences looked like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A list of users that can be enabled for FileVault 2 is displayed. The logged-in user account is marked with the green checkbox that shows that the account is enabled.
4. A message is displayed that a recovery key has been set by a company, school or institution.
5. A message prompting the user to restart is displayed.
6. Once the Restart button has been clicked, the FileVault 2 initialization process continues and restarts the Mac.
7. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

In Yosemite 10.10.0 and 10.10.1, the behavior of System Preferences looks like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A message is displayed that a recovery key has been set by a company, school or institution.
4. System Preferences then displays no additional messages and will appear to hang for up to two minutes.
5. The Mac restarts without further input from the user.
6. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

As Yosemite’s current behavior is different and omits several steps that were present in previous versions of OS X, I believe this is a bug in Yosemite instead of intended behavior.

To help get it fixed, I’ve filed a bug report. For those interested in duping it, it’s bug ID 19124344.

For those interested in the details, I’ve also posted the bug report to Open Radar:

http://openradar.appspot.com/19124344

After upgrading to OS X 10.10.x, I noticed that pushing the volume buttons didn’t produce a noise like they had before. I liked having that feedback sound, as it gave me an idea of how loud my volume was.

After some research, here’s how to get the volume button noise back:

1. Open System Preferences.

2. Go to the Sound preference pane

3. Click on the Sound Effects tab.

4. Check the Play feedback when volume is changed checkbox.

To test, tap a volume button on your keyboard and you should once again get a feedback noise.

Being able to virtualize OS X with VMware Fusion has been a great tool for Mac admins, as it allows them to test out new workflows and configurations before committing them to actual Macs. To go along with the convenience, there can be a performance trade-off between VMs and physical Macs, but it’s usually been one where assigning adequate RAM and processors to the VMware Fusion VM usually resulted in decent performance in the VM.

This changed with Yosemite, where the graphics performance in a VM was sluggish and assigning more RAM and processors to a VM did not address the issue. Even ensuring that the VMware Tools were installed did not markedly improve performance. I also saw redraw issue involving windows that had been in the background and hidden behind other windows. These windows were not redrawing correctly when they were selected and brought to the foreground, resulting in parts of windows showing up as being transparent.

On investigation, the root cause of the issue was beam synchronization, which is a technique first introduced in 10.4.x to better handle screen redraw and allow OS X’s window management process to be more efficient. Beam synchronization works fine on Yosemite when running on actual machines, but it is apparently a significant issue when running in a VMware VM.

Fortunately, the answer to the problem is relatively simple – disable beam synchronization. Once that’s done, the performance of an OS X VM running 10.10.x improves dramatically. However, there were two hitches:

1. The way to disable it was to use Apple’s Quartz Debug developer tool.
2. You had to disable it on every login.

Enter BeamOff, an application designed to do one thing – disable beam synchronization. For more details, see below the jump.

BeamOff was written by JasF, who developed BeamOff to fix the performance issue he was having with Yosemite VMs. JasF posted the source files to GitHub and a compiled version of the application as part of this thread on the InsanelyMac forums.

When BeamOff runs, you should see it appear briefly in the dock and bounce once or twice as it runs. Once it has finished disabling beam sync, it then quits automatically.

When I tested the compiled BeamOff application, I saw a considerable improvement in how fast the VM was now responding. The window redraw issues I had previously seen were now also addressed, with windows now being refreshed correctly regardless if they were in the background or foreground.

Because I wanted to have BeamOff run automatically, I installed it in the /Applications directory of my Yosemite VM and wrote the following LaunchAgent to launch and run BeamOff on login:

To assist other Mac admins who are also dealing with this issue, I’ve also built and posted an installer for BeamOff and the LaunchAgent, which is available as a .zip file from the installer directory. The installer adds BeamOff to /Applications and installs the LaunchAgent to /Library/LaunchAgents.

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/fix_yosemite_vm_graphic_performance

For those interested in building their own installer, I’ve also posted a copy of the compiled BeamOff application, the LaunchAgent and the Packages project files I used to build the BeamOff installer. Those are available in the resources directory up on my repo:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/fix_yosemite_vm_graphic_performance/resources

One of the changes Apple made between Mountain Lion and Mavericks was how XProtect was updated. On 10.6.x – 10.8.x, Apple used /usr/libexec/XProtectUpdater to update XProtect’s blacklist. If you needed to force XProtect to update, you could run the following command with root privileges:

/usr/libexec/XProtectUpdater

Running that command with root privileges would force a check-in with Apple’s XProtect feed. If XProtect needed an update, running this command would check the current XProtect blacklist, detect that the online version was newer and pull down the new version. Once the new version had downloaded, XProtectUpdater would then exit.

If XProtect was up to date, running this command would check the current XProtect blacklist and detect that the online version was the same as what was currently loaded on the system. XProtect would then produce a notification that it was ignoring the update because the online version was not newer than the one already on the system. XProtectUpdater would then exit.

In 10.9.x and continuing on in 10.10.x, Apple moved the XProtect updates into Apple’s software update feed. As part of this change, the previous way of forcing XProtect by running /usr/libexec/XProtectUpdater no longer worked because /usr/libexec/XProtectUpdater did not exist on 10.9.x and higher.

Instead, you now need to use the softwareupdate command to force the update process. For more details, see below the jump.

If you need to force XProtect to update on Mavericks or Yosemite, run the following command with root privileges:

softwareupdate --background-critical

The –background-critical function is actually an undocumented softwareupdate function, so it’s not listed when you run either softwareupdate –help or when you check the softwareupdate man page. In the case of XProtect, softwareupdate –background-critical performs the same function that /usr/libexec/XProtectUpdater did for Macs running 10.6.x – 10.8.x:

1. Checking to see if the Mac has the current XProtect blacklist
2. Updating the system’s XProtect blacklist if needed

One important thing to know about forcing XProtect updates on Mavericks and Yosemite is that the Software Update function on the system in question must be set to automatically check for updates. Based on my testing, if the automatic check for updates is disabled, XProtect will no longer receive updates. This applies even if you run the softwareupdate –background-critical command to force an update to XProtect’s blacklist.

To control the automatic update check from the command line, run the following commands with root privileges:

To enable the automatic update check:

softwareupdate --schedule on

To disable the automatic update check:

softwareupdate --schedule off

You can also manage this on Mavericks and Yosemite from System Preferences using the following procedure:

1. Open System Preferences

2. Select the App Store preferences

3. Check or uncheck Automatically check for updates (should be checked by default.)

One of the changes that Steve Jobs briefly mentioned in the course of the WWDC 2011 keynote address was that Apple had revamped its FileVault encryption solution for Mac OS X 10.7.x, changing it from encryption that primarily protected your accounts home folder to encryption that protects your whole boot volume. Since that initial announcement, FileVault 2 has evolved into an encryption solution that can be easily managed by both home users and enterprises alike.

That said, almost every technology solution has details and parts that aren’t generally well known and FileVault 2 is not different in that regard. To help Mac admins who are managing FileVault 2 in their own environment, I’ve put together a list of 10 things I’ve run across in my work with FileVault 2 that I’ve either been asked about frequently or which seem to be completely undocumented by Apple. Most of these I’ve previously documented in one form or another, so some of these may seem familiar. See below the jump for the list.

1. Password Changes And FileVault 2

FileVault 2 has a nifty password update procedure for its enabled accounts (i.e. the accounts that show up at the pre-boot login screen) If you change your accounts password, the OS will automatically and invisibly update your FileVault 2 pre-boot login. This helps ensure that your account is consistently using the same password across the board. For local accounts, this password update is triggered when changing the local accounts password via the Users & Groups preference pane in System Preferences.

If a FileVault 2-enabled account is an Active Directory or Open Directory mobile account (where the accounts password is being managed by the Active Directory or Open Directory directory service), it’s possible to change your password for your account without your Macs OS being aware of it. For example, many worksites have a policy that you must change your password on a scheduled interval and also provide a website where you can change your password. If your encrypted Mac was offline at the time that your password was changed, it may not receive that password change until the next time you start up.

In a case like this, here’s how the password update process should work:

1. The mobile account’s password gets changed outside the Mac.

2. You boot your encrypted Mac while connected to a network that allows connections between your Mac and the directory service that manages the account’s password.

3. The pre-boot login screen would accept the account’s old password.

The pre-boot login is taking the old password here because the OS is not running at this point in the boot process, and the Mac is unable to communicate with the directory service that manages the accounts password.

4. Next, you get the OS’s login window and type the accounts new password there. Since the OS is running at this point, it can communicate with the directory service and learn that the account has a new password. Once the new password has been accepted, the OS will allow the login process to complete and it will also update the FileVault 2 pre-boot login to use the new password.

5. After the new password has been accepted, the Mac should provide the option to update the login keychains password.

Once updated, the login keychain should be using the account’s new password as well.

2. The Guest User And FileVault 2

One unusual feature of FileVault 2 is that sometimes a Guest User icon will appear at the pre-boot login screen.

When you log in as that guest user, you don’t get access to your hard drive. The only thing you get access to is Safari and a network connection. Quitting out of Safari will return you to the FileVault 2 pre-boot login screen.

To my knowledge, Apple has never commented specifically about this guest user but it appears the guest user is an anti-theft measure. The guest user’s appearance at the pre-boot login screen is a feature tied to signing into iCloud and enabling the Find My Mac option.

One consequence of logging into the guest user is that, as soon as the Mac gets a network connection, it will immediately connect back to Apple and report its location information.

If you don’t sign in with iCloud and then enable Find My Mac from that machine, the Guest User icon will not appear on the FileVault pre-boot login screen. That said, mobile device management solutions that track a machine’s location may also trigger the Guest User icon to appear.

3. Enabling Non-Enabled Admin Users For FileVault 2 Via System Preferences

One challenge for Mac admins is figuring out ways to enable users for FileVault 2. One approach to enable non-enabled accounts that have administrative privileges is the following:

1. Log in at the OS login window as the non-enabled admin account.

2. Open System Preferences and go to the FileVault preference pane

3. Click the lock to unlock the FileVault preference pane and authenticate when prompted.

4. Click the Enable Users button in the FileVault preference pane

5. The previously non-enabled admin user account will appear with a green checkbox to show that the account has been enabled for FileVault 2.

This approach to allow admin users to enable themselves for FileVault 2 has worked since FileVault 2 was first introduced in Lion and it continues to work in Yosemite.

4. Creating An Institutional Recovery Key

If you want to use an institutional recovery key on FileVault 2 encrypted Macs, you will need to create and configure a FileVaultMaster keychain. Apple has provided a way to create this keychain by using the security command’s create-filevaultmaster-keychain function. To create a FileVaultMaster.keychain file, run the following command in the Terminal:

security create-filevaultmaster-keychain /path/to/FileVaultMaster.keychain

You’ll be prompted for a password for the keychain. When provided, the keychain will be created and will contain both the private and public keys needed for recovering a FileVault 2-encrypted drive that uses this institutional recovery key.

Make copies of the keychain and store them in a safe place. Also make sure to securely store copies of the password you used to create the keychain.

If you want to create the FileVaultMaster keychain in its proper place, run the security command with root privileges and use /Library/Keychains for the destination path.

Once you’ve made your copies, make another copy and remove the private key from that copy of the keychain. Once the private key is removed, the FileVaultMaster.keychain file is ready to be used for encrypting Macs with FileVault 2 with the institutional recovery key.

It doesn’t appear that the security man page includes information about the create-filevaultmaster-keychain function, but you can see what it does by running the security help command in the Terminal and checking at the bottom of the list that appears.

A way to modify /Library/Keychains/FileVaultMaster.keychain so that it only has the public key inside would be to do the following:

1. Create the FileVaultMaster.keychain file using the security command.

2. Next, make several copies of the FileVaultMaster.keychain file that you just created and store the copies separately in secure locations. A locked safe would be a good place, or in an encrypted disk image that is on an access-restricted file share.

3. Next, unlock the newly-created FileVaultMaster.keychain file by running the following command and entering the keychain’s password when prompted for the password:

security unlock-keychain /Library/Keychains/FileVaultMaster.keychain

Note: The FileVaultMaster keychain will need to be unlocked from the command-line as the keychain will not unlock in Keychain Access by clicking on the lock.

4. If it succeeds, you’ll get the next system prompt. If not, get another copy of the FileVaultMaster.keychain file and try again. A FileVaultMaster.keychain file with an unknown password should not be used because there is no way to use it for recovery purposes without first knowing the keychains current password.

5. Once you’ve unlocked the FileVaultMaster.keychain file, open the Keychain Access application from /Applications/Utilities/.

6. In Keychain Access, go to File: Add Keychain and add /Library/Keychains/FileVaultMaster.keychain.

7. Assuming you previously unlocked the FileVaultMaster.keychain file using the security command, it should show up as unlocked in Keychain Access.

8. Go into the FileVaultMaster keychain and remove the private key. (It should be called FileVault Master Password Key and its kind should be listed as private key.)

9. Relock the FileVaultMaster keychain

10. Copy the modified FileVaultMaster.keychain file (now with only the public key inside) to the /Library/Keychains directory of the Macs you want to encrypt with FileVault 2. For ease of deployment, you can package the FileVaultMaster.keychain file into an installer package. That installer package can then be deployed ahead of encryption to multiple machines using the system management tools used in your environment.

When deployed to /Library/Keychains on the Macs you want to encrypt with FileVault 2, the FileVaultMaster.keychain file should have the following permissions set:

Owner: root

Permissions: read and write

Group: wheel

Permissions: read only

Everyone

Permissions: read-only

Once the institutional recovery key is deployed to an unencrypted machine, enabling FileVault 2 via System Preferences should produce a message stating that A recovery key has been set by your company, school or institution instead of displaying the personal recovery key.

5. Erasing A FileVault 2-Encrypted Volume From The Command Line

On occasion, it’s necessary to erase a FileVault 2-encrypted volume. However, sometimes Disk Utility won’t let you erase or repartition an encrypted drive until you unlock or decrypt. This can be an issue for a malfunctioning FileVault 2-encrypted volume that will not let you either unlock or decrypt.

To help with this, the diskutil tool provides a way to quickly delete CoreStorage volumes from the command line. This includes the ability to erase encrypted CoreStorage volumes (aka FileVault 2-encrypted volumes) without first deleting them.

To do this, first run the following command in the Terminal:

diskutil cs list

This will give you with a list of the CoreStorage volumes on your system. Unless you have a Fusion drive or multiple encrypted drives, your FileVault 2-encrypted drive should be the only one listed.

In the listing, you will want to select and copy the Logical Volume Group (LVG) alphanumeric UUID for your CoreStorage volume. The LVG should be the first UUID listed and its the one we want to delete.

Next, run the following command in the Terminal:

diskutil cs delete UUID_here

This command will delete the encrypted CoreStorage volume and reformat it as an unencrypted HFS+ volume.

6. Setting A Text-Only Login Banner For The FileVault 2 Pre-Boot Login Screen From The Command Line

It is possible to set a text-only banner message that appears in the following locations:

1. The FileVault 2 pre-boot login screen

2. The OS login window

3. The screensaver lock window

Brevity is best, as staying within a maximum of three lines will permit the banner text to be consistently displayed in all three locations. Exceeding the three-line limit may result in the text being cut off and not fully displayed.

You can set this banner text from the command line using the following defaults command, which should be run with root privileges:

defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"

However, if these functions were enabled from the command using the defaults command, they may show up at the OS login window and the screensaver lock window, but not the FileVault 2 pre-boot login screen.

The answer seems to be that, in addition to running the defaults commands, you also need to manually update the /System/Library/PrivateFrameworks/EFILogin.framework using the touch command. By running the touch command on the right part of the EFILogin framework, the OS will force the system to update the FileVault 2 pre-boot login screen to use the banner text.

For example, running the following commands with root privileges updates the FileVault 2 pre-boot login screen with a login banner:

defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"

touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources

On restart, the FileVault 2 pre-boot login screen should look like this, with the banner text now showing.

To remove these, you would need to boot back into the OS and run the following commands in the Terminal with root privileges:

defaults delete /Library/Preferences/com.apple.loginwindow LoginwindowText

touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources

On restart, the text should no longer appear at the FileVault 2 pre-boot login screen, the OS login window or the screensaver lock window.

7. Booting Into Single-User Mode On A FileVault 2-Encrypted Mac

A while back, I communicated with a Mac admin who was concerned about using FileVault 2 in his environment because he didnt want to lose access to tools like single-user mode. Like a number of Mac admins, hed found single-user mode valuable in helping to diagnose and fix issues on troublesome Macs.

Fortunately, Apple makes it reasonably easy to boot into single-user mode on a FileVault 2-encrypted system. here’s how to boot into single-user on a FileVault 2-encrypted system:

1. Hold down Command-S after powering the system.

2. The Mac will be begin booting into single user, then the FileVault 2 pre-boot login screen will appear.

3. Authenticate at the FileVault 2 pre-boot login screen by selecting an account and providing the accounts password.

4. The Mac will then unlock and continue booting into single-user mode.

8. Using Apple’s Internet Recovery To Unlock Or Decrypt Your FileVault 2-Encrypted Boot Drive

One of the new features that appeared with Macs that shipped with Mac OS X 10.7.x and later versions of OS X was Apple’s Internet Recovery. If you encounter a situation in which you cannot start from the Mac’s Recovery HD partition, such as where the internal hard drive has failed or when you’ve installed a new disk without an OS on it, Mac models that were released after July 2011 can use Internet Recovery. Internet Recovery lets you start your Mac directly from Apple’s servers using a NetBoot-like process and gives you the same functionality that Recovery HD does.

Because Internet Recovery has the same capabilities as your Macs Recovery HD partition, it can be used to unlock or decrypt a FileVault 2-encrypted Mac. This is potentially valuable in case of emergency, as it means that you can do recovery of a FileVault-encrypted drive even in a situation where the Macs Recovery HD partition has been damaged or corrupted in some way.

To force your Mac to boot to Internet Recovery, start up your Mac and hold down Command-Option-R on your keyboard. You should see a gray screen with an animated globe appear and display a message similar to Starting Internet Recovery. This may take a while.

Depending on your connection speed, it may also switch to a countdown clock to show you how long until its fully booted.

Once booted to Internet Recovery, you should see the Recovery interface and the available tools.

From there, you should be able to use Disk Utility or the Terminal applications to unlock or decrypt your FileVault 2-encrypted Mac.

9. FileVault 2 And UUIDs

A little-known fact about FileVault 2 is that it uses the GeneratedUID user attribute (also known as a UUID) of an account to help identify enabled accounts. For example, when you run the fdesetup list command in the Terminal, you’ll see the user information for FileVault 2-enabled accounts appear with both the username and UUID information.

For local accounts, the OS will properly generate a GeneratedUID user attribute to provide a UUID for the local account. Active Directory also generally handles this correctly on Macs, so I haven’t seen UUID problems occur for AD mobile users.

Where I’ve heard of problems have been with Macs bound to non-Apple LDAP servers. If the LDAP server doesn’t provide the GeneratedUID user attribute for its accounts, or it does not provide the UUID in the way that FileVault 2 is expecting, you may see one or more of the following behaviors:

• The LDAP account’s icon disappearing from the FileVault 2 pre-boot login screen – This behavior is generally caused by the GeneratedUID attribute not being set for the LDAP account.
• The account icon being present, but the password not matching the current password on the LDAP server – This behavior has been observed when the GeneratedUID does not match what FileVault 2 is expecting.

A good example of the latter behavior comes from a Mac admin who asked me about the issue he was seeing with passwords not updating. His shop was running an LDAP server as its directory service for its Macs and he had recently added the GeneratedUID user attribute to the accounts on the LDAP server as a fix for accounts disappearing from the FileVault 2 pre-boot login screen. Now, accounts were staying at the FileVault pre-boot login screen, but their passwords were not updating to match what was set on the LDAP server.

In discussing the problem, he mentioned that the UUIDs were using lower-case letters; did that matter? When I followed up on this, he confirmed that instead of his UUIDs looking like this:

7C9AFB0E-E06E-43FA-8E9F-1D410344D2AA

Instead they looked like this:

7c9afb0e-e06e-43fa-8e9f-1d410344d2aa

After confirming that Mac account UUIDs needed to use upper-case alphabetical characters and were case-sensitive, my colleague changed a test account’s UUID to use all upper-case for the alphabetical characters. At that point, FileVault 2 logins for that account began working properly.

If you have an LDAP server and your mobile LDAP accounts aren’t working properly with FileVault 2, here’s what should make FileVault 2 start working properly:

A. On your LDAP server(s), make sure that there’s an apple-generateduid value for your LDAP accounts – If an apple-generateduid value exists in LDAP for a user and is mapped properly to the GeneratedUID attribute on your Macs, FileVault 2 will use the apple-generateduid value stored in LDAP for its UUID.

B. Ensure that all alphabetical characters listed in the apple-generateduid value are using upper-case characters – It’s very important that the locally-set UUID value and the value stored in LDAP match exactly. Otherwise, you may see a recurrence of one or both of the undesired behaviors described above.

10. Automating fdesetup authrestart in 10.9.x or later

One of the more interesting functions in Apple’s fdesetup tool is the authrestart verb, which allows a FileVault 2-encrypted Mac to restart and bypass the FileVault 2 pre-boot login screen. Instead, the Mac reboots as an unlocked system and goes straight to the regular login window.

When you run the fdesetup authrestart command, it asks for a password or a personal recovery key. If using a password, the password must be an account that has been enabled for FileVault 2. After that, it puts an unlock key in system memory and reboots. On reboot, the reboot process automatically clears the unlock key from memory.

For those who want to automate this process, Apple added some functionality to fdesetup authrestart in OS X 10.9.x to support importing the authentication via a properly formatted plist. The plist needs to follow the format shown below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
</dict>
</plist>

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist file.

Once the plist file has been set up and properly formatted, run the following command with root privileges to run the authrestart process and reference the password or recovery key in the plist file for authentication.

fdesetup authrestart -inputplist < /path/to/filename.plist

Once the command runs, it puts an unlock key in system memory and reboots the Mac to the OS login window. As part of the Mac’s restart, the reboot process will automatically clear the unlock key from memory.