For the past few major releases, Oracle has used a standard installer package to install Java 7 and Java 8. With the release of Java 8 Update 40 though, Oracle changed how Java 8 for Macs is installed. Oracle has now switched to using an application to install Java.

This switch away from using installer packages is a problem for Mac admins who need to deploy Oracle’s Java 8 in their own environment. However, after doing some research, it looks like it is still possible to deploy Oracle’s Java 8 Update 40 using a standard installer package. For more details, see below the jump.

While the Oracle install application is not a standard installer package, it appears that Oracle had stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

Once the JavaAppletPlugin installer package is copied out of the install application, it can be deployed like previous Java updates’ installer packages.

Now that the good news is covered, let’s talk about the not-good news. Oracle’s Java 8 Update 40 application has the following behavior:

The install application will prompt for admin privileges before fully launching.

Once you provide admin authentication, the application launches.

You will be prompted to set Ask.com as your browser homepage, with the choice to do so checked off by default. If left checked, Safari’s homepage will be set with a search.ask.com URL and a Safari extension will be used to install an Ask.com toolbar.

The install application will then tell you how many devices run Java while it installs.

Once complete, it’ll tell you what it’s installed.

If you didn’t change the option of setting Ask.com as your browser homepage, it’ll then ask you to install the Ask.com toolbar as a Safari extension.

If you then choose to install the Ask.com toolbar, Safari will look like this.

It also doesn’t appear that Safari is unique in this regard, as the installer will check for the default browser. If Firefox is your default browser, Firefox’s homepage will be set with a search.ask.com URL and the user is prompted to install a Firefox extension.

If Google Chrome is set as your default browser, Chrome’s homepage will be set with a search.ask.com URL and the user is prompted to install a Chrome extension.

Circling back to the JavaAppletPlugin installer package mentioned earlier in the article, it appears that this installer does not install any toolbars or reset the homepage setting for the default browser. To avoid having to deal with Ask.com-driven annoyances, I recommend using the JavaAppletPlugin installer package whenever possible.

Part of Oracle’s new install application for Java is a binary named MacJREInstaller. This application appears to be what installs Java and governs whether or not the Ask.com toolbar gets deployed.

For context, MacJREInstaller appears to be the helper tool referenced when the Java install application prompts for admin privileges.

Based on observation, when running the Java install application, MacJREInstaller appears to run the following tasks:

1. Checks to see if it can contact the internet

2. If it can contact the internet, checks back with Oracle to see what country it’s in. Oracle apparently is selective about which nations it wants to have the Ask.com browser settings and toolbar installed (thanks to a Canadian colleague’s testing, it appears Canada is not one of the nations.)

3. If it determines the Mac in question is in a country where Oracle wants to deploy the Ask.com browser settings and toolbar, a Sponsors.framework.tar file is downloaded to the Mac and uncompressed into /Users/username/Library/Application Support.

4. Determines which web browser is set as the Mac’s default web browser.

5. Displays the choice for whether or not to install the Ask.com browser settings and toolbar.

Note: By default, the option to install the Ask.com browser settings and toolbar is selected. The person running the install application must uncheck the appropriate checkbox or checkboxes to opt out.

6. Depending on whether the Ask.com browser settings and toolbar have been chosen for installation, the following actions take place:

If installation of the Ask.com browser settings and toolbar is selected:

A. The Ask.com browser settings and toolbar for the Mac’s default web browser are installed using a tool called APNSetup, which is included in the downloaded Sponsors.framework.

B. The JavaAppletPlugin installer package stored within the Java install application is installed.

C. MacJREInstaller checks back with Oracle again to see what country the Mac in question is in.

If installation of the Ask.com browser settings and toolbar is not selected:

A. The JavaAppletPlugin installer package stored within the Java install application is installed.

B. MacJREInstaller checks back with Oracle again to see what country the Mac in question is in.

Note: Even if the installation of the Ask.com browser settings and toolbar is not selected, the Sponsors.framework remains resident on the machine, in /Users/username/Library/Application Support.

7. Once the install process finishes, MacJREInstaller then exits.

For more details, see below the jump.

As part of my research, I’ve run MacJREInstaller from the command line and captured the output from running MacJREInstaller in the following scenarios:

A. Output from MacJREInstaller when installation of the Ask.com browser settings and toolbar is selected.

B. Output from MacJREInstaller when installation of the Ask.com browser settings and toolbar is not selected.

I’ve also run MacJREInstaller from the command line when the Mac is at the loginwindow, where nobody is logged into the machine. MacJREInstaller will crash in this instance.

However, Oracle apparently anticipated that MacJREInstaller may need to be run on a logged-out Mac, as they added a –silent function flag to MacJREInstaller. To invoke this installation method, run the following command with root privileges:

/path/to/Java_install_application.app/Contents/MacOS/MacJREInstaller --silent

This installation mode does not attempt to download the Sponsors.framework.tar file and does not install the Ask.com browser settings and toolbar. Instead, it performs the following functions:

A. Checks to see if it can contact the internet

B. Sets itself to perform a silent installation

C. The JavaAppletPlugin installer package stored within the Java install application is installed.

D. MacJREInstaller checks back with Oracle to see what country the Mac in question is in.

In the event that MacJREInstaller can’t contact the internet or Oracle’s site, MacJREInstaller will install Java using the following process:

A. Checks to see if it can contact the internet. Check fails

B. Does not display the choice for whether or not to install the Ask.com browser settings and toolbar

C. The JavaAppletPlugin installer package stored within the Java install application is installed.

