While assisting a user today whose workstation is running 10.8.5, I downloaded the latest version of Skype and tried to run it. To my surprise, I received the following message.

It looks like Skype 6.1.7 only supports 10.9 and higher, which is not something mentioned on the Skype support site’s system requirements page.

The new system requirements are available on the Skype download page by clicking the System Requirements link found there.

For those that need a version of Skype that works on 10.6.x – 10.8.x, it looks like Skype 6.1.5 (334) is the latest version available. It’s available from the following link:

http://www.skype.com/go/getskype-macosx-106-107-108

Hat tip to @tvsutton for finding the download link for the latest version of Skype that works on 10.6.x – 10.8.x.

When checking for Apple software updates today, my colleague Tim Sutton noticed that there was a problem with checking updates. When I checked for updates on my 10.8.x and 10.9.x Macs using the App Store and the command-line softwareupdate tool, I received the same error from both:

The operation couldn’t be completed. (NSURLErrorDomain error -1012.)

The reason for the error has its root in a change which Apple introduced with OS X 10.8.x, where Macs running 10.8.x and 10.9.x use an HTTPS URL to check for updates on Apple’s Software Update servers. It appears that the SSL certificate used to validate Apple’s Software Update service has expired as of Saturday, May 24th at 7:59:59 PM Eastern Daylight Time.

Since the certificate needs to be valid in order for connections to Apple’s Software Update servers to work properly, the certificate expiration is preventing the Software Update service from connecting.

When I checked for software updates on Macs running 10.7.5 and 10.6.8, they were unaffected by this issue. Macs running 10.7.x and older use an HTTP URL to connect to Apple’s Software Update servers, which means they do not use an SSL certificate to validate the connection.

Hopefully, Apple is able to get a new certificate in place soon. Once a valid certificate is in place, Apple’s Software Update service should begin working again for Macs running 10.8.x and higher.

Update: May 25th, 2014 – It appears that Apple has acted with dispatch to fix this issue. A new SSL certificate is now in place, with an expiration date of Tuesday, May 24, 2016 at 7:59:59 PM Eastern Daylight Time.

Back when Apple Remote Desktop 1.2 (ARD) was the main tool I used to administer my Macs remotely, I wanted to be able to run Unix commands remotely but needed a delivery vehicle that could send them over ARD. Payload-free installer packages were the answer.

Installer packages are Apple’s preferred way to install software. Apple built into ARD the ability to install software on remote machines using the Install Packages… function. One useful feature of installer packages is that you can have them run a script before or after the package is installed. You can even set up a number of scripts and have them run in the order you designate. Best of all, you can build a payload-free installer package that run scripts but does not install files. So, when I needed to run a Unix command on one or more of my managed Macs, I’d normally build a payload-free package and use the Install Packages… function to push it out to the relevant machines.

With Apple Remote Desktop 2 and later, Apple included a Send Unix Command… function. This gives you the ability to send a Unix command and get the feedback from the remote machine, without the extra work of building a payload-free installer package. However, the practice of building payload-free packages and using those to run my Unix commands stayed with me for the following reasons:

1. Ease of use – Running a script contained within a payload-free package does not require any special knowledge or training. All the person using it has to know is how to run an installation using an installer package.

2. Portability – When my management methods evolved beyond using ARD as my primary management tool, I found that different management tools had their own ways to deploy scripts but a common denominator of system management and deployment tools for Macs is that they can deploy installer packages. Using payload-free packages allows me to run scripts on managed machines in a consistent manner regardless of which management or deployment tool is being used.

Installer packages are available in two general categories:

1. Bundle-style installer packages – This style of installer package is created as a Mac OS X bundle that contains scripts and a description of the package requirements and behaviors. As part of creating a bundle-style package, you can define scripts that will execute before or after the installation.

2. Flat installer packages – This type of installer package was first introduced in Mac OS X 10.5 and is a single file. This style of installer package is created as a xar archive that contains scripts and a description of the package requirements and behavior.

Using Scripts with Bundle-Style Installer Packages

Six categories of scripts can be used in a bundle-style package. The categories and their execution conditions are described in the table below:

For bundle-style payload-free packages, only the following two categories of scripts are used:

preflight

postflight

The other categories of scripts used in bundle-style installer packages depend on something being installed. Since payload-free packages do not install files, these script categories would not execute properly.

Using Scripts with Flat Packages

Two categories of scripts have been defined for use with flat packages:

When working with bundle-style and flat packages, one thing to keep in mind is that the script category names will not match up across the different types of installer packages. The table below shows the equivalents between the script types.

Bundle-style Package -> Flat Package Category Equivalents

A commonality between scripts used in bundle-style and flat installer packages is that the scripts must return an exit status of zero or else the Installer application will either cancel the installation process or report that the installation has failed.

