To follow up on Apple’s changing the output of csrutil status when System Integrity Protection (SIP) is disabled, I’ve posted the following Casper extension attribute to my GitHub repo to report on whether SIP is enabled or disabled.
The script has the following functions:
If the Mac is running 10.10.x or earlier
The script reports System Integrity Protection Not Available For and then reports the relevant version of OS X. For example, the script returns the following output on a Mac running OS X 10.10.5:
System Integrity Protection Not Available For 10.10.5
If the Mac is running 10.11.x or later
This script uses csrutil status to check SIP’s status. If System Integrity Protection is disabled, the script returns the following output:
If System Integrity Protection is enabled, the script returns the following output:
For those interested, the script is available on my GitHub repo:
In order to check whether System Integrity Protection (SIP) is enabled or disabled on a Mac running OS X El Capitan, you can use the csrutil command to report on SIP’s current status. For example, to learn if SIP is enabled or disabled, run the following command:
This command can be run without root privileges and will tell you if SIP is on or off.
If SIP is enabled on 10.11.0 or higher, you should receive the following message:
System Integrity Protection: enabled
If SIP is disabled on OS X 10.11.0 or 10.11.1, you may receive a confusing message which indicates that SIP is enabled, followed by a list of individual SIP functions which are disabled. If all functions listed are showing as being disabled, SIP is actually completely disabled; it’s just confusingly worded.
It appears that Apple has updated the status message on OS X 10.11.2 to make it much more clear when SIP is disabled. On 10.11.2, if SIP is disabled, you now should receive the following message:
System Integrity Protection: disabled
Starting with VMware Fusion 7.x Professional, it’s been possible to transfer virtual machines from VMware Fusion to VMware ESXi. This ability has been improved with VMware Fusion 8.x Professional, but there is a recurring issue with OS X VMs transferred from VMware Fusion to VMware ESXi 6.x. The symptoms normally look like this:
1. An OS X VM running OS X 10.10.x or 10.11.x is created in VMware Fusion 8.x Professional
2. The hardware version of the OS X VM is changed to Hardware Version 11, to allow compatibility with ESXi 6.x
3. The VM is transferred successfully to VMware Fusion 8.x Professional to the ESXi 6.x server
4. Following the transfer, the OS X VM is started but does not successfully complete the OS startup process.
The root cause is that there is some OS information which is not transferred successfully along with the VM, but it’s relatively straightforward to fix. For more details, see below the jump.