Based on the behavior I’ve seen, MacJREInstaller is Oracle’s tool for handling the installation of Java on the Mac although the JavaAppletPlugin installer package stored within the Java install application is what’s actually installing the Java browser plug-ins. However, MacJREInstaller is pretty much a blackbox to me and does not include documentation saying what it’s doing or how it works. Even MacJREInstaller‘s –silent function does not appear to be documented, it was instead discovered by several Mac admins in the ##osx-server IRC room while analyzing the MacJREInstaller binary.

Without documentation of what MacJREInstaller‘s functions are, combined with the behavior I have observed when running the tool, I plan to stick with pulling out the JavaAppletPlugin installer package stored within the Java install application and running that separately to install the Java browser plug-ins.

Following the release of Security Update 2015-002, it became apparent that the usually-hidden /mach_kernel file was now visible via the Finder. The mach_kernel file file is important to OS X and is stored on the root level of the hard drive on most versions of OS X (OS X 10.10.x has moved the mach_kernel file out of the root level of the Mac’s boot drive.)

To help fix this issue, Apple has made a KBase article available showing how to re-hide the /mach_kernel file using the chflags command.

As part of a post describing the problem, Tim Sutton has written a script to identify and fix the issue by using the ls command to check for the hidden attribute and then using the chflags command to re-hide the /mach_kernel file as needed. I’ve adapted Tim’s script for use in my own shop to have Casper find and fix this issue. For more details, see below the jump.

The first part of fixing the problem was detecting which machines had the problem. To address this, I wrote a Casper Extension Attribute to check for and display the following results:

If the /mach_kernel file exists and is not hidden:

Result: Visible

If the /mach_kernel file exists and is hidden:

Result: Hidden

If the /mach_kernel file does not exist (as will be the case on OS X 10.10.x):

Result: /mach_kernel not present on OS X xx.xx.xx

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

Check mach_kernel visibility: like: Visible

Here’s how the smart group looks in Casper 9.x:

The next part was writing a script to fix the problem. To address this, I adapted Tim’s script and then added it to my Casper server:

I’ve also posted the script and Extension Attribute to GitHub:

Script: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/fix_mach_kernel_file_visibility

Extension Attribute: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/check_mach_kernel_file_visibility

Once I had the EA, smart group and script created, I set up a policy that is scoped to run on members of that smart group. The policy I set up will run the script to re-hide the /mach_kernel file, then run a new inventory. The inventory update should then take the machine out of the smart group.

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

My shop recently made the change from using Juniper Network‘s Network Connect VPN client to using Juniper’s Junos Pulse VPN client. As part of the changeover, I wanted to provide an installer for our folks to use which would install both the Junos Pulse software and the configuration needed to connect to our VPN.

Fortunately, Juniper made the process of creating and importing the necessary configuration fairly straightforward. My VPN admin provided me with a copy of the needed .jnprpreconfig config file from our VPN server and I could use Pulse’s jamCommand application to import it. Once I had both the .jnprpreconfig config file and a copy of the Junos Pulse installer, I was able to create an installer using this method that handled both the installation and the automated configuration of the Junos Pulse VPN client. For more details, see below the jump.

Prerequisites:

• Packages
• A disk image with the Junos Pulse installer on it (provided by our VPN administrator)
• The appropriate .jnprpreconfig config file from our VPN server (provided by our VPN administrator)

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

2. In this case, I’m naming the project Junos Pulse VPN Client Installer.

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

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

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

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

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

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

6. Select the disk image with the Junos Pulse installer and drag it into the Additional Resources section of your Packages project.

7. Select the .jnprpreconfig config file and drag it into the Additional Resources section of your Packages project.

8. The last piece is telling the Pulse installer to run and follow the installation by importing the needed VPN configuration. For this, you’ll need a postinstall script. Here’s the one I’m using:

The logic of this script is as follows:

• Mount the disk image
• Run the installer from the mounted disk image.
• Once installation completes, check for the installed Junos Pulse application and use Pulse’s jamCommand to import the configuration from the .jnprpreconfig file.

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

sudo chmod a+x /path/to/postinstall

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

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

Testing the installer

Once the package has been built, test it by taking it to a test machine that does not have the Junos Pulse VPN client and install it. The end result should be that the Junos Pulse VPN client installs along with the corrected permissions.

Oracle has released a new update for Java 8, but this update has an interesting wrinkle. Oracle has put out a new build of Java 8, but didn’t bump the version number from Java 8 Update 40. So folks who have the previous version of Java 8 Update 40 installed may receive a message to update to Java 8 Update 40 from their current version, which will also be Java 8 Update 40.

For those thinking this sounds familiar, Oracle did the same thing with Java 8 Update 31 in February.

The difference between the two Java 8 Update 40 releases

Early March’s Java 8 Update 40 (released on March 3, 2016): Java 8 Update 40 build 25 (1.8.40.25)

Mid-March’s Java 8 Update 40 (released on March 12, 2016): Java 8 Update 40 build 26 (1.8.40.26)

If you have Java 8 Update 40 installed, you can find out which build you have by running the following command in Terminal:

defaults read /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist CFBundleVersion

If you have Java 8 Update 40 build 25, the following string will be returned:

1.8.40.25

If you have Java 8 Update 40 build 26, the following string will be returned:

1.8.40.26

Following installation of Java 8 Update 40 build 26, I tested on a 10.10.2 Mac against the following sites:

Oracle’s Java Test page: https://www.java.com/en/download/help/testvm.xml