If you’re building a shell script for a payload-free package, one way to ensure that the script returns an exit status of zero to the Installer application is by including exit 0 at the end of your script.

Installer Script Variables

When building a payload-free package, it’s helpful to know that the Installer application can automatically pass along information to the script using variables. The table below shows the variables that are available for use with shell scripts.

Here’s an example of using the $3 variable in a payload-free package script. In this case, we can take advantage of the Installer process telling us which drive the package is being installed on by using the $3 variable as the target of our script’s actions.

Creating payload-free packages

To assist with the task of creating payload-free packages, I’ve written a tool named Payload-Free Package Creator to help create payload-free installer packages. It leverages Apple’s pkgbuild tool to create payload-free packages from existing scripts. All Payload-Free Package Creator components and scripts are available at my GitHub repo:

https://github.com/rtrouton/Payload-Free-Package-Creator

If you want to know more about the process that Payload-Free Package Creator uses, I have a post on how how to use pkgbuild to create payload-free packages.

Payload-free Packages and Receipts

One thing to be aware of when using payload-free installer packages to run commands is that payload-free flat packages may not leave an installer receipt behind. When installing a payload-free package built with Apple’s pkgbuild tool using the –nopayload flag, no receipt is created as part of the installation process. When asked about this behavior, Apple’s response was that this is an intended behavior for payload-free packages built using pkgbuild as the principal purpose of receipts is to track upgrade behavior. Apple further stated in their response that payload-free packages are intended to be a convenient container for scripts.

Using payload-free packages to deploy scripts has been a vital part of my toolkit for many years. Understanding the functionality that payload-free packages can offer, and knowing how to quickly create them to meet your needs, will hopefully add them to yours as well.

As part of Firefox 30′s release, Mozilla made a change to disable support for NT LAN Manager version 1 (NTLMv1) network authentication. This change affects sites using Microsoft’s SharePoint or IIS services. The Windows version of Firefox 30 should switch to using NTLMv2 authentication automatically, but NTLMv2 is not supported by Firefox on non-Windows platforms.

The result for non-Windows platforms is that access may be blocked when Firefox 30 users try to access those kinds of sites.

Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication, which will allow access again to SharePoint-based or IIS-backed web applications. For more details, see below the jump.

Enabling NTLMv1 in Firefox 30

1. Open Firefox

2. In the address bar, enter the following:

about:config

3. If prompted, click on the I’ll be careful, I promise! button.

4. Search for the following:

network.negotiate-auth.allow-insecure-ntlm-v1

5. Once the network.negotiate-auth.allow-insecure-ntlm-v1 setting is located, double-click on the setting. That should change the entry in the Value column from false to true.

6. Once the network.negotiate-auth.allow-insecure-ntlm-v1 setting has been set to true, close the Firefox browser window.

7. Open a new browser window and attempt to access the SharePoint-based or IIS-backed site. You should now be able to log in.

A while back, I wrote a post on fixing Casper Mac MDM enrollment. This post covered my experiences with Casper 8.7.x and provided a method to automatically fix any problems with the MDM certificate. Unfortunately, the method that works in 8.7.x does not work in 9.x because the command that I use to do the MDM enrollment in Casper 8.x is jamf mdm. As part of the change from Casper 8.x to 9.x, the function performed by the jamf mdm command is now handled by the jamf manage command in Casper 9.x. The jamf mdm command itself does not exist in Casper 9.x

To duplicate the general process which I’m using in Casper 8.x, I needed to run the following commands:

/usr/sbin/jamf removeMdmProfile -verbose
/usr/sbin/jamf manage -verbose
/usr/sbin/jamf recon

The issue I ran into is that jamf manage waits until all policies are finished running, which meant that the MDM fix is running after the jamf recon command completes its inventory update and sends it on to the Casper server. The consequence is that the Casper server would never be informed that the machine had actually been fixed, which potentially cues an infinite loop of fixing a problem which is already fixed.

So I had two issues:

1. I wanted to fix my problem with a Casper smart group that would contain only affected machines and an associated Casper policy that would fix the machines in the smart group. This would allow the problem to be automatically detected and then fixed without the need for human intervention.
2. I needed to make reasonably sure all policies were finished running before trying to run the jamf manage command. Otherwise, running jamf manage would result in the recon running before the MDM certificate gets fixed.

On top of that, I preferred that jamf manage only be run once rather than building a process that potentially ran it a large number of times.

To sum up:

A) I wanted to fix the problem automatically with a Casper policy.
B) I couldn’t directly fix this with a Casper policy. Running the commands above using a policy would mean that jamf manage and jamf recon would not run in the order I wanted them to, with the undesired “infinite loop” consequences described above.

Shea Craig gave me the idea of using a LaunchDaemon and script to run the commands I needed, but I still needed a reliable way of determining if Casper policies were running. Shea’s approach relies on killing the jamf process as needed, but that ran the risk of interrupting any active policies or other tasks that were running.

