One of the issues I worked on this week was building a new Office 2011 installer after Microsoft released the Office 2011 14.5.0 update. I have an existing process to build a combined Office 2011 installer using Packages, which I’ve used successfully for a while.

This time though, I hit a problem. When I installed the combined Office 2011 installer with DeployStudio, then logged in, I was asked to enter a product key. Since my work has a volume license, this isn’t a screen I should ever see.

This is a problem that I’ve seen before with previous Microsoft Office 2011 installers and usually involves the license file not being applied when it should be. This behavior is seen on Macs in the following cases:

1. Office 2011 is installed and then updated to 14.5.0 while nobody is logged in
2. Office 2011 is installed and then updated to 14.5.0 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 14.4.x installed on it and put it back on an as-needed basis.

The needed file is /Library/Preferences/com.microsoft.office.licensing.plist. If you have a volume-licensed version of Office 2011 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 an example using an Office 2011 SP 4 installer package, the Office 2011 14.5.0 Update, and the com.microsoft.office.licensing.plist license file to build a unified Office 2011 14.5.0 installer package that does not prompt for a product key.

1. Remove the Office 2011 installers’ application quit function.

2. Set up a new Packages project and select Raw Package.

3. In this case, I’m naming the project Microsoft Office 2011 14.5.0

4. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

5. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

• In the Post-Installation Behavior section, set On Success: to Do Nothing
• In the Options section, check the box for Require admin password for installation

6. Click on the Scripts tab in your Packages project.

7. Select your installers and drag them into the Additional Resources section of your Packages project.

In the case of my example, I’m selecting the following installers:

• Office 2011 14.4.2 with Service Pack 4 Installer.pkg
• Office 2011 14.5.0 Update.pkg

8. Select the com.microsoft.office.licensing.plist file and drag it into the Additional Resources section of your Packages project.

9. The last piece is telling the installers to run and for the com.microsoft.office.licensing.plist file to be fixed as needed. For this, you’ll need a postinstall script. Here’s the one I’m using:

Notice that $install_dir in the postinstall script refers to the path to the package’s working directory. That’s where Packages will be storing the installers along with the com.microsoft.office.licensing.plist file, inside the Package-built installer’s embedded directory where it stores the items defined in the Additional Resources section.

The -target value is defined as “$3″ because some information is passed along by the Packages-built installer to its included scripts when those scripts are run by the installation process. (For more information, see the PackageMaker How-To available here and search on the page for $3)

In this case, -target being defined as “$3″ means that the postinstall script will install the two Office 2011 packages onto the desired drive. The $3 variable will also allow the installer to correctly determine if the com.microsoft.office.licensing.plist license file is in the right place on the target drive and take appropriate action if it isn’t.

The script also governs what order the installers run in, so the main Office 2011 installer runs first and the update runs next after the first job finishes. The -dumplog and -verbose flags are to help you track the progress of installation if you’re looking at the installer log.

10. Once you’ve got the postinstall script built, run the following command to make the script executable:

sudo chmod a+x /path/to/postinstall

11. Once completed, add the postinstall script to your Packages project.

12. Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing

Once you have the package built, you should be able to test it by installing it on a machine while the machine is logged out. Once installed, Office 2011 14.5.0 should be properly licensed and not prompt you for a product key.

When the Office 2011 14.5.0 update was released, it was initially noteworthy for the fact that in certain circumstances it removed Office’s license. Shortly thereafter, Outlook 14.5.0 became noteworthy for the fact that Outlook’s main window (which displays the mailboxes, list of emails, calendars and other functions) was now invisible.

Another thing that was curious was that this problem did not affect everyone. It seemed to affect only those who met both of the following conditions:

• Macs running 10.10.x
• Accounts that had mailbox subfolders and had those mailbox subfolders expanded at the time of quitting Outlook.

For better or for worse, I have a large number of mailbox subfolders so I could pretty much reproduce this issue (which I quickly dubbed Inbox Invisible) on demand.

A number of suggested fixes included the following:

• Removing the Outlook preferences from ~/Library/Preferences
• Rebuilding the Outlook identity
• Deleting cache files
• Some combination of all of the above

In my testing, those fixes would work for one time. I’d launch Outlook, the main window would be there, I’d quit Outlook and re-launch it and be confronted again with Inbox Invisible.