Java Tester’s Java Version page: http://javatester.org/version.html

In both cases, the Java applets on those sites launched and worked without issue using Java 8 Update 40 build 26 (though the javatester.org applet needed to be whitelisted.)

To make things even more confusing, Oracle is providing a different installer for its update feed than it’s providing at the Java.com download site. When you update an existing Java installation on OS X via Oracle’s Java update mechanism, you will receive Oracle’s install application for Java along with the selected option to install the Ask.com browser add-ons.

If you download an installer from Java.com, you will receive a standard digitally-signed installer package which does not include the Ask.com browser add-ons.

Unfortunately, Oracle has not provided any information about why these differences in installation methods exist. To make sure you’re installing Java 8 Update 40 without the Ask.com browser add-ons, I would currently recommend downloading the installer package available via the Java.com download site.

Oracle has released a new update for Java 8, but has continued their recent trend of not bumping the version number. Oracle has put out a new build of Java 8 but didn’t bump the version number from Java 8 Update 40, which makes this the third release of Java 8 Update 40.

At this point, it appears that Oracle is now providing the install application across the board. When you update an existing Java installation on OS X via Oracle’s Java update mechanism, you will receive Oracle’s install application for Java along with the selected option to install the Ask.com browser add-ons. If you download an installer from Java.com, you will also receive this install application.

While the Oracle install application is not a standard installer package, it appears that Oracle had stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

The JavaAppletPlugin installer package is digitally-signed and does not include the Ask.com browser add-ons.

The difference between the three Java 8 Update 40 releases

Early March’s Java 8 Update 40 (released on March 4, 2015): Java 8 Update 40 build 25 (1.8.40.25)

Mid-March’s Java 8 Update 40 (released on March 13, 2015): Java 8 Update 40 build 26 (1.8.40.26)

Just-Past-Mid-March’s Java 8 Update 40 (released on March 16, 2015): Java 8 Update 40 build 27 (1.8.40.27)

If you have Java 8 Update 40 installed, you can find out which build you have by running the following command in Terminal:

defaults read /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist CFBundleVersion

If you have Java 8 Update 40 build 25, the following string will be returned:

1.8.40.25

If you have Java 8 Update 40 build 26, the following string will be returned:

1.8.40.26

If you have Java 8 Update 40 build 27, the following string will be returned:

1.8.40.27

For more details, see below the jump.

Following installation of Java 8 Update 40 build 27, I tested on a 10.10.2 Mac against the following sites:

Oracle’s Java Test page: https://www.java.com/en/download/help/testvm.xml

Java Tester’s Java Version page: http://javatester.org/version.html

In both cases, the Java applets on those sites launched and worked without issue using Java 8 Update 40 build 27 (though the javatester.org applet needed to be whitelisted.)

At this point, it appears that Oracle is now providing the install application across the board. When you update an existing Java installation on OS X via Oracle’s Java update mechanism, you will receive Oracle’s install application for Java along with the selected option to install the Ask.com browser add-ons. If you download an installer from Java.com, you will also receive this install application.

Unfortunately, Oracle has not provided any information about why they’ve cycled so rapidly through both builds and installation methods.

Something I’ve been doing for a while is running ESXi on my home server setup. Up until now I’ve been running ESXi 5.5.x on a 2011 Mac Mini, but with the release of ESXi 6.0 by VMware, I decided it was time to upgrade to new hardware. I opted to use the 2012 Mac Mini Server over the 2014 Mac Mini because the 2012 Mini Server uses quad-core processors with hyper-threading. Hyper-threading effectively doubles the number of available processors, so I would be upgrading from four available processors on my 2011 Mini to eight available processors on my 2012; in turn doubling the number of virtual machines which I could host and run inside of ESXi.

Unlike my previous installation of ESXi 5.x on a 2011 Mac Mini Server, where I needed to add ethernet drivers to the stock ESXi 5.x installer, ESXi 6.0 will install and work without additional drivers or installer modification needed. All I needed to do was download a copy of the ESXi 6.0 installer ISO file from the VMware website, use Disk Utility to burn the ISO file to a CD and use that to install ESXi 6. For more details, see below the jump.

Installing ESXi 6.0 on the Mini

Once I had the CD, I hooked up an Apple USB SuperDrive to the Mini, popped the newly-burned CD in and rebooted the Mini. When rebooting, I held down the Option key on my keyboard to allow the various boot drive options to appear, then selected the CD. The CD showed up with EFI Boot and Windows partitions, so I selected EFI Boot.

NOTE: All screenshots of this process are from ESXi running inside of VMWare Fusion, but the Mac Mini install process was identical.

Once booted from the CD, I was asked to select the ESXi 6.0 installer. Once selected, the ESXi installer boot process began.

1. When asked to begin the installation process, I hit the Enter key.

2. I hit the F11 key to accept the license agreement.

At this point, the installer took a few minutes to scan the machine.

3. Once scanning completed, I was asked to select the drive I wanted to install on. I selected the drive I wanted and hit the Enter key.

4. I selected US Default for the keyboard layout.

5. When prompted, I set a password for the root account. This is the user account that you’ll initially use to log into your ESXi server.

At this point, the installer took a few minutes to scan the machine again.

6. The installer then confirms that you want to install using the options you’ve selected. You’re also warned that the disk will be repartitioned.

NOTE: Repartitioning will wipe everything on the drive. If you have data you need to get off of this drive, hit the Escape key to back out at this point.

7. ESXi 6.0 will then install.