After mulling over the problem for a while, I thought of another way to determine if a policy was running. /var/log/jamf.log is updated when Casper policies or check-ins run on an individual Mac, so if the log hasn’t been updated in a while, it is very unlikely that a policy is running.

Using this idea, I wrote a script and an associated LaunchDaemon to perform the following tasks:

1. Verify that the Mac can contact the Casper server.
2. Verify that /var/log/jamf.log has not been written to in the past five minutes.
3. If /var/log/jamf.log has not been written to in the past five minutes, fix the MDM certificate and communicate that it is fixed to the Casper server.
4. Delete itself and its associated launchdaemon.

For the details, see below the jump.

Script:

The LaunchDaemon assumes the script above has been installed as /var/root/fixcaspermdm.sh. The LaunchDaemon runs the script when the LaunchDaemon is loaded and then attempts to run it once every 10 minutes thereafter.

LaunchDaemon:

I still had the issue of deploying this solution. I decided to fix this with a payload-free package, which performs the following tasks

1. Determines if the Mac is running 10.7.x or later.
2. If any previous instances of a specified LaunchDaemon and script exist, unload the LaunchDaemon and remove the LaunchDaemon and script.
3. Create the LaunchDaemon described above by using cat input redirection to write the XML contained below to a new file.
4. Create the script by using cat input redirection to write the script described above to a new file.
5. Once the LaunchDaemon file has been created, fix the permissions so that the file is owned by root:wheel and set to not be executable.
6. After the permissions have been updated, move the LaunchDaemon into place in /Library/LaunchDaemons.
7. Once the script file has been created, fix the permissions so that the file is owned by root:wheel and set to be executable.
8. After the permissions have been updated, move the script into the place that it will be executed from.
9. After the LaunchDaemon and script are in place with proper permissions, load the LaunchDaemon to begin the script’s execution.

Payload-Free Package Script:

I then created a payload-free package using the script above and Payload-Free Package Creator.

Now I had a solution that would fix the MDM certificate, but I still needed to be able to identify machines with the MDM certificate problem and then deploy the solution with Casper 9.x. Fortunately, here I could use the same strategy on Casper 9.x that I had on Casper 8.x.

To help identify machines with this problem, JAMF provides three extension attributes with your Casper JSS server to help you identify machines with either problematic SSL certificates or missing MDM certificates.

JSS Certificate Validation
Verify Certificate Based Communication
Verify MDM Enrollment

All can be installed from the JAMF Software category of your Casper server’s Computer Extension Attribute Templates.

From there, you can set up a Smart Group to look for machines that fit the following criteria:

JSS Certificate Validation – Success
Verify Certificate Based Communication – Enabled
Verify MDM Enrollment – Not Enrolled

It should also currently be scoped to look for Macs running 10.7.x or higher, as earlier OSs won’t be enrolled in MDM.

Here’s how the smart group I set up looks in Casper 9.3.x:

From there, set up a policy that is scoped to run on members of that smart group. The policy I set up will install the payload-free package, which in turn will create and load the LaunchDaemon and script to fix the problem.

Once the script has fixed the MDM certificate issue, the script will trigger a new inventory to run and send the results to the Casper server. The updated inventory should then allow the JSS to detect that the MDM certificate has been installed and take the machine out of the smart group.

Here’s how the policy I set up looks in Casper 9.3.x:

I’ll be speaking about FileVault 2 at the Penn State MacAdmins Conference 2014, which is being held from July 8th – 11th, 2013 in State College. For those interested, my talk will be on Thursday, July 10th.

For a description of what I’ll be talking about, please see the Managing Mavericks’ FileVault 2 with fdesetup session description. You can see the whole list of speakers here on the Sessions page.

I’ll be collaborating with my colleague Jeremy Reichman to give a session at the Penn State MacAdmins Conference 2014, which is being held from July 8th – 11th, 2013 in State College. For those interested, our talk will be on Friday, July 11th.

For a description of what we’ll be talking about, please see the Extending OS X Management Systems with Scripting session description. You can see the whole list of speakers here on the Sessions page.

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 a 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. The password must be an account that has been enabled for FileVault 2 (i.e. an account that shows up at the FileVault 2 pre-boot login screen.) 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 Mavericks to support importing the authentication via a properly formatted plist. The plist needs to follow the format 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.

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

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

The man page for fdesetup also indicates that you can use a keychain with both the private and public keys associated with an institutional recovery key to authenticate the authrestart process. Based on the manpage, you should be able to run the following command to run the authrestart process and reference the institutional recovery key for authentication.

sudo fdesetup authrestart -key /path/to/filename.keychain

As of OS X 10.9.3, this does not appear to work. Instead of being prompted for the keychain’s password and the Mac restarting, an Error: Unable to restart message is displayed and nothing else happens.

