One of the changes noted in Apple’s security notes about 10.8.4 and Security Update 2013-002 was this section:

Disk Management

Available for: OS X Mountain Lion v10.8 to v10.8.3

Impact: A local user may disable FileVault

Description: A local user who is not an administrator may disable FileVault using the command-line. This issue was addressed by adding additional authentication.

CVE-ID

CVE-2013-0985

In short, this helps address an issue that has vexed various Mac admins since 10.7.0: If you have a FileVault 2-enabled account, you can decrypt the encryption from the command line using your account’s password.

With 10.8.4, the command-line diskutil tool has now been updated to request an administrator’s login and password before allowing decryption to proceed.

Administrators are also prompted, but can supply their account’s username and password to start the decryption process.

The good folks at Penn State have posted the session videos from the Penn State MacAdmins Conference 2013. The sessions slides and videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:

http://macadmins.psu.edu/conference/resources/

As all the session videos have been posted to YouTube, I’ve linked my FileVault 2 session here:

To follow on to my earlier post about needing admin rights to decrypt FileVault 2 on Mac OS X 10.8.4, it appears that Mac OS X 10.8.4′s Recovery HD partition no longer can decrypt FileVault 2-encrypted Macs. If you boot from a 10.8.4 Recovery HD partition, you can unlock a FileVault 2-encrypted boot drive but you can’t decrypt it either from Disk Utility or the command line.

In Disk Utility’s File menu, Turn Off Encryption… is now grayed out. Unlock “Drive Name” is still an available option.

In Terminal, attempting to decrypt with diskutil with the following commands now results a The given UUID is not a CoreStorage Logical Volume UUID error.

diskutil cs revert UUID_here -stdinpassphrase

diskutil cs revert UUID_here -passphrase

diskutil corestorage revert UUID_here -recoveryKeychain /path/to/FileVaultMaster.keychain

Unlocking from the command line continues to work.

The fact that decrypting using the institutional keychain does not work is particularly worrying. To the best of my knowledge, the only way you can decrypt using the institutional keychain is by using Recovery HD or Internet Recovery. I’ve verified that booting from an alternate 10.8.4 boot drive gives the same behavior with regards to Disk Utility and the diskutil tool.

I’ve filed bugreports at bugreport.apple.com for these issues. For those who who want to submit duplicate bugs, they are bug IDs 14099380 and 14099359.

I’ve also posted the bug reports at Open Radar:

rdar://14099380 – Unable to decrypt using diskutil while booted from Recovery HD

rdar://14099359 – Unable to decrypt using Disk Utility while booted from Recovery HD

As a follow-up to my earlier post about not being able to decrypt FileVault 2 from the Recovery HD partition, it looks like Apple has changed the process for how decryption works. Previously, you could run a command to decrypt on a locked FileVault 2-encrypted boot volume and it would decrypt.

As of 10.8.4, it appears that Apple now requires that the encrypted volume be unlocked first. Once it’s unlocked, then you can decrypt. See below the jump for details.

Here’s how the new decryption procedure works for Disk Utility:

1. Boot your Mac and hold down ⌘-R (Command –R) to boot from the Mac’s Recovery HD partition.

Note: You can also boot from a 10.8.4 installer drive , boot to Target Disk Mode and connect it via Firewire or Thunderbolt to another Mac, or use some other 10.8.4-booting drive. As long as you have 10.8.4′s Disk Utility, this should work.

2. Open Disk Utility.

3. Select your locked hard drive.

4. Under the File menu, select Unlock “Drive Name”

5. When prompted for a password, you can enter the password of any authorized account on the drive.

6. Once you unlock the disk, hold down the Option key on your keyboard and click on the File menu.

7. Under the File menu, select Turn Off Encryption… (with the Option key held down, it’s no longer grayed-out.)

8. When prompted for a password, you can enter the password of any authorized account on the drive.

9. Disk Utility should briefly display a progress window labeled Starting conversion to JHFS+

Your drive should now start decrypting.

You should also be able to unlock then decrypt your Mac from the command line, using the procedures described in this previous post.