What ultimately fixed it for both myself and those in my shop affected by this issue was the following:

1. Quitting all Office applications
2. Uninstalling Office 2011
3. Restarting the Mac
4. Reinstall Office 14.4.9 following the restart.

Outlook started working again once rolled back to 14.4.9. The weird thing was that uninstalling Office and reinstalling it fixed the issue, without needing to change anything else. This is one of the very few times I can recall when uninstalling Office 2011 and reinstalling it actually addressed a serious problem. Normally, problems with Outlook are caused by something amiss on the user account or email account level. However, it looks like there may be an explanation. For more details, see below the jump.

In a posting on JAMF Nation, Devin Kass was able to link this issue as being similar to one that occurred during the Yosemite development process.

As part of a conversation on Twitter, Erik Schwiebert posted something to support this hypothesis by claiming that Apple had introduced a change to fix this issue, but it only applied to versions of Outlook that were earlier than 14.5.0.

Further in the conversation, Schwiebert mentioned that if you change the version info for Outlook 14.5.0 back to reporting that it was Outlook 14.4.9, the problem should go away.

I decided to test this out and sure enough, the main window came back and was fine.

I would not recommend this fix for production use, but it is supporting evidence that the OS is making a version check somewhere as part of allowing the main window to appear and 14.5.0 isn’t passing that version check. Hopefully, the problem will be addressed soon and an update to fix this issue appears quickly.

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:

1. I wanted to create payload-free packages which only run scripts and do not install files.
2. I wanted to have an installer receipt.
3. Apple’s built-in method for generating payload-free packages with pkgbuild didn’t provide receipts.
4. I thought I needed to provide a payload to pkgbuild in order to generate a package which would provide receipts.
5. 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.

Using Payload-Free Package Creator.app

1. If needed, download the Payload-Free_Package_Creator_Application.zip file from the application directory in my GitHub repo.

2. Once downloaded and unzipped, double-click on the Payload-Free Package Creator application.

3. You’ll be prompted to select the script that you want to use as part of creating the installer package.

4. Once you’ve selected the script, you’ll be prompted to name the installer package. By default, the name filled in will be Payload Free Installer Package.

This name can be changed as desired.

5. Once you’ve entered a name for the installer package, you’ll be prompted for a package identifier. By default, the name filled in will be com.github.payload_free.

This name should be changed to be something unique.

6. Once you’ve entered an identifier for the installer package, you’ll be prompted for a version number. By default, the value filled in will be 1.0.

This value should be changed to be something unique.

7. Once the package name, package identifier and package version number have been set, Payload-Free Package Creator.app will prompt for an administrator’s username and password.

8. Once the admin username and password are provided, Payload-Free Package Creator.app will create the installer package and prompt you when it’s finished.

9. Click OK at the prompt and a new Finder window will open and display the newly-created installer package.

10. Payload-Free Package Creator.app will automatically exit.

How Payload-Free Package Creator.app works

Payload-Free Package Creator.app is an Automator application that uses AppleScript, shell scripting and pkgbuild behind the scenes to create installer packages which only run scripts but which will leave behind receipts. When a script is selected, the following process takes place:

1. The script is copied to /tmp and renamed to postinstall, to match the name that pkgbuild is expecting for a post-installation script.
2. After the package name, package identifier and package version number are chosen, /tmp is checked to make sure that there is not an existing directory that is named the same as the chosen name. If a matching directory is found, it is removed.
3. A new directory is created in /tmp that matches the chosen name of the package.
4. Next, a scripts directory and an empty directory named nopayload are created inside of /tmp/package_name_here. The nopayload directory provides the empty directory for pkgbuild‘s –root option.
5. The postinstall script is copied to /tmp/package_name_here/scripts
6. The package is built by pkgbuild using the postinstall script stored in /tmp/package_name_here/scripts
7. The finished package is stored in /tmp/package_name_here and the user is prompted that the process is finished.
8. Once the user is notified and clicks OK, a new Finder window opens for /tmp/package_name_here.

The AppleScript used to create the payload-free package as part of the Automator work is below:

All Payload-Free Package Creator components and scripts are available at my GitHub repo:

https://github.com/rtrouton/Payload-Free-Package-Creator

The Automator workflow files and the AppleScript are also available via the link above if you want to build a customized Payload-Free Package Creator for your own environment.

