In Mac OS X Server 10.7.x and 10.8.x, there’s been an issue that Mac admins have run into more than once:

“I’m trying to set up Open Directory in this VM, but the service won’t enable.”

Profile Manager in 10.7.x and 10.8.x also has an known issue where it crashes when set up in a VM. The root cause is the same: Profile Manager needs to have Open Directory running and Open Directory won’t turn on.

The fix for this issue in 10.7.x Server and 10.8.x Server is simple – give your VM more than one processor. Once you give the VM multiple processors (two is fine), Open Directory should begin working. This will also fix the Profile Manager crashing issue, as Open Directory should now enable properly.

In Mavericks, it appears Apple has addressed this issue. In my testing, Open Directory no longer requires multiple processors.

Now that Open Directory can run with one processor, Profile Manager also now runs properly on a one-processor VM.

A while ago, I needed to script a method for binding Macs running 10.6.x and later to our Linux-based OpenLDAP server. Recently, we needed to move our OpenLDAP domain to a different OpenLDAP domain as part of a larger directory service migration project. A small part of that project was moving the LDAP-bound Macs to the new LDAP domain, preferably with as little disruption as possible.

One enormous advantage I had with this LDAP move was the following:

All UIDs, GIDs, usernames, passwords and group names were going to be identical between the two LDAP domains.

As a consequence, I would not need to do any permissions changes, rebuild accounts, make sure people got new passwords or a host of other things normally associated with a directory service change. My task was essentially to tell the Macs “Stop talking to the OpenLDAP service at that address, start talking to this other OpenLDAP service at this address”

As part of the project, I also wanted to accommodate two separate Active Directory domains differently. I wasn’t binding to AD as part of this process, but if a particular Mac was bound to Domain A, I wanted to unbind. If a Mac was bound to Domain B, I didn’t want to unbind but I did want the new LDAP server to be the primary authentication source.

Using my previous OpenLDAP binding script as a starting point, I was able to build a script to handle moving our Macs without downtime or account changes. See below the jump for details.

This script will allow a Mac to connect to an OpenLDAP server using a simple anonymous bind and can be used to migrate a Mac from one LDAP server to another. It has been tested on Mac OS X 10.6.8, 10.7.5, 10.8.5 and 10.9.0.

If you are adapting this for your own use, run a search and replace for the following:

“dc=replaceme,dc=org” (no quotes)

You’ll need to replace that with your own LDAP search base

“ldap.server.here” (no quotes)

You’ll need to replace that with the fully qualified domain name of your OpenLDAP server.

The script is designed to check for the following:
1. Is the Mac bound to the old LDAP server?
2. Is the Mac bound to one of two AD domains:

Domain A (referred to in the script as OLDDOMAIN or olddomain.com)
Domain B (referred to in the script as NEWDOMAIN or newdomain.com)

The script will then perform the following actions:

If the Mac is bound to the old server and Domain A:
Remove the old LDAP server settings, add the new LDAP server settings, unbind from Domain A, and set the new LDAP server to be the primary authentication source.

If the Mac is bound to the old server and Domain B:
Remove the old LDAP server settings, add the new LDAP server settings, do not unbind from Domain B, and set the new LDAP server to be the primary authentication source

If the Mac is bound to the old server and not bound to AD:
Remove the old LDAP server settings, add the new LDAP server settings, and set the new LDAP server to be the primary authentication source.

If the Mac is bound to neither LDAP or AD:
Add the new LDAP server settings and set the new LDAP server to be the primary authentication source.

For those interested, I’ve made the script available here on my GitHub repo. I’ve also posted the script below.

Inspired by the folks over at macbrained, Tom Bridge and Justin Rummel are starting a DC-area Mac Admins group.

If you’re interested in learning more, please sign up here and follow @mac_dmv on Twitter.

As part of a domain migration project, I was recently tasked with figuring out a way to handle migrating the Macs from one AD domain to another. I had the following requirements:

1. Unbind the Mac from the old AD domain
2. Bind the Mac to the new AD domain
3. Migrate the user’s data from the old AD domain to the new AD domain

Preferably, it would be a procedure that anybody could use. That way, anyone on the team could be perform the migration process regardless of their personal skill level with Macs.

I had a pre-existing interactive script that I could modify and use to fulfill requirement 3, but I needed a way to fulfill requirements 1 and 2.

With some help from DeployStudio, I was able to develop an unbind / rebind procedure that fulfilled requirements 1 and 2. It also gave me the following features:

1. Anyone on our helpdesk team could do it, regardless of familiarity with Macs or Active Directory.
2. Potential for human error was minimized
3. Reboots (generally a good idea when making directory service changes) were a built-in part of the migration process.

For details, see below the jump.

To perform the migration process, I built a new workflow in DeployStudio. For the purposes of this example, the workflow is named as follows:

Rename and Re-bind a Company Mac to the new AD Domain