I tested specifically to see if the institutional recovery key using FileVaultMaster.keychain worked with the new unlock-first-then-decrypt method while booted from Recovery HD. As shown below, unlocking then decrypting using the institutional recovery key works fine.

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, you’ll see the user information appear with both the username and UUID information.

For local accounts, this isn’t an issue as the OS will properly generate 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 have heard of problems has been with non-Apple LDAP servers. If the LDAP server doesn’t provide the GeneratedUID user attribute for mobile LDAP accounts on Macs, 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:

1. 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 mobile LDAP account on the Mac. Stack Overflow has a good discussion about this issue that I recommend checking out for more details.

2. The account icon being present, but the password not matching the current password on the LDAP server – This behavior has been observed when the mobile LDAP account’s UUID does not match what FileVault 2 is expecting.

A good example of the latter behavior comes from a Mac admin who recently 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

They looked like this:

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

To the best of my knowledge at the time, alphabetical characters used in Mac UUIDs were all upper-case but I didn’t know for certain that the UUIDs were case-sensitive, so I recommended that he call AppleCare Enterprise support to see if they knew.

After checking with another colleague, who confirmed that Mac account UUIDs were both upper-case and case-sensitive, he changed a test account’s UUID to be all upper-case. At that point, FileVault 2 logins for that account began working properly.

Fixing this issue

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:

1. 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.

2. Ensure that all alphabetical characters listed in the the apple-generateduid value are upper-case.

Note: 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

There’s a couple of functions that you can enable on your Mac that will show up at the FileVault 2 pre-boot login screen. The two functions that I’m familiar with are the keyboard input menu and a text-only login banner.

On an FileVault 2-encrypted Mac, you can go into System Preferences and enable these functions. At the next restart, they should show up at the FileVault 2 pre-boot login screen. However, if these functions were enabled using the defaults command, they may show up at the regular login window, but not FileVault 2′s login screen.

The answer seems to be that, in addition to running the defaults commands, you also need to remove certain cache filenames ending in .efires from /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations. Clearing the filename.efires cache files forces the system to update the FileVault 2 pre-boot login screen. Whether this update happens right away or when the system reboots is not yet clear; if you know, please let me know in the comments.

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

defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"
defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool TRUE
rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires

On restart, the FileVault 2 pre-boot login screen should look like this, with keyboard input and login text (highlighted in red) now showing.

To remove these, you would need to boot back into the OS and run the following commands:

defaults delete /Library/Preferences/com.apple.loginwindow LoginwindowText
defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool FALSE
rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires

On restart, the FileVault 2 pre-boot login screen should no longer have either a keyboard input menu or a login banner.

Hat tip to Josh Schripsema for figuring out that the .efires cache files need to be removed to force the refresh.

After the latest round of Apple’s Java updates, some Java-based applications began exhibiting problems. At my shop, MATLAB was one of the applications that was affected by this.

The root cause was discussed and identified in this StackOverflow thread and appears to affect Swing applications, including MATLAB.

Symptoms

After applying Apple’s Java For Mac OSX 10.6. Update 16 to a 10.6.x Mac, or Java for OS X 2013-004 to a 10.7.x – 10.8.x Mac, MATLAB 2012b and below stops functioning correctly. You can open the program but it does not register any mouse or keyboard interaction until the window is resized.

Status as of Friday, June 21

After speaking with Mathworks support, I tested and verified the following:

MATLAB R2011a runs in Mac OS X 10.6.8, 10.7.5 and 10.8.4 with the latest Apple Java updates installed.

MATLAB R2013a runs in Mac OS X 10.7.5 and 10.8.4 with the latest Apple Java updates installed. MATLAB R2013a does not support 10.6.8.

At the moment, here are the options that appear to be available:

For 10.6.x: MATLAB users should install and use MATLAB R2011a

For 10.7.x – 10.8.x: MATLAB users should upgrade to MATLAB R2013a if possible. If not possible to upgrade to 2013a for code compatibility reasons, MATLAB users should install and use MATLAB R2011a.

Other options may include trying to roll back Java to the previous version, but that can cause other issues. I don’t recommend trying that unless neither MATLAB R2013a or MATLAB R2011a are viable options.