8. When finished, the installer will request that you remove the installation disc and then reboot. Once you’ve removed it, hit the Enter key to reboot.

Booting ESXi 6.0 on the Mini and changing network settings

On reboot, the Mini should now boot from the newly-created ESXi boot drive. Once up at the server display screen, you should see that it’s picked up a dynamic IP from your DHCP server and has the hostname of localhost. Here’s how to change that to a static IP and a new hostname.

1. Click the F2 key.

2. Log in as the root account, using the password you set during the install process.

3. You should be now at the System Customization screen. Select Configure Management Network.

4. In the Configure Management Network screen, select IPv4 Configuration.

5. In the IPv4 Configuration settings, Select Set static IP address and network configuration: and hit the space bar to make that option active.

6. Set the static IP, subnet mask and gateway address. Once finished, hit the Enter key to save the changes.

7. In the Configure Management Network screen, select DNS Configuration.

8. In the DNS Configuration settings, set the address(es) of your DNS server(s) and also set your desired hostname. In my case, I set a fully qualified DNS name.

Once finished, hit the Enter key to save the changes.

9. In the Configure Management Network screen, select Custom DNS Suffixes.

10. In the Custom DNS Suffixes settings, you may need to set a DNS suffix. In my case, my domain was already filled in. Once finished, hit the Enter key to save the changes.

11. Once you’ve made all of your changes, hit the Escape key to exit back to the System Customization screen. You’ll be asked to confirm the changes you’ve made to your network settings and warned that there will be a brief network outage for the ESXi server and any VMs running on it. Hit the Y key to apply the new settings.

12. At the System Customization screen, you should now see your static IP and hostname displayed under Configure Management Network.

13. Hit the Escape key to exit to the server display screen. It should now be displaying your hostname and your static IP address.

Logging to your ESXi server

To log into your ESXi server, I recommend having access to a Windows VM or a Windows PC and running the Windows vSphere client for initial setup. Once you’ve got it up and running, VMware Fusion Pro has a number of ESXi management options.

1. Install the vSphere client on the Windows box.

2. Launch the vSphere client and enter the following information:

IP Address / Name: IP or DNS address of your ESXi server

User name: root

Password: the password you set during the install process

3. You’ll be warned that an untrusted SSL certificate is installed. Click the Ignore button.

If everything worked right, at this point you should be in! You’ll be warned that you’re using a 60 day evaluation license. If you have a VMWare account, you can log in to the VMWare website and download a free ESXi license to use with your Mini ESXi server.

As part of moving my ESXi environment from 5.5 to 6.0, I have a 2012 Mac Pro which I’m using to host my OS X test environment for work. As this server is already configured the way I want it, I wanted to do a straight upgrade and preserve my existing settings and datastores. Fortunately, the 2012 Mac Pro is listed on VMware’s hardware compatibility list as being supported hardware.

While ESXi 6.0 is not yet listed as a supported release, I had it on reasonably good authority that I could use the stock ESXi 6.0 installer to upgrade. All I needed to do was get a copy of the ESXi 6.0 installer ISO file from the VMware website and use Disk Utility to burn the ISO file to a CD. For more details, see below the jump.

Upgrading to ESXi 6.0

The 2012 Mac Pro has a built-in optical drive, so once I had the CD available, I popped it in and rebooted the Mac Pro. When rebooting, I held down the Option key to allow the various boot drive options to appear, then selected the CD. The CD showed up with EFI Boot and Windows partitions, so I selected EFI Boot.

NOTE: All screenshots of this process are from ESXi running inside of VMWare Fusion, but the upgrade process on my Mac Pro was identical.

Once booted from the CD, I was asked to select the ESXi 6.x installer. Once selected, the ESXi installer boot process began.

1. When asked to begin the installation process, I hit the Enter key on my keyboard.

2. I hit the F11 key on my keyboard to accept the license agreement.

At this point, the installer took a few minutes to scan the machine.

3. Once scanning completed, I was asked to select the drive I wanted to install on. I selected the drive I wanted and hit the Enter key.

4. A VMFS partition was detected, so the installer did additional scanning of that partition.

5. I was notified that an existing ESXi installation and datastore was detected and I was given several options. I chose to upgrade ESXi and preserve the existing datastore, then hit the Enter key on my keyboard.

At this point, the installer took a few minutes to scan the machine again.

6. The installer then confirms that I wanted to to upgrade ESXi using the options I had selected. I hit the F11 key on my keyboard to confirm.

7. The installer then upgraded the existing ESXi installation to ESXi 6.x.

8. When the upgrade has completed, the installer requested that the installation disc be removed before rebooting. I removed it, then hit the Enter key on my keyboard to reboot.

NOTE: As you’re upgrading from an earlier version of ESXi, your current ESXi license will need to be updated to one for ESXi 6.x. The ESXi upgrade process will automatically install a a 60 day evaluation license.

8. After the reboot, my ESXi server was now running ESXi 6.0

As mentioned previously, an upgraded ESXi server will initially be using a a 60 day evaluation license. If you’re using VMware’s free license for ESXi, you can log in to the VMWare website and download a free ESXi 6.x license to use with your ESXi server.

Starting in Mac OS X 10.7.x, Apple started hiding the Library directory stored inside an account’s home folder. I’ve written a script to un-hide it on my own Macs, but I recently came across a couple of Apple-supported ways to access and unhide the ~/Library directory. For more details, see below the jump.

Accessing ~/Library via the Finder’s Go menu