If manually restarted, the Mac will reboot to the FileVault 2 pre-boot login screen.

I’ve filed a bug with Apple at bugreport.apple.com about this behavior. If you want to also file a bug report on this, please reference the following bug ID when submitting your report:

17423687

I’ve got the details of my bug report posted at Open Radar:

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

Since Casper 9.x was first released, I’ve been preparing for my shop’s own upgrade from Casper 8.x to 9.x. As of the morning of Saturday, June 28th, those preparations have ended with my shop’s successful upgrade to Casper 9.32. When I mentioned this on Twitter, I heard from a few folks who mentioned that they were planning to also do this in the near future and @theycallmebauer asked if I was going to post about my experience.

I thought that was a good idea, so please see below the jump for the details.

The biggest lessons I took away from the experience were these:

1. Having a test environment is essential.

I have two Casper test environments to help with me with my testing. The first was a Casper 9.x server hosted at my home. It did not replicate my work environment, but it allowed me to test new Casper 9.x releases on a small scale. If something blew up, it was no big deal as the only things affected were the VMs I was testing with.

The second was my test environment at work. This used a Casper 9.x server that replicated as closely as possible my production environment. If something didn’t blow up in my home test environment, the next step was to try it in my work test environment.

Between the two environments, I must have installed every version of Casper 9.x at least once. I also must have rolled back my work test environment to 8.73 about three or four times to help me practice upgrading to various versions of 9.x.

2. Surprises are bad. Test as much as you can to find issues.

I found a few things that worked in Casper 8.73 that either didn’t work or didn’t work like I expected them to. For example, in Casper 8.73 you can have a message pop up once Self Service policies are finished running. You can also have messages be displayed when policies are run in Casper 9.x, but for whatever reason, they won’t appear when those policies are run through Self Service.

Since I like to have “Hey, this is done,” messages appear for my users when Self Service policies finish running, I needed to figure out a way to have the messages appear in Casper 9.x. After some work, the answer I preferred was to have a script like the one below set to run after the Self Service policy’s main action:

#!/bin/bash

# This script displays a message that lets the user know that 
# a printer setup policy has finished. It is set to the lowest
# priority to ensure that it runs last after all other scripts
# and policy actions.

printer_name="$4"

/usr/sbin/jamf displayMessage -message "The $printer_name printer has now been set up on your Mac."

exit 0

In this case, $4 would pass along a name which I had set on the Casper server’s end. That worked fine, until I discovered that the jamf displayMessage -message command didn’t appear to work right in Casper 9.32 on 10.5.x and 10.6.x Macs. After discussing it with JAMF’s support, I decided to use jamfHelper for my 10.5.x and 10.6.x Macs, while using jamf displayMessage -message on 10.7.x and higher. With an OS check thrown in, my updated message script looked like this:

#!/bin/bash

# This script displays a message that lets the user know that 
# a printer setup policy has finished. It is set to the lowest
# priority to ensure that it runs last after all other scripts
# and policy actions.

# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

printer_name="$4"
dialog="The $printer_name printer has now been set up on your Mac."
description=`echo "$dialog"`
button1="OK"
jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
icon="/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertNoteIcon.icns"

if [[ ${osvers} -lt 7 ]]; then

  "$jamfHelper" -windowType utility -description "$description" -button1 "$button1" -icon "$icon"

fi

if [[ ${osvers} -ge 7 ]]; then

  jamf displayMessage -message "$dialog"

fi

exit 0

For those interested, I have my message scripts posted to GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/message_display_scripts

Another issue I found in 9.32 was with how Casper-passed parameters were interpreted. In particular, I saw an issue in Casper 9.32 where Parameter 6 is seemingly being read as Parameter 7 in scripts. I verified that the problem did not happen on Casper 8.73 with the identical script used with an identical policy.

Script used:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/install_company_xerox_printer_drivers

Blog post that explains how the script is used with Parameters 6 and 7:

http://derflounder.wordpress.com/2014/02/10/deploying-xerox-print-drivers-on-a-per-os-basis-via-caspers-self-service/

Where the parameters were coming into play was that Xerox provided several different versions of their print driver that I was using in my shop:

For 10.5.x – Xerox Print Driver 2.94.3

For 10.6.x – Xerox Print Driver 2.112.0

For 10.7.x through 10.9.x – Xerox Print Driver 2.113.0

When I ran my Casper 9.32 printer setup policy on a 10.6.x Mac, it reported that it did not detect that Xerox Print Driver 2.113.0 was installed and triggered a second policy to install drivers before the original policy proceeded with setting up the printer. The second policy correctly installed Xerox Print Driver 2.112.0 because that was the only option available for 10.6.x Macs. If the Casper 9.32 printer setup policy was re-run, it again reported that it did not detect that Xerox Print Driver 2.113.0 was installed and triggers the second policy to install the 2.112.0 drivers again.