Update – Friday, June 21 at 5:15 PM EDT

It looks like Apple has resolved this issue by posting new versions of the Java For Mac OSX 10.6. Update 16 and Java for OS X 2013-004 installers:

Java for OS X 2013-004 – http://support.apple.com/kb/DL1572
Java for Mac OS X 10.6 Update 16 – http://support.apple.com/kb/DL1573

I’ve tested the newly rev’d Java for Mac OS X 10.6 Update 16 update on 10.6.8 and MATLAB R2012b. The new update allowed MATLAB R2012b to run normally again. I still need to test 10.7.5 and 10.8.4, but this looks promising.

Update – Friday, June 21 at 9:40 PM EDT

I’ve now tested the new revision of the Java for OS X 2013-004 update on Mac OS X 10.7.5 and 10.8.4, both times with MATLAB R2012b. The new update allowed MATLAB R2012b to run normally again on both OSs.

To follow up on the re-release of Apple’s Java For Mac OSX 10.6 Update 16 and Java for OS X 2013-004 updates, which fixes a problem with the previous versions of the updates, there’s a need to identify which machines got the problematic version of Java. The problematic Java build is 1.6.0_51-b11-456-10M4508 and can be identified by running the following command:

/usr/libexec/java_home -v 1.6 -exec java -version

Update – June 24, 2013: On further examination, it looks like Apple used two different build numbers:

Mac OS X 10.6.x: 1.6.0_51-b11-456-10M4508
Mac OS X 10.7.x – 10.8.x: 1.6.0_51-b11-456-11M4508

To help Casper admins identify which Macs have 1.6.0_51-b11-456-10M4508 or  1.6.0_51-b11-456-11M4508 installed, I’ve posted the following Casper extension attribute to my GitHub repo:

This script uses the java -version command to check the Java build version. If Java builds 1.6.0_51-b11-456-10M4508 or 1.6.0_51-b11-456-11M4508 are detected, the script reports Installed. If neither 1.6.0_51-b11-456-10M4508 or 1.6.0_51-b11-456-11M4508 are installed on the Mac, the script reports Not Found.

For those interested, the script is available on my GitHub repo:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/check_for_java_build_M4508

As part of dealing with the issues caused by the initial versions of Apple’s Java for OS X 2013-004 and Java for Mac OS X 10.6 Update 16, Apple has recommended installing the revised version of the updates overtop of the existing update in order to replace the problematic Java builds.

The fixed Java builds are the following:

Mac OS X 10.6.x: 1.6.0_51-b11-456-10M4509 (currently installed by Java for Mac OS X 10.6 Update 16)

Mac OS X 10.7.x – Mac OS X 10.8.x: 1.6.0_51-b11-457-11M4509 (currently installed by Java for OS X 2013-004)

If you’ve already installed Java for Mac OS X 10.6 Update 16, it appears that there’s no way to use the softwareupdate tool to install it again. For 10.6.x Macs that had previously installed Java for Mac OS X 10.6 Update 16 and got the problematic build, the installer will need to be downloaded from Apple and then installed on your 10.6.x Mac.

For 10.7.x and 10.8.x however, there’s a way to override the install check that softwareupdate uses which is specific to Apple’s Java updates. By setting the JAVA_INSTALL_ON_DEMAND environment variable for softwareupdate, you can force softwareupdate to install the latest Java update from Apple. This allows you to leverage softwareupdate to re-install the updated Java for OS X 2013-004 over an existing Java for OS X 2013-004 installation that included the problematic Java build.

Michael Kuron posted a script to the MacEnterprise list that I’ve modified. The modified script works pretty well in my environment and does the following:

1. Checks the current OS to see if the Mac is running Mac OS X 10.7.x or later. If not, the script will exit and display the following message:

Not supported on this version of Mac OS X

If the Mac is running 10.7.x or higher, the script runs the following actions:

2. Checks the Java version and displays the results

3. Sets the JAVA_INSTALL_ON_DEMAND environment variable

4. Uses the softwareupdate tool to check for and get the name of the latest Apple Java update for 10.7.x and 10.8.x

5. Installs the latest available Apple Java update for 10.7.x and 10.8.x