The workflow has the following components:

1. Set the system time using a network time server.

The reason for this step is to ensure that the system clock is set to the correct time before binding the Mac to the new AD domain. If the time is off, the AD bind will fail.

2. Name the Mac (in case a name change is needed as part of the domain change.)

3. Force unbind the Mac from the old AD domain

For this step, I use a payload-free package based on a script available from my GitHub repo.

This script uses a username and password that won’t exist in AD, so the AD computer object won’t be removed from the domain that this Mac is migrating from. However, this domain is being retired so leaving behind the computer object didn’t matter in this case.

4. Bind the Mac to the new AD domain

5. Re-set the time server settings

The reason for this last step is that setting the system clock in step 1 removes the Mac’s previous time server settings. I use a payload-free package based on this script to set the Mac’s time server settings back to what they should be.

Once the workflow was built, here’s the process to migrate the Mac.

1. Boot the Mac you want to migrate to DeployStudio.

2. Log in and select the Rename and Re-bind a Company Mac to the new AD Domain workflow.

3. Select the boot drive of the Mac being migrated as the target volume.

4. Run the workflow

5. Once the workflow finishes, select Quit when prompted. Your Mac should reboot at this point.

On restart, the Mac will automatically unbind itself from the old AD domain, bind itself to the new AD domain and re-set the time server settings.

Once the Mac has been finished running the DeployStudio workflow tasks, it will reboot again. The Mac should now be bound to the new AD domain.

Once the Mac has been bound to the new AD domain, the next step is to migrate the existing AD accounts on the Mac. I recommend using the previously-mentioned interactive script to migrate the users’ data from the old AD account to the equivalent account on the new AD domain.

I was recently wrong on the internet again, but as always making a mistake gave me a chance to learn from it. What I learned was the method Mac admins choose to use upgrading their Macs to Mavericks may have behavior that apply specifically to FileVault 2-encrypted Macs. See below the jump for details.

There are two main ways that Mac admins are generally upgrading Macs to Mavericks:

1. createOSXInstallPkg: createOSXInstallPkg is a tool created by Greg Neagle. It is used to build individual installer packages that can install OS X Lion, Mountain Lion or Mavericks.
2. Apple’s Mavericks installation methods: Apple’s installation methods include using Install OS X Mavericks.app, install media created by using Apple’s createinstallmedia tool and NetInstall / NetRestore .

When upgrading a FileVault 2-encrypted Mac to Mavericks, you may see the following behavior when rebooting as part of the upgrade process:

createOSXInstallPkg – The Mac will boot to the FileVault 2 pre-boot login screen and require an account password to unlock. Once provided, the Mac boots and the upgrade process will proceed.

Apple’s Mavericks installation methods – The Mac will reboot without stopping at the pre-boot login screen during the upgrade process. Once the upgrade process is completed, the Mac will resume the expected behavior of booting to the FileVault 2 pre-boot login screen.

The difference has to do with which OS’s installation method is being used. Greg reverse-engineered 10.7′s installation process (see timestamp [18:43:31 UTC]) when he built createOSXInstallPkg (originally known as InstallLionPkg). That installation method does not include the Apple Mavericks installer’s ability to store an unlock key in system memory or the SMC so the disk is not automatically unlocked at boot. With the disk being locked, the Mac will boot to the FileVault 2 pre-boot login screen so that it can be unlocked. To help illustrate this, I’ve made a video showing the behavior.

Apple’s installation method does include putting an unlock key in memory, so the Apple Mavericks installer will keep supplying the unlock key as needed until the upgrade process is completed. At that point, the process that stores the key in memory stops running and the Mac goes back to the expected boot behavior where the Mac boots to the FileVault 2 pre-boot login for authentication before unlocking the disk. To help illustrate this, I’ve made a video showing the behavior.

When upgrading a FileVault 2-encrypted Mac to Mavericks, you may see the following behavior if the disk being upgraded is in the process of encrypting or decrypting:

createOSXInstallPkg – Installation of the createOSXInstallPkg installer fails.

Apple’s Mavericks installation methods – Upgrade proceeds without errors.

The difference here has to do with lines 835 – 858 of the postflight script in a createOSXInstallPkg-built OS X installer.

target_volume_is_corestorage_or_raid = False
    # check the install volume to see if it's CoreStorage
    cs_state = getCoreStorageStatus(installvolumepath)
    if cs_state in ['Encrypted', 'Not encrypted']:
        target_volume_is_corestorage_or_raid = True
        # make sure we can find the Apple_Boot helper partition before
        # we continue
        helper_partitions = findBootHelperPartitions(installvolumepath)
        if not helper_partitions:
            cleanupFromFailAndExit(
                'Cannot find a Recovery partition set as a boot helper for '
                'CoreStorage volume %s. Cannot continue.' % installvolumepath)
        print ('%s appears to be a CoreStorage volume.' 
                % installvolumepath)
    elif cs_state == 'Not CoreStorage':
        target_volume_is_corestorage_or_raid = False
    else:
        # volume is being converted to or from Core Storage
        # we should not install now.
        cleanupFromFailAndExit(
            'Cannot install to CoreStorage volume %s in the middle of '
            'conversion. Current state is: %s.\nPlease wait for conversion '
            'to complete, restart, and try again.' 
            % (installvolumepath, cs_state))

