Archive
Casper’s hidden documentation
I’m interested in discovering when tools have hidden documentation, so I was curious when I learned recently that the Casper agent has explicitly hidden documentation which requires root privileges to access. For more information, see below the jump.
Hidden text editing options available in Casper’s script editor
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.
Revisiting Sophos Enterprise Anti-Virus for Mac 9.2.x deployment
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.
WWDC 2015 notes
I’ve been out in San Francisco this week as an attendee of Apple’s WWDC 2015 conference. As part of this, I’ve been taking notes during the labs and sessions. I want to stay on the right side of Apple’s NDA, so I’ve been posting my notes to Apple’s developer forums rather than to here.
To make it easier for Mac admins to access them, I’ve set up a page in the forums where I’ve linking the various forum posts containing my notes. It’s available via the link below:
Yosemite’s paused encryption problem fixed in 10.10.3
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.
Opening screensharing connections on OS X using pre-set usernames
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:
vnc://computer_name_here.domain.com
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:
vnc://username@computer_name_here.domain.com
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.
Preparing for a Bad Day – How to write Disaster Recovery documentation
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.
Der Flounder 
Recent Comments