6. Checks the current Java version and displays the results

For those interested, the script is available on my GitHub repo:

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

On occasion, it’s necessary to erase a FileVault 2-encrypted volume. However, Disk Utility won’t let you erase or repartition 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. This includes the ability to erase encrypted CoreStorage volumes (aka FileVault 2-encrypted volumes) without first decrypting or unlocking them.

To do this, first run the following command:

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 it’s the one we want to delete.

Next, run the following command:

diskutil cs delete UUID_here

This will delete your CoreStorage volume and reformat it as an unencrypted HFS+ volume.

Apple announced on Friday, June 28th that the FIPS 140-2 validations for the cryptographic modules used by iOS 6 and OS X 10.8.x have now been completed. This is significant news for Mac admins who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)

For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.

As part of today’s announcement, Apple has released KBase articles, tools and guidance for security offices who deal with encryption:

Apple FIPS Cryptographic Modules v3.0 – http://support.apple.com/kb/DL1555

Mountain Lion: How to set up and maintain a FIPS-enabled system – http://support.apple.com/kb/HT5396

Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mountain Lion v10.8 – http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT5396/Crypto_Officer_Role_Guide_for_FIPS_140-2_Compliance_OS_X_Mountain_Lion_v10.8.pdf

FIPS Administration Tools v3.0 – http://support.apple.com/kb/DL1555

FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mountain Lion v10.8 documentation, in the Compliant Applications and Services section.

Casper’s JSS server has some hidden URLs that JAMF Software has built in for various purposes. As part of a discussion today, the folks in the ##osx-server IRC room pulled together a list of the ones that had appeared either in JAMF Software’s documentation, JAMF Nation, or in other media. See below the jump for details.

API structure – https://your.casper.server:8443/apiFrontPage.rest

API intro documentation – https://your.casper.server:8443/apiIntro.rest

Certificate authority – https://your.casper.server:8443/ca.html

Enrollment page for iOS devices and Mac running OS X – https://your.casper.server:8443/enroll

iOS

OS X

Export Mac OS X profiles – https://your.casper.server:8443/exportOSXConfigurationProfile.html

Export Mobile Device profiles – https://your.casper.server:8443/exportConfigurationProfile.html

Scheduled Tasks – https://your.casper.server:8443/tasks.html

Self Service – https://your.casper.server:8443/selfservice/

This last one may or may not still be a working part of the JSS. It was mentioned in JAMF’s April 2009 email newsletter as a way to access Self Service policies through a regular web browser instead of using the Self Service application. I was not able to successfully publish any policies to this page.

Know of any more? Let me know in the comments.

One of the changes Apple has made with the 2013 MacBook Airs is new hardware testing. Apple has moved on from Apple Hardware Test with its vintage Mac OS 9-like look to the new and more automated Apple Diagnostics. As with Internet Apple Hardware Test, Internet Apple Diagnostics can also be run via Apple’s cloud services. See below the jump for the details.

Running Internet Apple Diagnostics on a mid-2013 Mac or later

To use Internet Apple Diagnostics, start up your Mac and hold down both the Option and D keys on your keyboard.

You should see a gray screen with an animated globe appear. It should say something like “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 it’s fully booted.

Once the boot process has completed, you’ll be asked to select your language.

Once you’ve select a language, Apple Diagnostics will begin and a “Checking your Mac” screen will appear in that language. While the diagnostic runs, a progress bar will indicate the estimated time remaining.

Your test results will appear after testing finishes. If no problems were detected, a “No issues found” message will appear. If issues were discovered, a brief description of the issues will be displayed along with additional instructions and error reference codes.

To exit Internet Apple Diagnostics, click the Restart or Shut Down buttons at the bottom of the screen.

From time to time, Apple will release a custom build of Mac OS X to support a new Mac model. A current example is the Mid 2013 MacBook Airs, which were released after 10.8.4, but before 10.8.5. Since they have hardware that wasn’t accounted for in the standard 10.8.4 software, they’re running a custom build of 10.8.4.

Mac App Store 10.8.4 build number: OS X 10.8.4, build 12E55

Mid 2013 MacBook Air 10.8.4 build number: OS X 10.8.4, build 12E3067