As a safety check, this section of the postflight script checks to see if target drive has a CoreStorage volume and if it is in the process of converting. A converting CoreStorage volume means the drive is either being encrypted or decrypted.

If a converting CoreStorage volume is detected, this section of the postflight script prevents the install process from proceeding. In turn, the installer stops and reports an installation failure. To help illustrate this, I’ve made a video showing the behavior.

Apple’s Mavericks installation methods does not include this check and proceeds without errors on a converting CoreStorage volume. To help illustrate this, I’ve made a video showing the behavior.

One of my users ran into an issue recently when launching Microsoft Lync. When the Lync application logged into the Lync server, a Microsoft Lync wants to use OC_KeyContainer_username@company.com. Please enter the keychain password prompt appeared.

The curious thing was that the keychain prompt would not accept the user’s current login password. When I checked, the user’s login keychain was unlocked and using the current password, so it didn’t appear to be caused by the login keychain password issues that I normally deal with.

After some research, I was able to find the answer and get this issue fixed. See below the jump for the details.

The fix:

1. Quit out of Microsoft Lync

2. Go to /Users/username/Library/Keychains

3. Remove the OC_KeyContainer__username@company.com file from /Users/username/Library/Keychains.

4. Launch Microsoft Lync

5. On relaunch, the prompt no longer appeared.

What caused the password prompt?:

Microsoft Lync creates a keychain file to store encryption keys. The file is physically stored in /Users/username/Library/Keychains and is named something similar to OC_KeyContainer__username@company.com.

The password for this keychain is not tied to the user’s account password and it looks like the Lync program itself will automatically generate a randomized password for it. The password to unlock that keychain is then stored in the user’s login keychain.

Occasionally, something in Lync happens that causes this keychain to refuse to work properly. In that event, a pop-up may appear requesting a password.

Removing the OC_KeyContainer__username@company.com keychain file will force Lync to create a new one.

When Lync is relaunched, it will generate a new OC_KeyContainer__username@company.com keychain file with a new randomized password and store it in /Users/username/Library/Keychains.

An interesting thing about this OC_KeyContainer keychain and associated password entry is that the persistence of it appears to be tied to whether or not Lync is set to save the user’s account password.

If the password is set not to be saved:

The OC_KeyContainer__username@company.com keychain and OC_KeyContainer__username@company.com password entry in the user’s login keychain are created when Lync connects to the Lync server.

Once the Lync application is quit, the OC_KeyContainer__username@company.com keychain and application password entry are automatically deleted. On relaunch, a new OC_KeyContainer__username@company.com keychain and application password entry in the user’s login keychain are created.

If the password is set to be saved:

If they do not already exist, the OC_KeyContainer__username@company.com keychain and OC_KeyContainer__username@company.com password entry in the user’s login keychain are created when Lync connects to the Lync server. A Microsoft Lync password entry is also created in the user’s login keychain if one does not already exist.

Once the Lync application is quit, the OC_KeyContainer__username@company.com keychain and application password entry persist and are not automatically deleted. On relaunch, Lync will look for and re-use the existing OC_KeyContainer__username@company.com keychain and OC_KeyContainer__username@company.com password entry.

As part of a project to assess the deployment options for National Instruments’ LabVIEW 2013 Pro, I was asked to see if I could deploy it through Casper’s Self Service. After some work, I was able to repackage the installer in a way that deploys smoothly. In the process, I saw a number of ways that this particular installer went against The Commandments of Packaging. See below the jump for details.

National Instruments shipped us a DVD with the installer on it and the installation instructions were essentially “put the DVD into the machine and then run the installer.” I followed those instructions in a test virtual machine and everything installed fine.

So far, so good. But I wouldn’t be able to install LabVIEW from Self Service this way, so I copied the LabVIEW 2013 Pro installer metapackage from the DVD and then tried to install into an otherwise identical VM. This time, the installation succeeded but now I had no drivers. I also saw errors showing up in the installation log that complained about missing installers.

I went back and double-checked the metapackage carefully to make sure that it was only referring to packages contained within itself. As far as I could tell, it was.

Then I started going through the metapackage’s embedded installer packages and found three installer packages with post-installation scripts that made me unhappy.

Postflight script from LabVIEWServiceLocator 2013.pkg

#!/bin/sh

chmod g-w /Library/LaunchDaemons
launchctl load /Library/LaunchDaemons