An installer for the latest release of Payload-Free Package Creator.app is available via the link below:

https://github.com/rtrouton/Payload-Free-Package-Creator/releases/latest

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.

1. I forgot my password
2. My password doesn’t work when logging in
3. 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:

1. While booted to the initial Reset Password wizard screen, press and hold the power button on your Mac to shut it down
2. Reset NVRAM
3. 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.

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.

Audience

Who is the audience for your disaster recovery documentation? You should be writing it for you or other IT professionals, right?

No. In fact, the person reading your documentation may be the nice lady from Facilities who handles the HVAC for the server room, that sharply-dressed gentleman from HR who stopped by the IT office on an errand, or the boss’s niece who stopped by the office to sell some cookies. They will also be under pressure and doing an unfamiliar task.

You never know who will be standing in front of your server rack when the hammer comes down so your disaster recovery documentation should be both comprehensive, and written so that anybody can understand what needs to be done. The janitorial, accounting or HR staff should be able to follow it and use it to start up or shut down your servers.

Media

You can’t count on the person who needs the documentation being able to access it in electronic format, so having it available in printed form is a good idea. Remember, you have no idea ahead of time what form the disaster could take. Whoever is reading your documentation may be working in a dark room and reading with a flashlight.

Availability

Don’t hide this documentation. If you can, post a printed copy to the front of the server rack with a cover page or sign clearly indicating what it is and why it’s there. If that’s not an option, store it somewhere else where the documentation is both easily visible and clearly marked.

Now that we’ve covered who may be reading it and how the actual documentation should be handled, let’s talk about what should be in it.

Order Of Operations

Something that’s crucial to document is your order of operations. Pressing the power button will start up your server from being powered off, but what all needs to happen before you can hit the button?

For those not familiar with what the diagram above is, it’s a depiction of the psychological theory known as Maslow’s hierarchy of needs. It’s often portrayed in the shape of a pyramid with the largest, most fundamental levels of needs at the bottom and the need to be fully alive, or self-actualized, up at the top. You have to meet your most fundamental needs first before you can be fully alive.

Maslow’s hierarchy can also be applied to the order of operations in your disaster recovery documentation. What fundamental needs must be met before you hit the power button on your server? You need to have power. You need to have the room’s cooling system online and working properly. You need to have networking available. You need to have DNS available. A storage appliance your server uses to access crucial data needs to be powered on and functioning properly. And so on. Make sure to include this information in your documentation and specify that all of it needs to be available before your servers should be brought back up.

Physical Needs

Another thing to document is how to recover from hardware disasters in addition to software ones. Document where your replacement parts are and how to replace them. As part of this, make sure the parts are labeled and readily accessible. 

For those servers that may not have a physical keyboard and mouse permanently hooked up, make sure you have a crash cart available with monitor, keyboard, and relevant adapters, then include how to use the cart as part of the documentation.

Show Which Buttons To Hit

Don’t assume that the person in front of the server is going to know which are the correct buttons to hit and in which order. Include this information in your disaster recovery documentation along with graphics indicating which buttons do what and how they should be handled.

Verifying Normal Operation

Wherever possible, provide simple easily-checked ways in your documentation to verify that your devices are working properly. One way to do this is take a picture of the front of individual servers when they’re operating normally and use that to create a diagram with information like “All these lights in the indicated area should be lit up and showing green lights. The third light from the left should be blinking, but all others should not blink.”

Data Restoration

One common event in disasters is loss of data. Oftentimes, the loss is due to file system corruption, hardware failures, and deleted or corrupt files. The good news is that regular backups of your data can turn these problems from catastrophes into inconveniences.

Never forget that the real reason your server needs to come back online is because of the applications and data it contains. If practical, include the procedures for restoring data from your backup system as part of the disaster recovery documentation. 

That said, this is one part of your disaster recovery process where an IT professional may be required to handle the task. Assuming that is the case, make sure to clearly indicate this in the documentation so that non-IT folks know that they should stop at this point and get assistance.

Testing

Make sure your disaster recovery documentation is as up to date as possible. But how do you know for certain what’s now obsolete or wrong? The best way to find out is to test your documented disaster recovery procedures, including data restoration. How often? At least annually, though it’s even better to run these tests on a quarterly basis.