The Go menu in the Finder allows you to quickly access various destinations. By default, it doesn’t show an entry for ~/Library.

However, if you hold down the Option key on your keyboard, a previously-hidden Library entry will appear.

If you click it, a new Finder window will appear showing the contents of the hidden ~/Library directory.

Un-hiding ~/Library using the View options

If you’re running OS X 10.9.x and later, there’s a built-in way to unhide ~/Library. If you select your home folder, an option will become available in the View options to unhide the Library folder in your account’s home folder.

To access this option, do the following:

1. Open a Finder window and select your account’s home folder.

2. Click on the View menu and select Show View Options.

3. A Show Library Folder option will be available.

4. If the Show Library Folder option is checked, the Library directory will become unhidden and be visible when accessing your home folder.

Following the release of OS X 10.10.3, I noticed in my testing that I was no longer able to create Active Directory mobile user accounts using the /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount tool.

The process of using the createmobileaccount tool usually works like this:

1. Open Terminal or run a script
2. Run the following command with root privileges:

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n network_account_username_goes_here

What normally happens is a new mobile account and home folder are then set up on the Mac for the network_account_username_goes_here account. On 10.10.3, I’m receiving an error indicating that the mobile account could not be created.

To try to narrow down if it was an issue specific to Active Directory account, I tested against both my shop’s Active Directory domain and OpenLDAP domain. In both cases, I received similar errors.

Active Directory on OS X 10.10.3

OpenLDAP on OS X 10.10.3

To verify that this was a 10.10.3-specific issue, I re-ran my tests in a 10.10.2 VM. On 10.10.2, my results were what I expected: A new mobile account and home folder were created on the VM.

Mobile account creation on OS X 10.10.2

Mobile account creation via the OS loginwindow

One piece of good news is that this does not appear to affect the creation of mobile accounts via the loginwindow. In my testing against my Active Directory domain, automatic mobile account creation via the loginwindow appears to work fine.

The process I used in my testing looked like this:

1. Bind test Mac running OS X 10.10.3 to my shop’s Active Directory domain, with mobile account creation enabled in the Apple Active Directory plug-in’s settings.
2. Verify that the test account was not present as a mobile account on the Mac
3. Log in with the test account’s credentials at the loginwindow

The results were what I expected: A new mobile account and home folder were created on the test Mac.

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

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

http://www.openradar.me/20482382

I’ll be speaking about OS X and virtualization at MacIT 2015, which is being held from July 14th -16th, 2015 in Santa Clara, California. For those interested, my talk will be on Wednesday, July 15th.

For a description of what I’ll be talking about, please see the Virtualization and Os X Testing – Building Your Test Environment Using Virtual Macs session page, which is linked on the MacIT Wednesday Full Agenda page.

VMware recently released a Virtual Machine Remote Console (VMRC) application for OS X users. This application is designed to complement the browser-based console for vSphere users by providing a native application for launching a remote console session with a vSphere-hosted virtual machine.

A nice bonus is that the VMRC application can also connect to an ESXi server which is using VMware’s free license for ESXi. This provides a way for users of free ESXi to access ESXi-hosted VMs via a remote console session without needing to run either the Windows vSphere client or VMware Fusion Professional. For more details, see below the jump.

To use the VMRC without the vSphere Web Client, you will need to construct the VMRC URI which looks like the following:

vmrc://@[HOST]:[PORT]/?moid=[VM-MOREF]

• HOST = the hostname or IP address of the ESXi server
• PORT = the HTTPS port of the ESXi server, which is usually 443

Finding the MoREF for the VM can be accomplished by one of two methods:

1. Running this script developed by William Lam of virtuallyGhetto
2. If you have SSH enabled on your ESXi server, connecting via SSH and running the following command:

vim-cmd vmsvc/getallvms

William Lam’s script is well-documented, so I’m going to look at using SSH to get the MoRef identifier.

Pre-requisites:

Enabling SSH on your ESXi server

Installing the VMRC application

1. Make sure you have SSH enabled on your ESXi server.
2. SSH in and run the following command:

vim-cmd vmsvc/getallvms

In my case, I’m choosing to run this as a remote command via SSH, as that will display back just the information I’m interested in. That should produce something that looks like this:

3. Use the appropriate entry under Vmid for the MoRef value which the VMRC connection string is looking for.

Once you have the Vmid entry for your VM identified, use the following address in a web browser:

vmrc://@server_name_here:port_number_here/?moid=vmid_number_here

5. Enter the ESXi server’s login and password when prompted.

6. Accept the certificate if needed.

7. The remote console session will open.

In addition to opening via a web browser, you can also open the VMRC using the following process:

1. Open Terminal

2. Run the following command:

open 'vmrc://@server_name_here:port_number_here/?moid=vmid_number_here'

You’ll be prompted for the ESXi server’s login and password, as well as the certificate if needed, then the remote console session will open.

In the wake of VMware’s release of ESXi 6.0, I upgraded my ESXi 5.5 server to ESXi 6 using the install ISO file. However, it is also possible to perform the upgrade from 5.5 to 6.0 via SSH and esxcli. For more details, see below the jump.

To upgrade from ESXi 5.5 to 6.0 using esxcli:

1. Shut down all VMs running on your ESXi host machine.

2. Connect via SSH and run the following command to enter maintenance mode:

vim-cmd /hostsvc/maintenance_mode_enter

3. After putting ESXi into maintenance mode, run the following command to set the correct firewall rules for the httpClient:

esxcli network firewall ruleset set -e true -r httpClient