This postflight script assumes that the installer is being installed on the same drive that the Mac is currently running from. That goes against Commandment #1: Do not assume that your package will be installed interactively via the GUI or on the currently booted volume.

Postinstall from LabVIEWGPIBShell 3.0.1.pkg

#!/bin/sh

sudo rm "/Library/Application Support/National Instruments/.placeholder"
sudo installer -pkg "$PACKAGE_PATH/../../../../Drivers/GPIB/ni4882.mpkg" -target / -dumplog -verboseR

Postinstall from LabVIEWVISAShell 5.4.0.pkg

#!/bin/sh

sudo rm "/Library/Application Support/National Instruments/.placeholder"
sudo installer -pkg "$PACKAGE_PATH/../../../../Drivers/VISA/nivisai.mpkg" -target / -dumplog -verboseR

These two packages also go against Commandment #1 and find unusual ways to do so. These scripts assume that the installer is being installed on the same drive that the Mac is currently running from. The script also assumes that the additional ni4882.mpkg and nivisai.mpkg installers that are being installed by these scripts are at a certain fixed location. This assumption is true if you’re installing the LabVIEW 2013 Pro installer from the DVD. Change anything about where the LabVIEW 2013 Pro installer is located and the referenced installers won’t be found.

This explained why I was seeing errors in the install log. It also explained why the drivers weren’t being installed, as the installer packages referenced in the scripts installed the drivers. The fact that the scripts were using sudo to run the included commands with root privileges, when the scripts’ commands were already being run with root privileges, was just a bad scripting bonus.

Once I had this information and understood what was going on, here’s how I repackaged LabVIEW so that it could be deployed via Casper’s Self Service.

Prerequisites:

Packages

A disk image made of the LabVIEW 2013 install DVD

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

2. In this case, I’m naming the project LabVIEW 2013 Pro

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.

NOTE: The LabVIEW Pro software does require a restart to allow the application to work properly. I am planning to handle the restart via Casper, but if you’re installing via other means, you may want to set the Post-Installation Behavior to On Success: Require Restart.

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

6. Select the LabVIEW 2013 disk image and drag it into the Additional Resources section of your Packages project.

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

#!/bin/bash

# Determine working directory

install_dir=`dirname $0`

#
# Installing LabVIEW 2013 Pro
#

# Specify location of the LabVIEW 2013 Pro disk image

  TOOLS=$install_dir/"LabVIEW 2013  Pro.dmg"

# Mount the latest LabVIEW disk image to /Volumes

  hdiutil attach "$TOOLS" -nobrowse -noverify -noautoopen

# Install the LabVIEW software

  /usr/sbin/installer -dumplog -verbose -pkg "/Volumes/LabVIEW 2013  Pro/LabVIEW 2013 Pro.mpkg" -target "$3"

# Clean-up

# Unmount the LabVIEW disk image from /Volumes

  /usr/bin/hdiutil detach "/Volumes/LabVIEW 2013  Pro"

# Fix world-writable permissions in /Applications/National Instruments

chmod -R o-w "/Applications/National Instruments"

exit 0

The logic of this script is as follows:

Since I was only successful when installing the software from the DVD, mimic the environment that the DVD creates.

A. Mount the disk image in /Volumes using the same volume name as the DVD

B. Run the installer from the mounted disk image, so that all of the assumptions made by the install scripts mentioned above will be true.

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

Once the package has been built, test it by taking it to a test machine that does not have LabVIEW 2013 and install it. The end result should be that LabVIEW 2013 installs along with the correct drivers.

Once it was installed, one thing I noted about the National Instruments directory that is installed by the LabVIEW Pro installer into /Applications was that it seemed to have a number of world-writable files and directories. When I ran a check for world-writable files and folder inside /Applications/National Instruments, here’s the list I got back:

World-writable files can be a security issue, so I added a line in my postinstall script to fix this by removing the world-writable permissions. The application is owned by root and gives write permissions to members of the admin group (like a number of other Mac applications), so I figured that would be fine. That opinion lasted until I actually tried to save a driver template in LabVIEW Pro. By default, LabVIEW wants to save the new driver into a subfolder located inside the National Instruments directory in /Applications.

This flies in the face of how saving files on the Mac is supposed to work, but it did explain why so many files and folders were world-writable; the application assumes the user will be saving files into those directories or otherwise writing to them.

In my case, the users who would be running this software have admin privileges so removing the world-writable permissions won’t affect my shop. Environments who don’t give users admin rights may need to make other arrangements to deal with this issue.

Before IRC, AOL Instant Messenger and Apple’s Messages, there was talk. talk is a Unix text chat program, allowing messaging between users of Unix-based systems. While it’s been largely superseded by other chat applications, it’s still included with OS X Mavericks as the ntalk service.

Setting up a talk server on OS X

To start the talk server on OS X, run the following command to start the ntalk service:

sudo launchctl load -w /System/Library/LaunchDaemons/ntalk.plist