Now that we’ve discussed what should be in your documentation and how to find out if it’s good or not, what comes next? Improvements.

Audit Your Documentation

Use the results of your testing to improve your disaster recovery documentation. Once you’ve identified what’s obsolete, either toss it or move it to a legacy archive system. Make sure it does not remain in your disaster recovery documentation, as obsolete information may make recovery efforts harder.

Automation

As part of testing your disaster recovery documentation, identify which human-driven processes can be handled by automation and invest the time and effort to automate them. For example, if part of your current process includes “open a Terminal window and run this command,” figure out how that process can be automated. Always keep in mind that a human being other than you may be the one in the hot seat for bringing your systems down safely.

Identifying And Fixing Documentation Gaps

Another thing you may find as part of testing is that something was missed in the disaster recovery documentation. A common cause is that a new system was added since the last round of testing and it wasn’t added to the disaster recovery docs. Wherever gaps are found, address them as part of updating the disaster recovery documentation.

Outsourcing Services To Reduce Disaster Impact 

One other thing to keep in mind as you go through the process of documenting your disaster recovery procedures is if particular services can be moved to other systems in your organization or to an outside cloud service. If you’ve transitioned a service to be handled by other systems, you’ve also outsourced the disaster recovery (and associated disaster recovery documentation) for that service to that other system. That’s less work for you and potentially less risk of having a disaster, assuming that the other system is built on a high availability model.

That said, there are crucial questions to ask before moving a particular service:

• Who is managing my data?
• How is my data backed up?
• What happens if you lose my data?

If you don’t get back answers that satisfy your needs, don’t move the service.

Conclusion

Writing good disaster recovery documentation with the model I’ve laid out above is challenging. It requires in-depth knowledge of how your systems work, but also requires constructing step-by-step directions that nearly anyone in your work environment could complete successfully. IT disaster planning is a never-completed task, as your IT environment is always changing and the documentation will need to reflect those changes.

That said, the reward for all the hard work may be like the one in the story I began with: Being able to get on a plane and take off for that non-ruined vacation. When disaster struck, your physical presence was unnecessary because someone else’s hands and eyes were able to follow the documentation and handle the job.

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.

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.

The root cause for the encryption pausing and not resuming was a problem with resizing the CoreStorage volume. When the CoreStorage volume was unable to grow, the encryption was paused and could not resume until the resize issue was addressed.

To fix this issue:

1. Update your Mac to 10.10.3, or boot from an alternate drive which is running 10.10.3.
2. Unlock the encrypted drive if necessary
3. Open Terminal
4. Run the following command to get the disk identifier for the boot drive:

diskutil list

5. Once you have the disk identifier information, run the following command with root privileges:

fsck_cs -y disk_identifier_goes_here

Running the fsck_cs tool should repair the CoreStorage volume and address the resizing issue. As part of the output, it should show that encryption is resuming.

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:

https://forums.developer.apple.com/message/7293

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.

Prerequisites:

A copy of the Sophos Installer application and the Sophos Installer Components directory from your Sophos server. The Sophos installer application should be available inside from your Sophos Enterprise server using an address similar to that shown below:

smb://sophos.server.address.here/SophosUpdate/CIDs/S000/

Credentials to mount the SophosUpdate share on your Sophos Enterprise server

Credentials to download Sophos updates from Sophos, in the event that the Sophos AV client is unable to connect to your Sophos Enterprise server

Packages

Configuring the Sophos AntiVirus installer application

1. Connect to the following server address (substitute the hostname of your server where appropriate):

smb://sophos.server.address.here/SophosUpdate/CIDs/S000/

2. Copy the ESCOSX folder available on that fileshare from your Sophos server to somewhere convenient on your Mac.

3. Open Terminal.

4. Change directory location with the following command:

cd /path/to/ESCOSX/Sophos\ Installer.app/Contents/MacOS

5. Run the following command to configure the Sophos installer with the needed credentials for your Sophos Enterprise server, with the fallback option of updating from the update feed hosted by Sophos:

Note: this command should all be on one line.

sudo ./CreateUpdatePreconfig -PrimaryServerType 2 -PrimaryServerUserName SMB_Username_Goes_Here -PrimaryServerPassword SMB_Password_Goes_Here -PrimaryServerURL smb://sophos.server.address.here/SophosUpdate/CIDS/S000/ESCOSX -SecondaryServerType 0 -SecondaryServerUserName Sophos_Username_Goes_Here -SecondaryServerPassword Sophos_Password_Goes_Here