Replacing the $6 value in the script with a hard-coded “2.112.0” allowed the script to correctly detect that Xerox Print Driver 2.112.0 is installed. An identical Casper 8.73 policy and identical script worked properly and passed along $6 as being 2.112.0.

JAMF Support confirmed that they were seeing the same issue and that the solution for now was to hard-code it.

3. You don’t have to do everything at once.

As I found issues in testing, or learned about new functions and features, I tried to see if I could incorporate them into my existing Casper 8.73 setup. A good example of this had to do with MySQL. When I started the process, my Casper server was running the following:

Red Hat Enterprise Linux Server release 6.0 (Santiago)

MySQL 5.1.47

However, I looked ahead to Casper 9.x and saw the following versions of MySQL were now listed as being required:

MySQL Enterprise Edition 5.5 or later, or MySQL Community Server 5.5 or later

Since I didn’t want to deal with a MySQL upgrade at the same time that I was doing an upgrade to Casper 9.x, I went ahead and upgraded my Casper production server to use MySQL 5.5.

Another example of prior preparation had to do with the messages in Self Service. The nice thing there was that all of the scripts worked fine in 8.73 as well. Instead of having to do all the work of updating my scripts as part of the upgrade process, I could update my Self Service policies to use the scripts in Casper 8.73 and have both the policies and the scripts all be brought into Casper 9.x when I upgraded.

The Upgrade Process

When the time came to actually do the upgrade to Casper 9.32, here’s what I did to make the process go smoothly:

Pre-upgrade work:

• Made a snapshot backup of my work’s Casper production VM
• Verified that the previous night’s automated database backup ran successfully
• Purged all Casper database logs older than one week
• Performed a manual backup of the Casper database using the JSS Database Utility
• Rebooted the Casper production VM

Upgrade work:

• Ran the Casper 9.32 Linux installer on my RHEL VM to upgrade Casper from 8.73 to 9.32​
• Migrated the Casper installer repository using Casper Admin to compress non-flat packages and move scripts from the repo to their new storage location in the Casper database.​
• Created new Casper QuickAdd installer package with Casper Recon

Post-upgrade work:

• Verified that a sampling of workstations running 10.5.8 through 10.9.3 had upgraded themselves to the 9.32 Casper agent.​​
• Verified that a sampling of workstations running 10.5.8 through 10.9.3 were all able to run an inventory update and send it to the upgraded Casper 9.32 server.​
• Verified that CasperCheck was able to detect and download the new QuickAdd installer package.
• Verified that my policies were running as expected and that the Self Service messages were popping up as appropriate.

I’m indebted to those folks who went before me, as they helped find and fix a number of issues that I didn’t have to deal with as part of my upgrade process with 9.32. For those who have yet to upgrade to Casper 9.x, hopefully this information helps you out in your own upgrade process.

VMware has released the VMware Fusion Technology Preview July 2014 as of Jul 3, 2014. One of the new items included in the Features list was this one:

Support for viewing VMware Fusion Professional to VMware Workstation, VMware ESXi, VMware vSphere servers in the library (File > Connect to Server)

When I investigated, it looks like this feature brings to VMware Fusion something that’s been in VMware Workstation for a while: a way to manage free ESXi and paid vSphere servers.

For more details, see below the jump.

Connecting to an ESXi server from VMware Fusion

1. Launch VMware Fusion Technology Preview July 2014

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.

4. If your ESXi server is using a self-signed certificate, you’ll be warned that Fusion can’t verify the identity of the server. I am using a self-signed cert on my home ESXi server, so I clicked Continue.

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, clicking on the name of your ESXi server will give you 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 the ability to suspend, power on, and make snapshots.

Note: When I tried to create snapshots of the VMs running on my ESXi server, Fusion became unresponsive while the snapshot was created. After about five minutes, the snapshot was created and Fusion resumed normal operation. Deleting snapshots was a much quicker operation.

To open a console window, double-click on one of the listed VMs.

A console window should open up and allow you to have access to your VM and its settings.

Exporting VMs from VMware Fusion to ESXi

To copy a VMware Fusion-built VM to your ESXi server, use the following procedure.

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

2. Connect to your ESXi server

3. Drag your shut-down VM into the ESXi server section.

4. A new Upload Virtual Machine window will appear.

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

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

7. Once the upload is completed, the newly-uploaded VM will appear in your ESXi server’s list of VMs.

At the moment, it does not appear that I can create new VMs directly on my ESXi server without having to first create them in VMware Fusion. Hopefully, this ability will appear in a future release.

As an ESXi user who primarily uses a Mac, I’m pretty happy with the new ESXi management options that I’m seeing in this Fusion Tech Preview release. I’m hoping VMware builds on this to provide ESXi management functionality in VMware Fusion comparable to what Windows users have long enjoyed in VMware Workstation.