To stop a running talk server, run the following command to stop the ntalk service:

sudo launchctl unload -w /System/Library/LaunchDaemons/ntalk.plist

Using talk

It’s pretty straightforward to use talk. To talk to another user logged in on the same host, use this command:

talk username_here

To talk to a user on another host, use this command:

talk username_here@hostname

Once communication is established, the two parties may type simultaneously, with their output appearing in separate windows. One thing to know is that output is reflected live to both sides; every character typed (typos and all) will be visible.

Reprint screen – Typing control-L will cause the screen to be reprinted.
Clear screen – Typing control-D will clear both parts of your screen to be cleared, while the control-D character will be sent to the remote side (and just displayed by this talk client).
Exit current talk session – To exit, type control-C.

For more information on talk, please see the man page:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/talk.1.html

With Apple’s release of OS X 10.9.1, it looks like the automated FV 2 unlock process that Apple built into the Mavericks install process has been included with OS X updates. To illustrate, I’ve made a video showing the following process:

• Logging into a FileVault 2 encrypted Mac
• Verifying that I was on 10.9.0 and encrypted
• Opening the Mac App Store and installing the 10.9.1 update
• Mac reboots and bypasses the FileVault 2 pre-boot login screen
• Mac automatically logs into my account

Note: The video has been edited to artificially reduce the amount of time the install process takes to run. Run time of the pre-edited video was 14 minutes.

How is the pre-boot login screen bypassed?

During the upgrade process, an unlock key is being put into the SMC by the update process to unlock the encrypted volume at boot. The reboot process then automatically clears the key from the SMC. This process is similar to how fdesetup authrestart works, except that the user is not being prompted to authorize it.

How is the Mac automatically logging into my account following the update?

This question is unresolved at this time and this behavior is worrisome to me. Walking away at the wrong moment may give an opportunity for someone to get physical access to my Mac without my knowledge.

The length of that window of vulnerability is going to be determined by when the screensaver kicks in, as enabling FileVault 2 will also set your Mac to require your account’s password before exiting the screensaver.

Do you have information about how the Mac is automatically logging into an account after an update? Please let me know in the comments.

A change that occurred between Mountain Lion and Mavericks is that it’s no longer possible to add additional users with fdesetup by using a non-enabled admin user’s credentials. Instead, you must use either a previously-enabled user’s credentials or use a personal recovery key (aka an individual recovery key) to authorize adding a user account with fdesetup add.

The recovery key option is specifically for the personal recovery key; there is not an option in fdesetup add to use the institutional recovery recovery. This is an issue for IT shops that are using fdesetup enable with the -defer option in combination with an institutional recovery key because the Mavericks way to authorize additional accounts depends on an enabled user’s password (which in this case would be an end-user’s password) or a personal recovery key (which doesn’t exist.)

There is a way to fix this in a roundabout way, by leveraging the ability of fdesetup in Mavericks to generate a new personal recovery key using fdesetup changerecovery. fdesetup changerecovery allows the use of an institutional recovery keychain to authorize the generation of a new personal recovery key. To do this, run the following command:

sudo fdesetup changerecovery -personal -key /path/to/keychain_with_both_private_and_public_recovery_keys_inside.keychain

You’ll be prompted for the password to unlock the institutional recovery keychain. Once that password is provided, a new personal recovery key will be generated.

To verify that this new recovery key is valid, run the following command:

sudo fdesetup validaterecovery

If the new personal recovery key is valid, you should receive a result of “true”.

fdesetup can also export the recovery key to a plist file by using the -outputplist flag. To generate a new personal recovery key and have it exported to a plist, run the following command:

sudo fdesetup changerecovery -personal -key /path/to/FileVaultMaster.keychain -outputplist > /path/to/new_recovery_key.plist

The plist should contain information similar to what’s shown below and include the new personal recovery key information in the RecoveryKey plist value.

<?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>Change</key>
	<true/>
	<key>EnabledDate</key>
	<string>2013-12-20 13:51:58 -0500</string>
	<key>HardwareUUID</key>
	<string>00000000-0000-1000-8000-000C2991B2C4</string>
	<key>HasMasterKeychain</key>
	<true/>
	<key>RecoveryKey</key>
	<string>MLZA-NZTC-MVLM-O82Q-Y8TW-F8FX</string>
	<key>SerialNumber</key>
	<string>VM401BlpPKGn</string>
</dict>
</plist>

fdesetup changerecovery doesn’t currently include a way to utilize the institutional recovery keychain without requiring a password to be entered, but it is possible to automate the password entry process using an expect script or other means. As an example, I’ve written an expect script which automates running the fdesetup changerecovery process described above to generate a new personal recovery key and export it to a plist.

If you want others to be able to temporarily use your computer, but you don’t want to create an account for each user, Mac OS X allows you to create a guest account. This guest account allows a person to log in to the Mac without entering a password, but the account type has the following limitations:

1. Guest users can’t make changes to other user accounts.
2. Guest users can’t change setting on the computer.
3. Guest users can’t log in remotely.
4. Files created by guest users are deleted when the user logs out. As part of this, a temporary home folder is created for the guest’s files but this folder and its contents are deleted when the user logs out.

By default, OS X only allows the creation of a single guest account with the name of Guest. That said, it is possible to create custom guest accounts with names that are different from Guest. This would allow Mac admins to create multiple guest accounts if needed. See below the jump for more details.

I’ve built a script for creating a custom guest account, based on earlier work by Noel B. Alonso. The script is available below and has been tested on Mac OS X 10.6.8 – 10.9.1.

I also have this script available on my GitHub repo:

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

One thing to be aware of is that, if the login window is set to show icons instead of the username and password blanks, all guest accounts created will show up with a Guest User account icon regardless of the account’s name.

If you need to have multiple user accounts, I recommend setting the login window to display username and password blanks and then logging in with the relevant username.

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 530,000 times in 2013. If it were an exhibit at the Louvre Museum, it would take about 23 days for that many people to see it.

Click here to see the complete report.

Oracle released Java 7 Update 51 on January 14th. As part of the installation, the Java security level is set by default to High. With this security setting, self-signed and unsigned applets are blocked from running. This can be verified by going to http://javatester.org/version.html, as this site uses an unsigned Java applet.

Fortunately, it appears that there are a couple of ways to fix this. See below the jump for details.

Adding the site to the Exception Site List

It is possible to whitelist specific sites, which allows the ability to access those specific sites and run Java applets and Java Web Start applications that do not meet the latest security requirements.

To add sites to the Exception Site List on Mac OS X 10.7.x – 10.9.x:

1. Open System Preferences

2. Click on the Java preferences

3. In the Java Control Panel window, select the Security tab.

4. Click the Edit Site List… button

5. In the Exception Site List window, click the Add button.

6. Enter the site(s) you want to whitelist.

Note: If you are adding sites starting with HTTP, you will have to confirm that you want to add the site.

7. When finished, click the OK button.

8. Click the Apply button if needed.

9. Click the OK button to close the Java Control Panel window.

10. Close System Preferences.

Lowering the security level

It is also possible to lower the security level to Medium, which is the least secure setting. At this security level, all Java applications are allowed to run after presenting a security prompt.

To set the security level to Medium on Mac OS X 10.7.x – 10.9.x:

1. Open System Preferences

2. Click on the Java preferences

3. In the Java Control Panel window, select the Security tab.

4. Move the Security Level slider from High to Medium.

5. Click the Apply button.

6. Click the OK button to close the Java Control Panel window.

7. Close System Preferences.

If all goes well, you should now be able to run the needed Java applet.

Older versions of Java applets used by Juniper’s SSL VPN may be blocked from working properly by security changes in Java 7 Update 51. When the applet is blocked, an error message like this will appear:

SecurityException: Missing required Permissions manifest attribute in main jar: https://server.name.here/dana-cached/sc/JuniperSetupClientApplet.jar

The root cause is that Java 7 Update 51 now requires the existence of the referenced permissions attribute, along with a requirement to code sign all Java applets. The applets used by older versions of Juniper’s SSL VPN do not include the permissions attribute.

The fix is to update the SSL VPN with Secure Access (SA) version 7.1R17, 7.3R9, 7.4R7, 8.0R1 and later versions. The applets included with these versions have the needed permissions attribute. Until the VPN server is upgraded, Juniper’s recommended workaround is use Java 7 Update 51′s Exception Site List feature. To help with this, I have a post showing how to add sites to the Exception Site List in the Java Control Panel settings.

One of my users was having a problem with meeting invites on his iPhone and iPad, where he would accept a meeting in Outlook 2011 and the meeting would show up afterwards as a new invite on his iDevices. He’d accept it there and it would be fine for a while, until he went to check something about the meeting in Outlook. At that point, his iDevices would again get a new meeting request for the already-accepted meeting that he had just looked at.

After a lot of re-accepted meetings and frustration, a solution was finally found. See below the jump for details.

The issue was that Exchange was set to automatically put new meeting requests with a status of Tentative onto his calendar. For some reason, just accessing the meeting entry on the calendar was triggering Exchange to mark the entry as a new meeting invite and update his iDevices.

The fix was to stop that automatic processing from happening. Here’s how to do it:

1. Log into Outlook Web Access

2. At the top right corner of the browser window, click Options and select See All Options…

3. Select Settings in the left menu, then click on the Calendar icon.

4. Uncheck Automatically place new meeting requests on my calendar, marked Tentative.

5. Click Save at the bottom of the page.

Once this was done, the recurring new meeting request behavior stopped.