4. Next, run the following command to list the ESXi 6.x updates available. You want the latest one that ends in “-standard” for your version of VMware.

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep ESXi-6

5. Once you’ve identified the correct version of VMware (as of 4-18-2015, this is ESXi-6.0.0-20150404001-standard), run the following command to download and install the update.

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-6.0.0-20150404001-standard

Note: It is very important that you run esxcli software profile update here. Running esxcli software profile install may overwrite drivers that your ESXi host needs.

6. Once the update has been installed and prompts you to reboot, run the following command to restart:

reboot

7. After your ESXi host restarts, connect via SSH and run the following command to exit maintenance mode:

vim-cmd /hostsvc/maintenance_mode_exit

At this point, your ESXi host should be upgraded to ESXi 6.x.

Apple has updated its Using the USB-C port and adapters on your MacBook (Retina, 12-inch, Early 2015) KBase article to provide more detail about USB Target Mode. One piece of information that jumped out at me was this section:

For reference, a USB-A connector looks like this.

Based on my reading of the KBase article, you will not be able to connect a 2015 MacBook in USB Target Disk Mode to a Mac with USB 2.0 or 3.0 ports and expect to be able to transfer data via Setup Assistant or Migration Assistant to the USB 2.0/3.0-equipped Mac. 

There are a couple of workarounds for this limitation:

1. Cloning the MacBook’s drive to an external drive and plugging that external drive into the USB 2.0/3.0-equipped Mac.
2. Creating a Time Machine backup of the MacBook’s drive and accessing the Time Machine backup on the USB 2.0/3.0-equipped Mac.

Both of these workarounds should allow the MacBook’s data to be accessible by Setup Assistant or Migration Assistant.

As part of working with open source software on OS X, it’s often convenient to use a package manager to install open source packages. Good package managers are useful because they handle downloading the open source software you want, make sure that any related software dependencies get handled, and make it easy to keep the software you installed up to date.

The ones that I’ve worked with in the past have been the following:

• Fink
• MacPorts
• Homebrew

All have their good points and bad points, but my colleague Tom Bridge pointed me in the direction of Joyent’s pkgsrc and this one may be my go-to going forward.

pkgsrc has the following strengths:

1. Easy to install
2. Works on multiple Unix-based platforms
3. Installs its software all within one dedicated location (/usr/pkg)
4. Does not require the creation of dedicated local user accounts
5. Installs software with root privileges

That last point was important to me because Homebrew doesn’t do that. Instead, Homebrew installs software with the ownership set to be the user who ran the installation command.

That characteristic of Homebrew has always made me crazy, but I freely admit that’s my own personal peeve. As with many things, I’m not going to tell folks what package manager to use if their choice is working well for them.

To aid with the installation of pkgsrc on OS X, I’ve written a script. For more details, see below the jump.

The script below will download an OS-appropriate gzipped tar file from Joyent and install pkgsrc using the bootstrap installer stored inside the downloaded tar file.

How the script works:

1. Uses curl to download an OS-appropriate gzipped tar file containing the latest pkgsrc bootstrap installer from http://pkgsrc.joyent.com.
2. Renames the downloaded tar file to pkgsrc.tar.gz and stores it in /tmp.
3. Installs pkgsrc into /usr/pkg using the bootstrap installer.
4. Updates pkgsrc with the latest package info.
5. After installation, removes the downloaded pkgsrc.tar.gz tar file from  /tmp.

Post-installation

Once installed, the pkgsrc binaries are located inside of /usr/pkg. /usr/pkg is not automatically added to the list of places that Terminal will search for commands, so you may wish to add the following entries to your account’s .bash_profile file or your Mac’s /etc/profile file:

PATH=/usr/pkg/sbin:/usr/pkg/bin:$PATH

MANPATH=/usr/pkg/man:$MANPATH

If you want to set these variables for only your account, please run the following commands:

echo "export PATH=/usr/pkg/sbin:/usr/pkg/bin:$PATH" >> $HOME/.bash_profile

echo "export MANPATH=/usr/pkg/man:$MANPATH" >> $HOME/.bash_profile

If you want to set these variables for all users on your Mac, please run the following commands instead with root privileges:

echo "export PATH=/usr/pkg/sbin:/usr/pkg/bin:$PATH" >> /etc/profile

echo "export MANPATH=/usr/pkg/man:$MANPATH" >> /etc/profile

After that, please close and re-open your Terminal window. That will allow the new path settings to take effect.

I’ve posted the script to my GitHub repo at the following address:

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

This script is also available as a payload-free installer package, stored as a .zip file in the payload_free_installer directory.

I’ll be speaking about OS X and virtualization at the Penn State MacAdmins Conference 2015, which is being held from July 7th – 10th 2015 in State College. For those interested, my talk will be on Thursday, July 9th.

For a description of what I’ll be talking about, please see the Virtualization and OS X Testing – building your test environment using virtual Macs session description. You can see the whole list of speakers here on the Speakers page.

At JAMF Nation User 2014, JAMF Software took the wraps off of a new product: Bushel. Bushel is a cloud-based MDM solution for managing Apple Macs, iPhones, iPads and iPod devices. It’s designed to be simple to use, so that a business can get their Apple devices managed without needing to invest in a complex solution which needs a specialized skill set.

Since Bushel’s current pricing model allows for up to three devices free, I was able to take Bushel for a test drive and document what the process of setting it up and working with it looks like. For more details, see below the jump.

Prep work