As part of the man page for fdesetup, Apple provides a sample plist file as a guide for those who want to import authentication credentials as part of running commands with fdesetup.

As part of the plist, there are two plist keys that reference using a keychain which contains the private key for an institutional recovery key:

KeychainPath

KeychainPassword

For KeychainPath, you will need to provide the file path to the keychain as the plist value. For KeychainPath, you will need to provide the password that unlocks that keychain.

For example, if you put the keychain file into the /tmp directory, you would reference /tmp/filename.keychain as the KeychainPath plist value. If the password to unlock that keychain is seKritPassword, you would reference seKritPassword as the KeychainPassword plist value.

One particular thing to note is that the KeychainPath entry on the fdesetup man page references that this works with certain fdesetup commands, but does not specify which commands are applicable.

As of OS X 10.9.4, it appears that you can leverage the KeychainPath and KeychainPassword plist keys with the following two fdesetup commands.

fdesetup changerecovery

fdesetup removerecovery

If using the current institutional key to authenticate, the plist should look like this.

<?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>KeychainPath</key>
<string>/path/to/filename.keychain</string>
<key>KeychainPassword</key>
<string>password</string>
</dict>
</plist>

If you are using the current institutional key to authenticate a change to a new institutional recovery key, you can also embed the public key of the new institutional recovery key in the plist. In that case, the plist will look like this.

<?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>KeychainPath</key>
<string>/path/to/filename.keychain</string>
<key>KeychainPassword</key>
<string>password</string>
<key>Certificate</key>
<data>
(Certificate data goes here.)
</data>
</dict>
</plist>

For those who wanted a copy of my FileVault 2 talk at Penn State MacAdmins, here are links to the slides in PDF and Keynote format.

PDF: http://tinyurl.com/PSUMac2014PDF

Keynote slides: http://tinyurl.com/PSUMac2014key

For those who wanted a copy, click on the link below for the Extending OS X Management Systems with Scripting slides in PDF format.

PDF: http://tinyurl.com/PSUMac2014ExtendScriptPDF

Penn State MacAdmins 2014′s communication lines ran in a number of directions, with few more important than Twitter. Thanks to Michael Lynn capturing presentation links from Twitter, links to most of the presentations can be accessed below the jump. These presentations can also be accessed via AFP548.

Slides for my #psumac presentation on Modular Image Creation are now posted:
ucalgary.ca/iaml/mic2014—
Anthony Reimer (@AnthonyReimer) July 09, 2014

Slides for my #psumac talk are up: bit.ly/1jCiDHy—
Pepijn Bruienne (@bruienne) July 12, 2014

The slides from both of my talks at #psumac are now up on my site. grahamgilbert.com/blog/categorie…—
Graham (@grahamgilbert) July 10, 2014

Here are the current slides from my Care and Feeding of Your IT Pro session. Thanks for the love #psumac. jimrisp.in/1zs866n—
Jim Rispin (@jimrispin) July 10, 2014

Slides, resources, etc., from my talk today at PSU MacAdmins 2014 about filing bugs with Apple. mboylan.me/WV8W #psumac—
Mike Boylan (@mboylan) July 09, 2014

Posting my PSU MacAdmins Conference presentation #psumac talkingmoose.net/?p=720—
William Smith (@meck) July 12, 2014

The slides @AlwaysDNS and I presented at our workshop this week have been added to our resource page. tinyurl.com/njr4m7c #psumac—
Gretchen K. (@osuterrycat) July 10, 2014

You can find my slides and link to the companion github repo for my Shell Building Blocks talk here: wp.me/pi1TO-fj #psumac—
Peter Bukowinski (@pmbuko) July 10, 2014

Slides from the FileVault 2 Session at Penn State MacAdmins 2014: derflounder.wordpress.com/2014/07/10/sli… #psumac—
Rich Trouton (@rtrouton) July 10, 2014

Slides from the "Extending OS X Management Systems with Scripting" Session at Penn State MacAdmins 2014: derflounder.wordpress.com/2014/07/12/sli…—
Rich Trouton (@rtrouton) July 12, 2014

Going MAD presentation: PSUMac 2014 wp.me/p37Zmx-O7—
Steve Yuroff (@swy) July 11, 2014

Photo: Slides from today’s talk: How to Survive as a Solo Admin tmblr.co/ZI7LYy1L155d5—
Tom Bridge (@tbridge) July 09, 2014

The Linde Group has released a new tool on Github: AutoPkgr, a GUI interface for AutoPkg. In my working with the initial release today, I’ve been impressed with the problems it solves for Mac admins who want to get started using AutoPkg but aren’t sure where to begin.

To use AutoPkgr, you will need to have the following pre-requisites:

1. OS X 10.9.x

2. Xcode and/or the Xcode Command Line Tools installed

3. Acceptance of the Xcode license agreement.

4. A logged-in user to run the AutoPkgr application in. This user can be a standard user or have admin rights.