Oracle’s Java 7 Update 51 has introduced new security requirements for browser plugins for applets and web start applications. However, not all applets are able to run using the new requirements. To help with this, Oracle has included a way to whitelist specific sites using Java 7’s new Exception Site List. This allows the applets and web start applications hosted on the specified sites to continue to work, even if they don’t meet the new security requirements in Java 7.

On Mac OS X 10.7 and higher, the Exception Site List is a plaintext file named exception.sites, which is stored in /Users/username/Library/Application Support/Oracle/Java/Deployment/security.

To help Mac admins manage the Exception Site List, I’ve written a script which is designed to add websites to Oracle’s Java 7’s Exception Site List without overwriting existing entries. For more details, see below the jump.

Since these settings are stored on a per-user basis, I’ve written a script and launch agent combination. The LaunchAgent runs the script on login to any user account with the logging-in user’s privileges and permissions.

As written, the script will add two servers to the Oracle Java Exception Site List. If the servers are already in the whitelist, it will note that in the log, then exit.

The script and launchagent are available here on my GitHub repo:

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

It’s been a long time coming, but Java 6 on OS X has hit the end of the road for updates. Mike Swingler has posted a message to the Apple java-dev list that confirms that no further Java SE 6 updates are available for any platform, including OS X. Java for OS X 2013-005 and Java for Mac OS X v10.6 Update 17 are the latest versions available and install Java SE 6 build 1.6.0_65.

As part of this post, I’d like to say thanks to the Java folks at Apple for going above and beyond. Apple’s last Java 6 update was released in Oct 15, 2013, which was a full eight months after Oracle discontinued updates for other platforms. This allowed some vulnerabilities in Java 6 to be addressed that otherwise wouldn’t have been.

For those who need them, download links for Java for OS X 2013-005 and Java for Mac OS X v10.6 Update 17 are available below:

Java for OS X 2013-005

Java for Mac OS X v10.6 Update 17

As I’ve mentioned previously, Apple does at least one thing with each new OS release that a) annoys me and b) makes me wonder about the thought process that went behind it.

In Mavericks, it’s smart quotes. These are quotes that are curved in shape and face in different directions, depending on if they’re opening quotes or closing quotes.

Having smart quotes is inconvenient for me because I can’t always tell when they’re in use until I copy and paste. If I’m copying and pasting content into a script, smart quotation marks aren’t recognized as legal quote marks, which means I have to find and replace them.

Fortunately, it’s possible to turn smart quotes off. See below the jump for details.

There’s two places I know of where you may need to turn off smart quotes:

A. System Preferences

B. TextEdit

To disable smart quotes via System Preferences:

1. Open System Preferences

2. Select the Keyboard preference pane

3. Select the Text tab in the Keyboard preferences

4. Uncheck Use smart quotes and dashes

To disable smart quotes in TextEdit

1. Launch TextEdit

2. In the TextEdit menu, select Preferences…

3. Uncheck Smart quotes and Smart dashes

4. Close the the Preferences window

5. In TextEdit’s Edit menu, select Substitutions

6. Under Substitutions, uncheck Smart Quotes and Smart Dashes

Once smart quotes have been disabled, quotes should return to being non-curly quotes marks.

Other applications may have smart quote settings, so you may need to check in the application settings.

After some VMware host issues that were out of my control, the RHEL VMs that my production and test Casper servers are hosted on were unexpectedly rebooted a couple of times. When I checked the VMs afterwards, everything appeared to be OK. I figured that I had been fortunate, until my Casper test server sent me the nightly “Successful backup of the Casper database” email and my production server didn’t.

Uh oh.

When I checked the directory when my production server stores its backups of the Casper database, there wasn’t a backup from the night before. I immediately launched the JAMF Database Utility application and had it make a backup of the production database. A task which normally would take 10 minutes or so now took 40 minutes.

Not good.

To lighten the load on the database, I went into the JSS and had it manually flush all but the last week’s worth of logs (I normally retain 30 days of logs.)

Once the log flush had completed, I then rebooted the box. On reboot, the JSS initialized and then hung halfway through the JSS startup process.

Really not good.

For the details of how I fixed this, see below the jump.

Casper’s JSS server software comes in two parts, a Tomcat web application and a MySQL database named jamfsoftware. As far as I could tell, the Tomcat part was OK but was having problems communicating with Casper’s jamfsoftware MySQL database.

To ensure that my Casper-managed Macs were not trying to update the database while I was working on fixing it, I stopped the Tomcat web application by running the following command as root:

/etc/rc.d/init.d/jamf.tomcat7 stop

I then restarted MySQL with the following command:

/etc/init.d/mysqld restart

After the MySQL restart, I ran the following mysqlcheck command to repair the database:

mysqlcheck -repair jamfsoftware -u root -p

In this case, mysqlcheck was set to repair all of the tables in the jamfsoftware database.

90 minutes later, the repair process had finished checking and repairing the database. I then ran optimization with mysqlcheck using the following command:

mysqlcheck -o jamfsoftware -u root -p

Since the database tables had just been repaired, optimization finished within seconds. I then rebooted the server. I could have just restarted the Tomcat web application, but I wanted to make sure everything worked on restart.

On restart, the Casper service started up normally. Later that night, I once again received the nightly “Successful backup of the Casper database” email from both my test and production servers.

In my shop, we use a number of Canon ImageRunner printers and have them set up in Casper’s Self Service so that our users can set them up themselves. All of the Canon printers in question have PostScript enabled, so I’ve been deploying the Canon PostScript drivers.

Historically, one of the things that was installed along with the drivers was a proprietary printing application that sat between the Mac’s CUPS printing system and the actual printer. That changed with the release of Canon’s 4.x PostScript drivers. With the new drivers, Canon has switched to using LPR and no longer uses that proprietary printing application.

Good news: Canon is no longer building in a custom printer program to handle talking to the printer; instead the new drivers are using LPR.

Bad news: Our existing printer setups that are available in Self Service do not work with the new printer drivers. I would need to delete and re-add our various printers to Self Service.

The bad news wasn’t a big problem by itself, but my testing showed that updating the printers in Self Service to accommodate the new printer drivers would make them no longer backwards-compatible with the old drivers. The new drivers would need to be installed in order for the new printers to work. Conversely, just pushing out the new drivers to our Macs could result in existing printer setups breaking.

In short, here were the problems I was looking at:

1. The old printer setups could not use the new drivers

2. The new printer setups could not use the old drivers

3. The new drivers needed to be installed before the new printer setup happened.

4. I didn’t want to break existing printer setups if I could avoid it.

Making the new drivers available in Self Service as standalone installers wasn’t an issue but I was concerned about adding them to the printer setups themselves. That potentially could result in the printer drivers being installed over and over again as people set up multiple printers on one Mac. I also wanted to avoid problems with accidentally trying to overwrite newer drivers, in the event that Canon released new drivers and someone installed them before I updated the driver installer in Self Service.

For details on how I addressed this, see below the jump.

Here’s the workflow I wanted to use when a Canon printer setup is requested via Self Service:

A. Casper will check the Mac to see if the needed Canon printers are installed.

B. If no Canon drivers or older Canon drivers are detected, the appropriate Canon print drivers will be installed before the requested printer is set up.

C. If the installed drivers are the same version or higher as the print drivers available via Self Service, no drivers are installed and Casper will proceed to set up the printer using the installed drivers.

The first part was figuring out if the needed Canon drivers were installed. Canon’s installer package didn’t have an easy way I could see to discern the driver version from the installer receipts, so I looked for something else that would have the version number. After some digging, I was able to confirm that the Canon CUPS PS Printer Utility application located in /Library/Printers/Canon/CUPSPS2/Utilities had the version number that I was looking for.

I also confirmed that I could use the defaults command to pull the version information from the CFBundleVersion key value stored in /Library/Printers/Canon/CUPSPS2/Utilities/Canon CUPS PS Printer Utility.app/Contents/Info.plist.

Using this information, I built the following script:

The script checks /Library/Printers/Canon/CUPSPS2/Utilities/Canon CUPS PS Printer Utility.app/Contents/Info.plist for the CFBundleVersion key value. Based on the key value, the following actions are taken:

- If the value returned is less than the version of the current drivers, the print drivers are installed by a Casper policy before the requested printer is set up.

- If the installed drivers are the same version or higher as the print drivers available on the Casper server, this information is logged and the Canon print drivers are not installed.

The driver version that the script is looking for is then set on the JSS by using Parameter 4 in the JSS settings for the script. As of 2-6-2014, the current version is 4.1.0.

The script uses a manual trigger to run a Casper policy that would install the print drivers. The next part was to build a policy which used that trigger.

Building the policy was straightforward, as I just needed it to respond to the manual trigger and install the package specified by the policy. When new Canon drivers come out, all I should need to do is update the policy with the new installer package.

Once I had the script and policy in place, I updated my printer setup policy with the new printer settings and added the previously-mentioned script. When added, I set the script to Run Before and set 4.1.0 in the Parameter 4 blank.

The other policy options were set as shown below:

The result is how it appears at the user’s end. When the printer setup is selected, the script will run before the printer setup and do its version check.

If new drivers are needed, a message will appear to inform the user that the drivers are being installed.

Once the printer setup has completed, a message will then appear to let the user know that the printer setup has completed.

One issue that this process does not address is the problem of existing printer setups. In the documentation for the new drivers, Canon noted that existing printers may need to be deleted and re-setup following the installation of the new drivers. Since the new drivers are now automatically installed on an as-needed basis by Self Service, existing printers may break.

That said, if all relevant Canon printers are registered in Self Service, the fix should be to tell folks with this problem to delete the non-working printer and set up the printer again in Self Service.