A new feature in VMware Fusion 8 Professional is the ability to create a new VM on an ESXi 6.x server. This new functionality gives Fusion users on OS X another tool for managing VMs on VMware's ESXi hypervisor and complements the ability to copy VMs between VMware Fusion and VMware ESXi 5.5.x and 6.x.
There are a few things to know about if you want to create an OS X VM to an ESXi server running 6.x, so I've put together a procedure for those who want to leverage Fusion 8.x Pro to create new OS X VMs on ESXi. See below the jump for the details.
According to Apple, the OS X Yosemite Cryptographic Modules, Apple OS X CoreCrypto Module v5.0 and Apple OS X CoreCrypto Kernel Module v5.0, require no setup or configuration to be in "FIPS Mode" for FIPS 140-2 compliance on devices running OS X Yosemite v10.10.
FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Yosemite v10.10 documentation, in the Compliant Applications and Services section.
As part of releasing the developer betas for OS X 10.11, Apple announced that El Capitan would be the end of the line for the Java 6 runtime and tools provided by Apple, with the clear statement that developers should be moving on to Oracle's Java tools.
To completely replace Apple's Java 6 tools, Oracle's Java JDK (Java SE Development Kit) will need to be installed. This is because the Oracle Java JRE (Java Runtime Environment) on OS X is a browser plug-in for running Java via a web browser and does not include capabilities for running Java desktop apps or command line tools.
By default though, the Oracle JDK does not set several options to advertise the capabilities provided by the JDK to Java apps, which may cause applications that need those capabilities to fail to launch. The capabilities are actually present in the JDK, but those options need to be set before applications will recognize them as available.
One of the issues I worked on this week was building a new Office 2016 installer after Microsoft began making Office 2016 available to its volume license customers. I have an existing process to build a combined Office 2011 installer using Packages, which I've used successfully for a while, so I decided to see if I could apply the same process to building an Office 2016 installer.
However, when I installed the combined Office 2016 installer with DeployStudio, then logged in, I was asked to sign into an account and activate Office. Since my work has a volume license, this isn't a screen I should be seeing.
Office 2016 is installed and then updated to 15.12.3 without any Office applications being launched between the initial installation and the update.
These two scenarios will likely apply if you're building a new machine using an automated deployment tool, but likely will not if you're a home user.
The easiest fix I've found in my testing is to get the necessary volume license file from a machine that has Office 2016 installed on it and put it back on an as-needed basis.
The needed file is /Library/Preferences/com.microsoft.office.licensingV2.plist. If you have a volume-licensed version of Office 2016 installed on your Mac, you should have this file.
To address this issue, you can use Packages' ability to add resources to a Packages-built package. See below the jump for an example using an Office 2016 volume licensed installer package, the Office 2016 15.12.3 updates for Excel, OneNote, Outlook, PowerPoint, and Word, as well the com.microsoft.office.licensingV2.plist license file to build a unified Office 2016 15.12.3 installer package that does not prompt for a product key.
Every so often, source code for an application gets lost, mislaid or not given to a customer. In that case, the application's user may need to do a lot of work to decompile the application and see if the source code can be recovered from the application itself.
I recently had a colleague ask about a similar situation with an Automator application, where they had the Automator application itself but didn't have access to the Automator workflow that created it.
After some testing, here's how we were able to access the workflow using only the compiled application.
1. Save a copy of the Automator application to a convenient location.
2. Right-click on the application and select Show Package Contents.
3. Save a copy of Contents/document.wflow to a convenient location.
4. Rename document.wflow to preferred_file_name_here.workflow.
5. When prompted, confirm that you want to change the extension from .wkflow to .workflow.
At this point, you should be able to open the newly-renamed .workflow document in Automator and examine the workflow.
Update 8-1-2015: Steve Hayman pointed out that there's an even easier way. For details, see below the jump.