Before starting with Bushel, I set up a Google Apps for Business domain named hiddenplant.com. This is where I hosted the email addresses which I used during this walkthrough.

Once I had my HiddenPlant Google Apps for Business domain set up with Google, I set up the following accounts for use with my testing:

Name: User Name
Email: username@hiddenplant.com

Name: John Doe
Email: johndoe@hiddenplant.com

Name: Jane Doe
Email: janedoe@hiddenplant.com

Name: Push Certificate
Email: pushcertificate@hiddenplant.com

I also set up Apple IDs for each of these accounts.

What was not tested

Bushel supports Apple’s DEP and VPP programs. Regrettably, I was not set up to test these (Apple understandably won’t provide DEP for virtual machines, for example) so I will not be covering Bushel’s capabilities in those areas during the course of this post.

Setting up a Bushel instance for hiddenplant.com

1. I went to bushel.com and clicked on the Sign Up Free button.

2. This took me to signup.bushel.com, where I filled in the requested information to begin the setup process.

3. Bushel notified me that verification would be needed, then sent me a verification email.

4. After verification, I logged in at login.bushel.com

5. I was then prompted to continue the setup process by linking Bushel with an Apple account by clicking on the Let’s Go button.

This part of the the Bushel setup walked me through the process of setting up an APNS certificate for the Bushel instance.

Setting up an Apple Push Notification Certificate for hiddenplant.bushel.com

1. To start the process, I clicked on the Certificate Signing Request.plist link

Once the link was clicked, I verified that the referenced Certificate Signing Request.plist file had been downloaded to my Mac.

2. Once I had the Certificate Signing Request.plist file, I clicked on the Go to Step 2 button.

3. At this point, I needed to go to Apple’s Push Certificates portal and set up an APNS certificate for use by my Bushel instance by clicking on the Go to the Apple Push Certificates Portal link. Since it’s assumed that new users of Bushel may not be familiar with this process, there is a video available to walk you through the process.

My assumption for most folks reading this post is that they are familiar with how to get an APNS certificate from identity.apple.com, so I’m not going to walk through this process as part of this post. I used pushcertificate@hiddenplant.com as the Apple ID used to generate this certificate and downloaded the APNS certificate in PEM format.

That said, for those reading this who are not familiar with how this process works, a very similar video is available from JAMF’s resource site for creating an APNS certificate for BYOD management.

4. Once I had the APNS certificate downloaded, I clicked on the Go to Step 3 button.

5. On the next setup page, I clicked on the Upload Push Certificate button and chose the downloaded APNS certificate.

6. Once uploaded, a new icon appeared on the Bushel setup page to indicate that Bushel had the certificate.

7. I then clicked on the Start Using Bushel button to complete the setup process.

8. Bushel then initialized hiddenplant.bushel.com and I was ready to move on to the next part:

A. Enrolling devices
B. Pushing setting to the enrolled devices

Setting up device enrollment for hiddenplant.bushel.com

1. On the Bushel management page, I clicked on the Account icon in the sidebar.

2. That gave me the option to enable open enrollment for my devices by clicking on the selector button.

3. Once enabled, I chose the options I wanted:

• Setting an access code as a way to protect open enrollment.
• How long I wanted open enrollment to last
• Setting network restrictions on enrollment (in this case, I chose to have no restrictions.)

4. Once I had the settings the way I wanted them, I clicked on the Update Open Enrollment Settings button to apply them to my Bushel instance.

Now that I was set up to enroll devices, next up was device management

Setting device management for hiddenplant.bushel.com

1. On the Bushel management page, I clicked on the Settings icon in the sidebar.

2. I chose Email Accounts and enabled GMail.

Note: While the guidance in Bushel at the time of this post recommends that Google Apps for Business users set up an Exchange profile and to use m.google.com for the mail server, I found that this worked for iOS but did not work for OS X. I’ve notified the appropriate Bushel folks about this.

3. Next, I selected Device Security and chose the options I wanted:

• Requiring a lock code or password on devices.
• Setting devices to automatically lock after a set amount of time.
• Setting FileVault 2 to be automatically enabled on Macs running OS X.
• Restricting which email accounts and applications could share documents and attachments by enabling managed open-in for iOS devices managed by my Bushel instance.
• Locking down iCloud features for both iOS and OS X devices.

4. Lastly, I chose Network Settings and set up a WiFi network which my Bushel-managed devices could access.

Now that Bushel was set up to enroll devices and provide management, it was time to enroll my test iOS and OS X devices.

Enrolling on iOS

For my test iOS device, I had an available iPod Touch running iOS 8.3. Prior to enrolling it, I did the following:

A. Performed a complete wipe of the device
B. Went through the setup procedure and skipped the following options:

• Setting up anything iCloud-related
• Setting up a passcode

1. On the iPod Touch, I opened Safari and went to the following address:

https://hiddenplant.bushel.com

2. When prompted, I provided the enrollment passcode and signed in as the following person:

Name: Jane Doe
Email: janedoe@hiddenplant.com

3. The iOS device was enrolled and I was walked through the process of installing the needed profile support.

4. Once the Bushel profiles were installed, I was prompted to set a passcode.

5. Once the passcode was set, I was prompted for the password to Jane’s Google Apps email account.

6. Once the password was provided, Jane’s email was set up automatically and her email began downloading.

Enrolling on OS X

For my test OS X device, I had an VMware Fusion VM running OS X 10.10.3 iOS 8.3. Prior to enrolling it, I did the following:

A. Went through the setup procedure and skipped the following options:

• Setting up anything iCloud-related
• Setting up anything FileVault 2-related

1. On the OS X, I opened Safari and went to the following address:

https://hiddenplant.bushel.com

2. When prompted, I provided the enrollment passcode and signed in as the following person:

Name: John Doe
Email: johndoe@hiddenplant.com

3. The VM was enrolled and I was walked through the process of installing the needed profile support.

4. Once the Bushel profiles were installed, I was prompted for the password to John’s Google Apps email account.

5. Once the password was provided, John’s email was set up automatically and his email began downloading.

6. On logout, I was prompted to enter the login password for my account in the OS X VM to begin the FileVault 2 encryption process.

Monitoring Bushel-enrolled devices

Once devices are enrolled, a great amount of detail about them is available via the Bushel management page.

To bring up information about a particular device, click on its listing.

If you want to remotely lock, wipe, unenroll or change a particular device’s assignment, this can be done via its device listing page.

Conclusion 

In my testing of Bushel, I found it to be a good solution for quickly and easily standing up management for Apple iOS and OS X devices. The Bushel team went to considerable lengths to make sure that the setup process was smooth and easy to follow. If I had a number of devices that I needed to set up where the same general configuration was applied to all of them, Bushel would be a great way to make that happen in fairly short order.

Where Bushel will fall short is in situations where you need custom configurations applied. Bushel’s focus is on simplicity of management, but it comes at the cost of management flexibility. When you hit the point of needing to set up different configurations for devices, Bushel stops being the one-stop solution for you. At that point, I’d recommend looking for a device management solution that can handle the increased complexity.

This does not mean that Bushel is a bad solution. It just means that it does one job. In my testing, I found it to do that one job well.

I’ll be collaborating with my colleague Vanessa White to give a lab session at the Penn State MacAdmins Conference 2015, which is being held from July 7th – 10th 2015 in State College. For those interested, our session will be a two-parter lab on Wednesday, July 8th.

For a description of what we’ll be discussing, please see the Take Vacations using this One Weird Trick – DOCUMENTATION! session description. You can see the whole list of speakers here on the Sessions page.

As part of working with OS X VMs in VMware Fusion and ESXi, I’ve regularly installed the VMware Tools and have even found ways to incorporate their installation into my build process. However, getting the latest VMware Tools installer into my VM building workflow has usually involved at least one manual step or having a system management tool handle the installation for me. I wanted something that was completely automated without needing to also install a system management client. My end goal was that I didn’t have to worry about doing anything; the latest VMware Tools for my OS X VM would just be installed into the VM as part of the build process.

After doing some research and testing, I have a solution that looks like it does just that. For more details, see below the jump.

My colleague Joe Chilcote had adapted using AutoPkg to install Puppet Labs‘ Puppet and Facter tools into VMs, using the script available from the link below:

https://github.com/chilcote/vfuse/blob/master/packer-scripts/puppet.sh

My colleague Jesse Peterson had written a VMware Tools provider for AutoPkg, which was designed to download the latest copy of VMware Tools for OS X:

https://github.com/autopkg/jessepeterson-recipes/blob/master/VMware/VMwareToolsURLProvider.py

I had already used Jesse’s AutoPkg provider to build AutoPkg recipes to download, uncompress and extract the VMware Tools installer, so I decided to see if I could leverage Joe’s technique with my existing VMwareTools.pkg recipe for AutoPkg. I also wanted to make sure to clean all AutoPkg-related parts from the system, as I didn’t want to leave traces behind on what could otherwise be a completely unconfigured OS X VM. After some work, I have a script which does the following:

1. Downloads AutoPkg from GitHub using git.
2. Adds the AutoPkg recipe repo containing the VMwareTools .download and .pkg recipes
3. Redirects the AutoPkg cache to a temp location.
4. Downloads the current release version of VMware Tools for OS X using AutoPkg and extracts the installer package.
5. Installs the latest VMware Tools using the AutoPkg-generated installer package.

Post-installation

Once VMware Tools has been installed by the script, the OS X VM where VMware Tools has been installed must be restarted in order to enable VMware Tools’ functionality.

Notes

One thing I found in my testing is that git would be needed for this process, so an essential pre-requisite for running this script is installing git.

This can be most easily accomplished by installing Xcode or the Xcode command line tools (CLT). Both will include git, so installing either should work. One gotcha I ran into during my testing is that Xcode / Xcode CLT usually require accepting Apple’s license before you’ll be able to use git, so make sure the license has been accepted prior to running this script.

I’ve posted the script to my GitHub repo at the following address:

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

This script is also available as a payload-free installer package, stored as a .zip file in the payload_free_installer directory.

I’d previously written a post about Yosemite’s FileVault 2 pre-boot recovery options and how they can be accessed via the FileVault 2 pre-boot login screen. This process uses a Reset Password wizard to help users recover from login problems at the FileVault 2 pre-boot login screen.

I recently learned that the FileVault 2 Reset Password wizard can also be manually launched while booted from the Recovery partition. For more details, see below the jump.

Accessing the FileVault 2 Reset Password wizard

1. Boot to the Recovery HD partition
2. Open Terminal from the Utilities menu

3. In Terminal, type the following command:

filevaultrecovery

4. FileVault 2’s Reset Password wizard should appear.

For more information about the Reset Password wizard and how it works, please see the link below:

https://derflounder.wordpress.com/2015/01/17/yosemites-filevault-2-pre-boot-recovery-options/

Hat tip: Rhys Thornett in the JAMF Nation forums.