While the Air’s custom build should run fine on older 10.8-compatible Macs, the Mid 2013 MacBook Airs aren’t able to run from the 10.8.4 build currently available from the Mac App Store.

In the event that you need to reinstall OS X on a Mac that needs a custom build, Apple’s solution is to use Recovery HD or Internet Recovery to download and install the correct version of OS X for that Mac. However, if your network connection is behind a proxy server, you may not be able to connect back to Apple while booted from Recovery HD, or be able to boot from Internet Recovery.

To help address this, you can use DeployStudio and OS install packages created by createOSXinstallPkg to help address situations where you can’t use Apple’s Recovery, but still need the ability to install custom builds of Mac OS X. See below the jump for the procedure.

Prerequisites

A copy of Install OS X Mountain Lion.app from the Mac App Store.

A copy of the InstallESD.dmg used to install the custom build.

Note: The custom build’s InstallESD must be obtained via Recovery HD or Internet Recovery, so you may need to take a machine off your network in order to get it.

Mac running 10.6.8 or higher (to build the createOSXinstallPkg installer on.)

DeployStudio 1.6.1 or higher running on another Mac

DeployStudio 1.6.1 boot set running the custom build of Mac OS X needed for your hardware (can be NetBoot, or using a Firewire/USB drive.) The boot set needs to be created with Python selected as a tool to include in the bootable system.

Replacing the stock 10.8.4 InstallESD with the custom build’s InstallESD

1. Right-click on the copy of Install OS X Mountain Lion.app from the Mac App Store and select Show Package Contents.

2. Navigate to Contents: SharedSupport and replace the stock 10.8.4 InstallESD.dmg file with the custom build’s InstallESD.dmg

Creating the automated installer package with createOSXinstallPkg

1. Download the latest version of createOSXinstallPkg to your Mac.

2. Run the following command to create a basic uncustomized installation package (see the documentation if you want to create a customized installer):

sudo /path/to/createOSXinstallPkg --source /Applications/Install\ OS\ X\ Mountain\ Lion.app

3. Copy your newly-created createOSXinstallPkg installer to your DeployStudio server.

Putting it into a DeployStudio workflow

1. Set up a new package in DeployStudio for your createOSXinstallPkg installer. In the case of my example, I’m calling it MacBook Air 2013 10.8.4.

2. Set up a new DeployStudio workflow where the workflow is set to do two tasks:

A. Repartition the boot drive with one partition (this erases any existing OS and Recovery HD partitions).

B. Install one package, configured to install MacBook Air 2013 10.8.4. I did not check the box to set it as a Postponed installation, so that the DeployStudio boot set would do the install rather than doing it on first boot. In the case of my example, I’m calling it Restore 2013 MacBook Air Custom OS.

Running the automated installation

1. Boot the Mac that needs reinstallation to DeployStudio.

2. Log in and select the Restore 2013 MacBook Air Custom OS workflow.

3. Depending on your automation preferences, you may need to select the drive. Once selected, DeployStudio should wipe and repartition the target drive, then install the custom version of Mac OS X for your Mac model.

4. Wait for DeployStudio to finish installing the package on the Mac and hit Quit when prompted. Your Mac should reboot at this point.

5. Stand up, walk away, go get some coffee. If all goes well, your Mac should install the custom version of OS X and set up a Recovery HD partition on the designated drive without needing any further intervention on your part.

My preferred way to create VMs in VMware Fusion is by leveraging NetBoot and DeployStudio, but not all environments have access to NetBoot or DeployStudio. For those environments, there’s now a scripted way to create customized OS X 10.7.x or 10.8.x installer disk images for use with VMware Fusion. This allows the creation of OS X VMs in VMware Fusion that can configure themselves in an automated fashion without needing access to either NetBoot or server resources. See below the jump for the details.

The script below prepares a customized OS X installer disk image for use with VMware Fusion. It’s adapted from the prepare_iso script created by Tim Sutton.

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 prepared before running the script.

Configuring First Boot Package Install.pkg for use with the script