Once the prerequisites have been met, see below the jump for details on installation and configuration.

Installing AutoPkgr

1. Download the latest version from the AutoPkgr release page.

2. Copy the AutoPkgr application to /Applications.

Using AutoPkgr

1. Open AutoPkgr and verify that both Git and AutoPkg are installed.

If not, AutoPkgr can install the latest versions for you using the Install Git and Install AutoPkg buttons available via the Install tab.

2. To configure AutoPkg‘s repos and recipes, click on the Configure Repos & Apps tab.

AutoPkgr will check GitHub for the AutoPkg repos available via https://github.com/autopkg and display the linked repos available for selection in the Repositories list.

If you need to add a repository, you can add it by entering it in the Add a repo URL manually: blank and clicking the Add button.

Note – 7-14-2014: You may need to manually add a repo to AutoPkgr before you’ll be able to select other repos.

Once a repo is selected, the repo’s AutoPkg recipes available will then appear in the Available Applications pane.

As more repos are selected, the associated AutoPkg recipes are automatically added to the Available Applications pane.

To add receipes to AutoPkg‘s run list, check the box next to the appropriate recipes to select them.

3. To configure AutoPkg to run on a schedule, click on the Configure Schedule tab

To configure AutoPkg to automatically run the selected recipes on a schedule, check the option for Check for new versions of apps every X hours and set an hour value.

To have changes to the AutoPkg repos automatically updated, check the option for Check for repo updates when AutoPkgr launches.

If you want to manually run the selected receipes with AutoPkg, click the Check Apps Now button.

If you want to manually update the AutoPkg repos, click the Update Repos Now button.

You can also be notified by email when AutoPkgr has completed running the selected recipes. To do this, check the option for Send email notifications when new versions are found.

Once checked, configure the mail settings as needed.

Once your mail settings are configured, you can test them by clicking the Send Test Email button.

You should receive an email that looks like the one below.

The notification emails currently look like the example below.

As I found the email in its current form a bit hard to parse, I’ve filed a feature request to improve the formatting. At this time, the response from the developers has been positive.

4. To access the AutoPkg receipe and download folders, click on AutoPkgr‘s Tools tab.

If you want to be notified about possible problems when quitting AutoPkgr, check the option for Warn Before Quitting AutoPkgr.

With this option enabled, the following warning will be displayed when quitting AutoPkgr.

Once the selected repos have been downloaded, the Open AutoPkg RecipeRepos Folder button becomes active.

Clicking the button will open a new Finder window directly to AutoPkg‘s RecipeRepos directory in /Users/username/Library/AutoPkg.

After AutoPkgr has completed its initial run of recipes, the Open AutoPkg Cache Folder button becomes active.

Clicking it will open a new Finder window directly to AutoPkg‘s Cache directory in /Users/username/Library/AutoPkg, which will give you access to the completed application installers.

5. To save your changes, click the Save and Close button.

When you click the Save and Close button, the AutoPkgr interface closes. To get back into it, locate the briefcase icon in the menubar and click Configure…

Once clicked, the AutoPkgr interface will re-open for editing.

For the initial release, AutoPkgr includes a lot of nice features and I’m looking forward to seeing how this application develops. One thing I didn’t test was the Munki-specific features, as I’m not a Munki user. If you’ve used AutoPkgr with Munki, please let me know your experiences in the comments.

I was interviewed on Tuesday, July 15, 2014 by the good folks behind Command-Control-power. I had a lot of fun doing it and they’ve now posted the interview at the following link:

http://commandcontrolpower.com/podcast/2014/7/20/059-interview-with-rich-trouton

Here’s links to the people, conferences and most of the tools that came up during the interview:

People

Tom Bridge – http://bits.tombridge.com

Graham Gilbert – http://grahamgilbert.com

Ed Marczak – http://www.radiotope.com

Conferences

Penn State MacAdmins – http://macadmins.psu.edu

MacSysAdmin – https://macsysadmin.se

MacTech Conference – http://www.mactech.com/conference/

WWDC – https://developer.apple.com/wwdc/

Tools

FileVault 2 – http://support.apple.com/kb/ht4790

fdesetup – https://developer.apple.com/library/Mac/documentation/Darwin/Reference/ManPages/man8/fdesetup.8.html

AutoPkg – https://github.com/autopkg/autopkg

Casper – http://www.jamfsoftware.com/products/casper-suite/

Munki – http://code.google.com/p/munki/

Hardware Encrypted External Drives
Ironkey – http://www.ironkey.com

As part of Firefox 31’s release, Mozilla made a change to enable support for NT LAN Manager version 1 (NTLMv1) network authentication when connecting to sites that are using HTTPS to allow encrypted communication via SSL between Firefox 31 and the website in question. This is to address the change made in Firefox 30, which disabled support for NT LAN Manager version 1 (NTLMv1) network authentication for sites using either HTTP and HTTPS.

