While working with a colleague to prepare a FileVault 2 rollout at his institution, he reported that in his testing, the decryption process did not appear to be working correctly when he was booted from the Recovery HD partition and using the command line diskutil-based decryption procedure that I had posted. In his testing, he was finding that the CoreStorage volume that the FileVault 2 encryption process created was not being removed when the diskutil corestorage revert command was run. The drive was being decrypted, but the CoreStorage volume was being left behind. This caused problems in his testing, because he found that rebooting afterwards led to the Mac booting to a prohibited sign.
This symbol at boot means the system has found a bootable installation of Mac OS X on the system, but there is something wrong with it.
After some additional testing, he discovered that he actually needed to run diskutil corestorage revert twice in succession. Running diskutil corestorage revert the first time would decrypt the drive. Running diskutil corestorage revert a second time following the first command would then remove the unencrypted CoreStorage volume. Once the CoreStorage volume was removed, the Mac would then be able to reboot normally to the regular boot drive.
The behavior seems to be tied to the following:
1. Booting from a Mavericks Recovery HD partition (all testing was done with a 10.9.4 Recovery HD partition.)
2. Decrypting either of the following methods:
A. Using Recovery HD‘s Disk Utility to decrypt the FileVault 2-encrypted boot drive. This decryption method is described here.
B. Running diskutil corestorage -revert from the Terminal. This decryption method is described here.
3. Letting the drive get to Conversion Progress: 100% while booted from the Recovery HD partition. Conversion Progress status can be displayed by running the diskutil corestorage list command in Terminal.
4. Rebooting back to the main boot drive once Conversion Progress: has reached 100%.
The end result is a locked CoreStorage volume that will not unlock or mount on boot, or when accessed from a Recovery HD partition or Apple’s Internet Recovery. This was the root cause for the prohibited symbol at boot that my colleague was receiving.
In my testing, I did find it was possible to decrypt the drive via Disk Utility or the command line when it was attached as an external drive (via Target Disk Mode or other means) to a Mac that was booted to a full version of OS X 10.9.x. Once decrypted, I verified that the CoreStorage volume was removed. Once I had verified that, I further verified that I could now boot normally from the previously non-bootable hard drive.
One drawback to decrypting while attached to a regular 10.9.x boot drive is that you are not able to use an Institutional Recovery Key (IRK). Using that kind of recovery key for unlocking or decryption only works when booted from a Recovery HD partition or Internet Recovery. Since that’s precisely where our problem exists, I investigated further to see if there were alternate workarounds for this problem. For more details and the workarounds I found, see below the jump.
I recently had a situation where I was asked to figure out a way to get a work-owned iCloud-locked phone’s activation lock removed. After doing some research, I was able to find a way to do this and was able to go from having an activation-locked iPhone to having a ready-for-activation iPhone.
If you have a work-owned iPhone that has been activation-locked with an Apple ID, it is possible to contact AppleCare and get the activation lock removed. The key is to be able to provide to Apple a clear chain of ownership of the iPhone by your company, school or institution, usually through providing an electronic copy of the invoice or other proof of purchase. If you can’t prove that your company, school or institution owns the specific iPhone in question, Apple will not unlock it.
Assuming that your work has purchased the activation-locked iPhone directly from Apple, or via a business account with one of the mobile carriers, you should be able to contact the vendor to get proof of purchase.
Here’s the procedure I used to get from an activation-locked iPhone to a ready-for-activation iPhone:
Note: Getting the lock lifted may take a few business days from the time that the request is submitted.
1. Get the IMEI of the iPhone. If possible, also get the serial number and phone number. See the link below for Apple’s KBase article on how to find this information:
2. If needed, have one of your workplace’s authorized contacts work with the vendor who sold the iPhone to your company, school or institution and get an electronic copy of the proof of purchase.
The reason to get the proof of purchase is that it will be needed to establish that your company, school or institution purchased and has ownership of the iPhone.
3. Once you have the proof of purchase available to you, verify that it has the following information:
iPhone serial number (may be the same as the IMEI)
iPhone phone number
4. With the proof of purchase readily available for reference, call the relevant AppleCare line for your company, school or institution. See the link below for AppleCare’s contact numbers.
5. If asked about the device you need support for, say “iPhone“.
6. When connected to the support rep, explain that you have an iCloud-locked phone and that you would like to submit a request to have it unlocked.
7. Tell them that you have the IMEI for the iPhone in question and provide it when asked.
8. Apple may ask you for the invoice number, serial number and/or phone number of the iPhone to help them look it up on their end and verify ownership.
9. Once the Apple rep has provisionally established that your company, school or institution has ownership of the iPhone, they will send you an email with instructions on how to contact the group that handles unlocks of iCloud-locked phones.
10. Follow the instructions in the email and make sure to provide an electronic copy of the proof of purchase.
If all goes well, Apple should unlock the activation-locked work-owned iPhone within a few business days and notify the person who submitted the request to have the lock removed.
In working through various issues with JAMF, I’ve noticed that a variety of issues I’ve reported are themselves tied to JAMF’s internal bug-reporting system of defect numbers. At the moment, the only way I get any visibility into progress on those defect numbers is by asking my account manager. My current account manager is pretty responsive, but this seems like a job that can be offloaded from his list of responsibilities. I also don’t always want to open a support call when I notice a bug, sometimes I just want to report it.
Here’s what I would want from JAMF in a bug reporting solution:
- I want a way to report bugs that I’ve noticed.
- I want a way to be able to check for myself the status of the reported bug.
- I also want to know how many other people are reporting this issue. Not just because I’d like to know if I’m filing a duplicate issue, but stats like that may give me some insight into how soon my bug will get fixed.
For a bug report itself, I want:
- The ability to upload screenshots and screen capture movies and be able to attach them to the bug report.
- The ability to add additional information to the initial bug report.
- Email notifications when my bug’s status has changed.
- A way for the developer working on the bug to be able to reach out and get more details from me directly.
- The ability to see both open and closed bug reports that I’ve submitted.
- If I’ve filed a duplicate issue, read-only access to the original filed bug report.
I file bug reports with Apple, so I know the drill. I know not all bugs get fixed as fast as I want them to. Sometimes, they don’t get fixed at all. What I want is more information, and to be able to access that information myself.
As it happens, there’s an existing Feature Request for this already open at JAMF Nation. Please vote it up. Hopefully one day soon, I’ll see that status change from UNDER REVIEW to IMPLEMENTED.
I found myself wanting to pull together a mix of the best of the Penn State MacAdmins playlists, so I looked up both 2013 and 2014 playlists. For those who also want both Spotify playlists, please see the links below:
Penn State MacAdmins 2013 Spotify: http://spoti.fi/macadmins13
Penn State MacAdmins 2014 Spotify: http://tinyurl.com/psumacmusic
I had an interesting issue crop up yesterday. One of our users sent in a ticket to report that Word 2011 on her laptop kept crashing with an EXC_BAD_ACCESS error. None of her other Office 2011 applications were exhibiting the behavior; it was specific to Word 2011.
When this error has cropped up in the past, I’ve fixed it in the past by removing Word’s Normal.dotm template from /Users/username/Library/Application Support/Microsoft/Office/User Templates or removing the com.microsoft preference files for the affected application from /Users/username/Library/Preferences.
So this time, I moved the following files to a new folder that I created on the user’s desktop:
/Users/username/Library/Application Support/Microsoft/Office/User Templates/Normal.dotm /Users/username/Library/Preferences/com.microsoft.Word.plist
Then I logged the user out, asked them to log back in and had them relaunch Word. Crash. EXC_BAD_ACCESS error again. This was going to be an unusual one…
The good folks at Penn State have posted the session videos from the Penn State MacAdmins Conference 2013. The sessions slides and videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:
As all the session videos have been posted to YouTube, I’ve linked my FileVault 2 session here:
The Extending OS X Management Systems with Scripting session I co-hosted with Jeremy Reichman is linked here:
As part of Firefox 31’s release, Mozilla made a change to enable support for NT LAN Manager version 1 (NTLMv1) network authentication when connecting to sites that are using HTTPS to allow encrypted communication via SSL between Firefox 31 and the website in question. This is to address the change made in Firefox 30, which disabled support for NT LAN Manager version 1 (NTLMv1) network authentication for sites using either HTTP and HTTPS.
NTLMv1 authentication to sites using HTTP is still disabled by default. For more information on why HTTPS is now enabled while HTTP remains disabled, this Mozilla bug report discusses the issue.
A way to tell if the NTLMv1-using site you’re trying to access is using HTTP or HTTPS is to check the connection address. If it begins with https://, you should be OK. If it begins with http:// , Firefox 31 will still block NTLMv1 authentication.
If you need to enable NTLMv1 authentication for an HTTP site that uses NTLMv1 authentication, Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication on HTTP sites, which will allow access again to SharePoint-based or IIS-backed web applications. For those folks who need it, I have the workaround documented here.