Note: If your username contains special characters, use quotes around the username. For example, if the PrimaryServerUserName value is an Active Directory account where you need to include the domain, the PrimaryServerUserName value should look like this:

-PrimaryServerUserName "DOMAIN\username_goes_here"

6. Running the CreateUpdatePreconfig command should produce output similar to that shown below:

7. As part of running the CreateUpdatePreconfig tool, an updateconfig.plist file is created in /path/to/ESCOSX/Sophos Installer Components. This stores the login information for your Sophos server.

Once the updateconfig.plist file has been created, a standard Apple installer package can now be created to install Sophos.

Building the installer package

1. Set up a new Packages project and select Raw Package.

2. In this case, I’m naming the project Sophos Enterprise Anti-Virus 9.2.4

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Post-Installation Behavior section, set On Success: to Do Nothing
In the Options section, check the box for Require admin password for installation.

5. Click on the Scripts tab in your Packages project.

6. Select the Sophos Installer application and its associated Sophos Installer Components directory and drag it into the Additional Resources section of your Packages project.

7. The last piece is doing an automated uninstall of any existing Sophos installations, then installing a fresh copy of Sophos with the pre-configured autoupdate settings.

For this, you’ll need a preinstall script and postinstall script. Here are the ones I’m using:

Preinstall:

Postinstall:

8. Once you’ve got the preinstall and postinstall scripts built, run the following command to make the script executable:

sudo chmod a+x /path/to/preinstall

sudo chmod a+x /path/to/postinstall

9. Once completed, add the preinstall and postinstall scripts to your Packages project.

10. Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by taking it to a test machine that does not have Sophos and install it. The end result should be that Sophos Anti-Virus installs properly and has the pre-configured settings for your Sophos Enterprise server included automatically.

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’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.

To access this documentation, go to a Mac which has Casper’s agent installed and run the following command with root privileges:

jamf help -hidden

This will display information about commands which aren’t mentioned when you run the standard command for help:

jamf help

You can access more documentation about these hidden commands by running the following with root privileges, referencing the command you want more information on:

jamf help command_goes_here

I do a lot of my application testing in VMs, so when Firefox 39.0 came out, it went into my test environment and I built a new VM to check it out.

Firefox 39.0 looked like this when I launched it in my test VM.

As part of my testing workflow, I also installed Firefox 39.0 onto a couple of actual Macs.

Firefox 39.0 looked like this when I launched it on those machines.

As you can see, two very different results were discovered as part of my testing. After a few rounds of “It’s broken in the VM, retest, it’s still broken, retest on my laptop, no problem, repeat,” I finally tracked down a Mozilla bug report that indicated that the issue was not specific to my environment and gave me the potential scope of the issue. For more information, see below the jump.

Between the release of Firefox 38.0.5 and Firefox 39.0, Mozilla appears to have introduced a change that affected OS X VMs running on the following virtualization solutions for OS X:

VMware Fusion
VirtualBox

It’s not mentioned in the Mozilla bug report, but my assumption would be that Firefox 39.0 running in OS X VMs on Parallels’ virtualization solution would also exhibit the same problem.

The scope presently appears to be limited to virtual machines running OS X as a guest OS. I tested Firefox 39.0 on the following OSs on physical Macs and the issue did not appear:

• OS X 10.9.5
• OS X 10.10.4

I also tested Firefox 39 on Windows 8.1 in a VMware VM and the issue did not appear.

For those who wanted a copy of my virtualization talk at Penn State MacAdmins Conference 2015, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/PSU2015vmPDF

Keynote – http://tinyurl.com/PSU2015vmKeynote

Note – 7-9-2015: Apparently, there were enough downloads of the presentation today that I’ve hit a Dropbox bandwidth limit. If you’re hitting this issue, please try downloading again tomorrow.

Update – 7-10-2015: It looks like Dropbox is still suspending access, so the virtualization session slides are also available via the links below:

PDF – https://goo.gl/zaZAfh
Keynote – https://goo.gl/H9oeYH

For those who wanted a copy of my documentation talk with Vanessa White at Penn State MacAdmins Conference 2015, here are links to the slides in PDF format.