First Boot Package Install.pkg is an installer package that enables other packages to be installed at first boot. The script adds First Boot Package Install.pkg to the OS X installer and allows installer packages that can’t run in the OS X Installer environment to be be installed during the first boot of the VM.

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 configure First Boot Package Install.pkg, please see this post:

http://derflounder.wordpress.com/2013/05/13/first-boot-package-install-pkg/

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

Once you have First Boot Package Install.pkg configured with your packages, run the create_vmware_osx_install_dmg script with two arguments:

A. The path to an Install OS X [Mountain] Lion.app or the InstallESD.dmg contained within.

B. An directory to store the completed disk image in.

Example usage:

If you have a 10.8.4 Mountain Lion installer available, run this command:

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

This should produce a DMG file inside output_directory that’s named OSX_InstallESD_10.8.4_12E55.dmg. This DMG will install both OS X 10.8.4 and First Boot Package Install.pkg.

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

1. Launch VMWare Fusion 5.x

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

3. In the Create New Virtual Machine window, select Continue without disc.

4. In the Installation Media window, select Use operating system installation disc or image, then click on Choose a disc or disc image…

5. Select your customized OS X install disk image file

6. In the Choose Operating System window, set OS as appropriate. In this example, I’m setting it as follows:

Operating System: Apple Mac OS X

Version: Mac OS X 10.8 64-bit

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

8. 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 First Boot Package Install.pkg, 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 First Boot Package Install.pkg.

Once the installation completes, the VM will then reboot.

On reboot, the login window will be stopped from loading while the packages included with First Boot Package Install.pkg are installed. Once the packages finish installing, the VM will reboot again.

After the second reboot, the VM should now be automatically configured with the desired applications and settings.

I’ve updated the create_vmware_osx_install_dmg.sh script that I had previously posted about here. It now includes the ability to create an .iso file, which can be used with VMware ESXi servers running on Apple hardware. See below the jump for the details.

When running the script, the user will now be asked if they want an ISO disk image for use with VMware ESXi.

If the user selects Yes, both a .dmg and an .iso file will be created and stored in the output directory.

If the user selects No, a “– ISO disk image will not be created. Proceeding..” message will be displayed and a .dmg file will be created and stored in the output directory.

The virtual drives created by VMware ESXi for OS X VMs are not automatically formatted, so support for System Image Utility‘s AutoPartition.app has been included. AutoPartition.app runs before the installation of OS X to make sure the boot drive is formatted and named correctly for the automated installation.

The updated script is below and has also been posted to my GitHub repo. For more details on configuring and running the script, click here.

While testing a new machine setup today, I noticed that Safari wasn’t opening to the default homepage like it should. Instead, it was opening Safari’s Top Sites.

There wasn’t an obvious way to set the Safari new window setting from the command line, but with the assistance of Greg Neagle, I’ve mapped out the applicable keys and their settings. See below the jump for the details.

The behavior of new Safari windows is set by the NewWindowBehavior key in /Users/username/Library/Preferences/com.apple.Safari.plist. Likewise, new Safari tabs are set by the NewTabBehavior key in /Users/username/Library/Preferences/com.apple.Safari.plist.

Both keys use an integer to set the desired behavior. Here’s how it maps out:

com.apple.Safari NewWindowBehavior

com.apple.Safari NewWindowBehavior 0 = Homepage

com.apple.Safari NewWindowBehavior 1 = Empty Page

com.apple.Safari NewWindowBehavior 2 = Same Page

com.apple.Safari NewWindowBehavior 3 = Bookmarks

com.apple.Safari NewWindowBehavior 4 = Top Sites

com.apple.Safari NewTabBehavior

com.apple.Safari NewTabBehavior 0 = Homepage

com.apple.Safari NewTabBehavior 1 = Empty Page

com.apple.Safari NewTabBehavior 2 = Same Page

com.apple.Safari NewTabBehavior 3 = Bookmarks

com.apple.Safari NewTabBehavior 4 = Top Sites

Here’s the defaults commands to set the NewWindowBehavior and NewTabBehavior keys to the various available settings:

Set new Safari windows to open to Safari’s default homepage:

defaults write com.apple.Safari NewWindowBehavior -int 0 

Set new Safari windows to open to an empty page:

defaults write com.apple.Safari NewWindowBehavior -int 1

Set new Safari windows to open to the same site as the last-opened page:

defaults write com.apple.Safari NewWindowBehavior -int 2

Set new Safari windows to open the Safari bookmarks page:

defaults write com.apple.Safari NewWindowBehavior -int 3

Set new Safari windows to open the Safari Top Sites page:

defaults write com.apple.Safari NewWindowBehavior -int 4

Set new Safari tabs to open to Safari’s default homepage:

defaults write com.apple.Safari NewTabBehavior -int 0

Set new Safari tabs to open to an empty page:

defaults write com.apple.Safari NewTabBehavior -int 1

Set new Safari tabs to open to the same site as the last-opened page:

defaults write com.apple.Safari NewTabBehavior -int 2

Set new Safari tabs to open the Safari bookmarks page:

defaults write com.apple.Safari NewTabBehavior -int 3

Set new Safari windows to open the Safari Top Sites page:

defaults write com.apple.Safari NewTabBehavior -int 4

We’ve gotten in a couple of calls from our users asking how to work with equations in Word 2011. So that other folks know, here’s how you do it:

1. Make sure that your document is saved in Word’s .docx format, as the equation editor will only be available to documents in that file format.

If you have a .doc document open in Word and need to work with the equation editor, please save your document in .docx format. Once saved in .docx format, the equation editor will become available.

2. Select the place in your Word document where you want a new equation to be inserted.

3. Under the Insert menu, select Equation.

3. The Equation Tools will open in the toolbar and you’ll be prompted in the document to type the equation.

Another way to access the Equation Tools is the following method:

1. Make sure that your document is saved in Word’s .docx format.

2. Click on the Document Elements tab in the toolbar.

3. In the Document Elements tab, click on the pi symbol (π) to access the Equation Tools.

As part of building a custom OS X installer ISO for my ESXi server, I wanted the ability to include Server.app as part of my installation process. One problem with that is that Server.app is only available via the Mac App Store and doesn’t have a separate installer available for download.

However, if you have already purchased Server.app, it is possible to get a copy of the Server.app installer from the Mac App Store. See below the jump for details.

To install Server.app, the Mac App Store will download an installer package from Apple, install Server.app, then delete the installer package as part of the post-installation clean-up. However, it is possible to make the App Store leave behind a copy.

1. Go to a machine that does not have Server.app installed.

2. If it is open, quit out the App Store application

3. Open Terminal and run the following command:

defaults write com.apple.appstore ShowDebugMenu -bool true

4. Launch the App Store application. It should now have a Debug menu showing.

5. If needed, sign into the App Store and go to Purchases. From there, find OS X Server.

6. Begin the installation process for OS X Server, then click the Pause button to pause the download.

7. Under the Debug menu, select Show Download Folder…

At this point, you should see a folder inside the displayed folder. In that directory, you’ll see a package with a long randomized name. That will be the Server.app installer package.

8. In Terminal, run the following command:

ln /path/to/package_from_mac_app_store_name_here.pkg /path/to/name_you_want_to_save_package_as_here.pkg

Using the ln command will set up a hard link to the downloaded installer package. This will create name_you_want_to_save_package_as_here.pkg in the location specified, which is then linked to the contents of package_from_mac_app_store_name_here.pkg. The reason to do this is that the hard-linked name_you_want_to_save_package_as_here.pkg will not be deleted when the Mac App Store deletes package_from_mac_app_store_name_here.pkg from the Mac as part of the post-installation cleanup.

9. Go back to the App Store and click the Resume button to have the installation complete.

10. Once the installation finishes, name_you_want_to_save_package_as_here.pkg will available as a signed Server.app installer package. From there, you can use it on its own or as part of a deployment workflow.

Hat tip to @tvsutton  for letting me know about the Mac App Store’s Debug menu and how to use hard links to capture downloads from the Mac App Store.

I’ll be speaking about FileVault 2 at MacSysAdmin 2013, which is being held from September 17 – 20th, 2013 in Göteborg, Sweden. For those interested, my talk will be on Wednesday, September 18th.

For a description of what I’ll be talking about, please see the Wednesday program page.