NTLMv1 authentication to sites using HTTP is still disabled by default. For more information on why HTTPS is now enabled while HTTP remains disabled, this Mozilla bug report discusses the issue.

A way to tell if the NTLMv1-using site you’re trying to access is using HTTP or HTTPS is to check the connection address. If it begins with https://, you should be OK. If it begins with http:// , Firefox 31 will still block NTLMv1 authentication.

If you need to enable NTLMv1 authentication for an HTTP site that uses NTLMv1 authentication, Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication on HTTP sites, which will allow access again to SharePoint-based or IIS-backed web applications. For those folks who need it, I have the workaround documented here.

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:

The Extending OS X Management Systems with Scripting session I co-hosted with Jeremy Reichman is linked here:

I had an interesting issue crop up yesterday. One of our users sent in a ticket to report that Word 2011 on her laptop kept crashing with an EXC_BAD_ACCESS error. None of her other Office 2011 applications were exhibiting the behavior; it was specific to Word 2011.

When this error has cropped up in the past, I’ve fixed it in the past by removing Word’s Normal.dotm template from /Users/username/Library/Application Support/Microsoft/Office/User Templates or removing the com.microsoft preference files for the affected application from /Users/username/Library/Preferences.

So this time, I moved the following files to a new folder that I created on the user’s desktop:

/Users/username/Library/Application Support/Microsoft/Office/User Templates/Normal.dotm
/Users/username/Library/Preferences/com.microsoft.Word.plist

Then I logged the user out, asked them to log back in and had them relaunch Word. Crash. EXC_BAD_ACCESS error again. This was going to be an unusual one…

I double-checked to make sure that both the files I had moved had not recreated themselves. They hadn’t, Word had crashed before being able to detect that those files were not there.

I then spent the next hour doing the following:

1. Logging in as my local administrator to confirm that issue seemed to be confined to the user’s account.

Result: Word launched fine and without errors while logged in from the local admin.

2. Moving all of the various com.microsoft preference files and the Microsoft folder from /Users/username/Library/Preferences to the folder I had set up on the Desktop.

Result: Crash. EXC_BAD_ACCESS error.

3. Renaming /Users/username/Library/Application Support/Microsoft to /Users/username/Library/Application Support/Microsoft_backup to force the OS to create a new /Users/username/Library/Application Support/Microsoft folder with default settings.

Result: Crash. EXC_BAD_ACCESS error.

4. Booting from a NetBoot utility disk and clearing the contents of the following cache folders on the user’s boot drive:

/var/folders
/Library/Caches
/System/Library/Caches
/Users/username/Library/Caches

5. While still booted from the utility NetBoot, running DiskWarrior and a permissions repair on the user’s boot drive to make sure all my bases were covered.

After rebooting from NetBoot back to the user’s boot drive, I asked my user to log in again and relaunch Word. Crash. EXC_BAD_ACCESS error again. But this time, I caught a small “opening file” screen that was gone in an eyeblink because Word crashed immediately after the screen appeared. Word had been trying to open a file. Why? How? All the work I had done should have cleared out Word’s listing of recent files.

I stopped at that point and just thought through the process for a minute or so. Then I went into /Users/username/Library/Saved Application State and moved the com.microsoft.Word.savedState folder to the folder on the user’s desktop where I had been storing the other files that I had moved. After that, Word launched without a single error.

What had happened?

My user had been editing a file when Word initially crashed. When I asked her to open the file in question, Word instantly crashed with an EXC_BAD_ACCESS error. In the initial crash, the file had somehow corrupted.

After that, Word got trapped in a cycle. When Word launched, it queried the saved state which told it to open this file. When Word tried to open the file, it crashed instantly. On restart, it queried the saved state again. Saved state told it to open this file; CRASH. The only way to break out of the cycle was to get the saved state out of the loop, which allowed Word to launch without trying to open the corrupted file.

Fortunately, the document in this case was a file that the user had received that day via email from a colleague. They were able to recover the original file from her email and were able to save and edit the new copy of the document without Word crashing.

Saved states aren’t unique to Microsoft applications and any application on OS X that’s been updated to support saved states may also exhibit this behavior. If you see an application repeatedly behaving oddly on launch, try moving the corresponding saved state folder out of /Users/username/Library/Saved Application State and see if the behavior clears up.

I found myself wanting to pull together a mix of the best of the Penn State MacAdmins playlists, so I looked up both 2013 and 2014 playlists. For those who also want both Spotify playlists, please see the links below:

Penn State MacAdmins 2013 Spotify: http://spoti.fi/macadmins13

Penn State MacAdmins 2014 Spotify: http://tinyurl.com/psumacmusic

My thanks to @jaharmi for having the 2013 link available on his blog. Like him, I’m posting these links because I want an easy way to find them later.