PDF – http://tinyurl.com/PSU2015docPDF

For those who wanted a copy of my virtualization talk at MacIT 2015, here are links to the slides in PDF and Keynote format.

PDF: http://tinyurl.com/MacIT2015vmPDF

Keynote slides: http://tinyurl.com/MacIT2015vmKeynote

Michael Lynn was good enough to pull together the complete list (so far!) of Twitter photo posts from Penn State MacAdmins Conference 2015.

There are over 300 in all, so I’m splitting this into three posts as having WordPress display 300+ embedded tweets may make your browser cry. The first hundred are below the jump. Enjoy!

http://twitter.com/Sacrilicious/status/618401416294572032

http://twitter.com/DariMorg/status/618453542253252609

http://twitter.com/tommrkr/status/618497851895750656

http://twitter.com/DariMorg/status/618526802923909120

Michael Lynn was good enough to pull together the complete list (so far!) of Twitter photo posts from Penn State MacAdmins Conference 2015.

There are over 300 in all, so I’m splitting this into three posts as having WordPress display 300+ embedded tweets may make your browser cry. The second set is below the jump. Enjoy!

http://twitter.com/jerbaker10/status/618860126750031876

http://twitter.com/sonradditz/status/618982263955566593

Michael Lynn was good enough to pull together the complete list (so far!) of Twitter photo posts from Penn State MacAdmins Conference 2015.

There are over 300 in all, so I’m splitting this into three posts as having WordPress display 300+ embedded tweets may make your browser cry. The final set is below the jump. Enjoy!

The folks at Penn State MacAdmins always have great music for their conference and have been kind enough to share the playlists via Spotify.

For those who want the playlists, please see the links below:

Penn State MacAdmins 2013 playlist: http://sptfy.com/macadmins2013

Penn State MacAdmins 2014 playlist: http://sptfy.com/macadmins2014

Penn State MacAdmins 2015 playlist: http://sptfy.com/macadmins2015

As part of my work with packaging, I’ve built a few Automator-based applications to assist me and other Mac admins.

• Payload-Free Package Creator
• Simple Package Creator
• First Boot Package Install Generator

Along with building the applications themselves, I wanted to provide custom icons for these apps. This would help them be instantly distinguishable from other Automator applications and also help make them look more polished.

I recently decided to change out the application icon for Payload-Free Package Creator, as its icon had been created on Mavericks and now appeared a little dated when used on Yosemite. With input from my colleague Elliot Jordan, the new icon for Payload-Free Package Creator now looks like this.

For more information on how I went from this PNG file to an icon set for the application, please see below the jump.

The first step is creating a high-resolution image of what you want your icon to look like. You can always convert a high-res image into a lower resolution image, but the reverse is not true.

Once you have your image created, convert it into an icon set. There are ways to do this manually, but I prefer to use iConvert Icons for this task. iConvert Icons is a paid app available on the App Store that allows you to drag-and-drop an image onto its application window and have it convert the image into one or more icon formats.

For my own applications, I have the following options selected in iConvert Icons:

• icns – Mac OS folder icon
• icns – Mac OS icns file
• Xcode iconset

I primarily use the Mac OS folder icon and Mac OS icns files in my Automator applications, but creating the Xcode iconset allows me to see how the icons will appear at various resolutions before actually applying them to the application.

To change the Automator application icon via the Finder’s Get Info window, I’m using the Mac OS folder icon generated by iConvert Icons with the procedure described here in this Apple KBase article:

https://support.apple.com/kb/PH19073

To change the Automator application’s embedded icons, so that the application’s icon also appears in dialog windows, I’m using the following procedure:

1. Right-click on the Automator application
2. Click on Show Package Contents

3. Navigate to Contents/Resources
4. Locate an existing file named AutomatorApplet.icns

5. Remove the existing AutomatorApplet.icns file
6. Copy the Mac OS icns file generated by iConvert Icons to the Resources folder
7. Rename the Mac OS icns file to AutomatorApplet.icns

8. Fix permissions as needed for the new AutomatorApplet.icns file, to match those that have been set for the Automator application

9. Close the Finder window

Once the new AutomatorApplet.icns file is in place, the chosen application icon should appear in dialog windows instead of the generic Automator icons.