I recently learned that there are hidden text editing options for the Casper JSS’s script editor. To access these options, do the following:
1. Log into your JSS
2. Go to Computer Management: Scripts
3. Bring up the script editor in your browser
4. Click inside the text entry area of the script editor
5. Press Command + comma (⌘ + ,)
6. The JAMF script editor’s text editing options will appear.
There are some issues to be aware of:
- Changes made are global and will affect all currently logged-in users
- The settings changes are not persistent across sessions. If you log out or are logged out, you will need to re-setup your settings.
Ideally, changes made to the text editing preferences would be:
A. Per-user instead of affecting all users
B. Persistent, so that changes to these settings would not be lost on logout.
There’s an existing feature request on JAMF Nation which requests these changes. If you agree that this would be beneficial, please vote it up.
I had previously written about deploying Sophos Enterprise Anti-Virus for Mac 9.2.x, but I was recently notified that the method I had been using would stop working in a future release of Sophos.
Sophos has a KBase article about pre-configuring their installer application with the AutoUpdate settings, but I also wanted to be able to deploy Sophos using an installer package. Using the information from the KBase article, I was able to update my existing method for building an installer package for deploying Sophos Enterprise Anti-Virus for Mac 9.2.x. For the details, see below the jump.
When Yosemite was released in October 2014, one of the changes it introduced was including a new FileVault 2 enablement option in Apple’s Setup Assistant. This option encouraged new users of Yosemite to enable FileVault 2 encryption and had the choice to enable FileVault 2 selected by default.
When the encryption process began, a significant issue then appeared for a number of users where the Mac would report Encryption paused during the encryption process, then never resume the encryption process.
This produced a situation where the Mac could not complete encryption, but would not decrypt either because the encryption process had not completed. The only fix appeared to be deleting the existing CoreStorage volume, which addressed the issue at the cost of deleting everything stored on the boot drive.
Fortunately, OS X 10.10.3 includes a fix that should stop this issue from occurring on OS X 10.10.3 and later. There is also now a procedure that should fix Macs still affected by this problem. For more details, see below the jump.
I use screensharing quite a bit, both at home and at work, to connect to machines. As part of this, my process for connection has looked something like this:
1. Verify I’m on the right network.
2. On the Mac I’m connecting from, under the Go menu, select Connect to Server…
3. In the Server Address: line, enter the address of the Mac which I want to remotely connect to:
4. Logging in by entering my authentication credentials into the screensharing login window’s username and password blanks.
5. Assuming username and password are accepted, the remote Mac’s screen is displayed.
As with any task I perform frequently, I wanted to shave some time off of this process but I didn’t want to save the screensharing authentication info to my keychain (personal preference).
Fortunately, there’s an easy way to pre-define the username for the screensharing login window by adding username@ to the vnc:// address:
The username should now be filled in when the screensharing login window appears.
Since you can also make bookmarks in the Connect to Server window, my next step was saving a bookmark for the updated screensharing address.
It’s simple enough to do, but not having to manually enter the username will save me at least a few seconds every time I connect to a remote machine’s screen.
IT disasters are unpleasant, and can take many forms. However overwhelming the idea of a possible disaster may be, it is crucial to have a well-formed plan in place. Many IT professionals don’t have a good grasp on how to write disaster recovery documentation, which can lead to confusion and problems when disaster strikes.
To give an idea of how good disaster recovery documentation can save the day, I’d like to share a story of how good documentation not only saved the day, but also saved my vacation.
A few years ago, I was riding the airport shuttle on my way to a cruise ship vacation. While en-route, I got a call from my workplace where the person calling said that they had a power outage at our main datacenter. I was gone, my alternate was stuck in traffic, what should they do? I said “Can you find the Mac server rack?” Yes, they found it. “Do you see the packet marked Emergency Server Startup and Shutdown Procedures?” Yes, they did. “OK, open that and start reading. It’ll walk you through the process.” I talked with them for a few more minutes to make sure that they were OK, then I said goodbye, ended the call and prepared to board my plane.
Without that packet attached to the front of the server rack, which I had made sure was updated the day before with the latest information, I might have been trying to talk someone through the shutdown procedure for about fifteen servers and twelve RAID arrays over the phone up until the moment that the flight attendant yanked my phone out of my hand because the plane needed to take off.
There are a few lessons to take from this story.
Q: Where was I when the disaster occurred?
A: Off-site and without access to either a computer or a way to connect back to the work network.
Q: Where was the other person who had been trained on our disaster recovery process?
A: Off-site and unavailable.
Q: Who was the person on the phone?
A: Someone who wasn’t trained in our disaster recovery process.
Q: What allowed the person on the phone to successfully bring down my servers?
A: Accurate and easily-understood documentation that was placed for ready access.
Q: What was not affected by this disaster?
A: My vacation.
With these lessons in mind, see below the jump for my advice on how to write disaster recovery documentation.
When a FileVault 2-encrypted Mac sits for more than a minute with an account selected at the FileVault 2 pre-boot login screen, a message like the one below should appear:
If you’re having a problem entering your password, press and hold the power button on your Mac to shut it down. Then press it again to start it up in the Recovery OS.
If the instructions are followed, the Mac will boot from the Mac’s recovery partition on the next startup and go into a FileVault 2 Reset Password wizard.
In the Reset Password wizard, there are currently three options available.
- I forgot my password
- My password doesn’t work when logging in
- My keyboard isn’t working when typing my password to login
However, if you don’t want or need to use the Reset Password wizard, there’s not an obvious way to get back to the FileVault 2 pre-boot login screen. There’s no visible way to quit, and rebooting the Mac using the power button will return you to the Reset Password wizard.
Thanks to research by the folks in the ##osx-server IRC room, it looks like there’s a relatively straightforward way to reset the boot process:
- While booted to the initial Reset Password wizard screen, press and hold the power button on your Mac to shut it down
- Reset NVRAM
- Once the NVRAM reset procedure has been completed, let the Mac boot.
At that point, you should be taken to the FileVault 2 pre-boot login screen instead of the Reset Password wizard.
Credit to arrose in the ##osx-server IRC room for figuring this out.
Update 5-28-2015: As elvisizer mentioned in the comments, there is also the option of revealing the hidden menu at the top of the screen and using the Startup Disk preferences to select your hard drive and reboot back to FileVault 2 pre-boot login screen. Since this is easier to show rather than explain, I’ve made a short video of the process.
Note: The password used to unlock the drive in the Startup Disk preferences can be the password of any account that appears on the Mac’s FileVault 2 pre-boot login screen. If you can log in at the pre-boot login screen, you should be able to enter your password to unlock.
I do a lot of work with payload-free packages and while I have a process for creating them as I needed them with pkgbuild, this approach requires some setup work. To help make the package creation process more convenient, I developed Payload-Free Package Creator.app, an Automator application that will allow to select an existing script and create a payload-free package that runs the selected script.
However, this tool has used pkgbuild‘s –nopayload function, which creates a package which doesn’t leave an installer receipt behind. This is intended behavior according to Apple, but not leaving a receipt behind can make it hard to determine whether an installer package has been run on a particular machine. This is especially problematic for Munki, which uses receipts along with other methods to track installation status.
While I don’t use Munki, I’ve heard from a number of folks who do and who had run into the no-receipt problem when they tried to use payload-free packages generated by Payload-Free Package Creator.app with Munki.
So the problem was this:
- I wanted to create payload-free packages which only run scripts and do not install files.
- I wanted to have an installer receipt.
- Apple’s built-in method for generating payload-free packages with pkgbuild didn’t provide receipts.
- I thought I needed to provide a payload to pkgbuild in order to generate a package which would provide receipts.
- Providing a payload meant I was installing files, which is what I didn’t want to do.
The matter had rested there for a while and I didn’t see a good way to fix it.
Fortunately, I was wrong about point 4. Greg Neagle recently documented that you can make a package with pkgbuild that, while not technically payload-free, will act just like one. The key is to create an empty directory and set pkgbuild‘s –root option to look there for files. pkgbuild‘s –root option is used to tell pkgbuild which files to package, but since there will be no files in an empty directory, the package will install no files on the destination Mac.
That’s where I had gone wrong on point 4 – I thought I had to give pkgbuild something to install in order to build a package with a receipt, but it turns out that pkgbuild will successfully build a package while using an empty payload directory. This information allowed me to reconcile points 1 and 2, which resolved the problem.
With this new information, I was able to update Payload-Free Package Creator.app and I’m happy to announce it has two new features:
- Version numbering
- Packages generated by Payload-Free Package Creator.app will leave receipts behind after installation.
For more details, see below the jump.