Demystifying the Apple Lightning to USB 3 Camera Adapter

A common question I get from travellers is, "how can I back up the photos taken with my digital camera without my laptop?"

The answer is to get an Apple Lightning to USB 3 Camera Adapter (MK0W2AM/A | model A1619) to use with your iPad/iPhone. This adapter works with any iPad or iPhone with a Lighting port, which covers almost every iPad/iPhone sold in the last 6 years.

Usage

1. Simply connect your camera's USB cable into the adapter and plug the adapter into your iPad/iPhone.
2. The Photos app will automatically launch and allow you to import specific photos or import all.
3. Imported photos will appear in the Last Import photo album.

Once imported, the next time your iPad/iPhone is connected to the Internet (e.g. hotel Wi-Fi), photos can be uploaded to your iCloud Photo Library.

The Photos app also remembers previously imported photos, so you don't need to worry about accidentally reimporting the same photos again.

Photos are not modified in any way and retain all metadata including date & time, location (cameras with GPS), camera settings used to take the photo and original filename.

Testing the adapter with a Panasonic Lumix DMC-TZ30, I found the Photos app fails to detect AVCHD formatted videos and therefore will not import them. Unless your camera records videos as MP4 files, importing videos will almost certainly require access to a computer.

The adapter is superior to the non-USB 3 Apple Lightning to USB Camera Adapter (MD821AM/A | model A1440).  Some digital cameras attempt to recharge when connected, the extra draw of power causes the iPad/iPhone error: "Cannot Use Device: The connected device requires too much power."

This error still occurs with the new adapter, however attaching a Lightning charger to the adapter resolves the error, allowing more cameras to work. If you are still getting the error: "Cannot Use Device: The connected device requires too much power." after connecting a charger, the charger is not outputting enough power for both the iPad/iPhone and the camera. Make sure you are using the charger that came with your iPad/iPhone.

Note: If you already own the older Lightning to USB Camera Adapter, connecting the adapter to an externally powered USB hub should also resolve the error.

Owners of the iPad Pro 10.5-inch and iPad Pro 12.9-inch will experience faster import speeds as the adapter performs at USB 3 speeds, compared to standard USB 2 speeds with other iPads and iPhones.

Surprisingly the adapter also works with many USB devices including:

• keyboards: with support for screen brightness, volume and playback controls
• barcode scanners: ideal for point-of-sale terminals
• Ethernet adapters: ideal for fixed digital kiosks, Apple list supported models here.
• hubs: connect multiple USB devices at once
• memory card readers (e.g. microSD, MMC, etc.)
• microphones: for higher quality audio recording
• Musical Instrument Digital Interface devices (e.g. MIDI keyboards)

Note: The adapter does not provide access to storage apart from importing photos & videos.

Automate the Setup of Microsoft Exchange Accounts on OS X

I have been recently looking for the best way to automate the setup of Exchange accounts (specifically Office 365 hosted) on shared Macs. William Smith has created an impressive Exchange Setup AppleScript, perfect for Microsoft Outlook users.

I also wanted to automate the setup of Exchange accounts for Apple’s native OS X apps (Mail, Contacts, Calendars, Reminders and Notes). Normally this would be done with a Mobile Device Management (MDM) solution, pushing out user personalised configuration profiles. But for those situations where a MDM isn’t feasible (possibly due to budget, resources, policy, etc.) or simply overkill this post should help you out. 

To make life easier for those without a MDM I have put together a bash script to automate the setup of Exchange accounts on OS X.

How it works

The script locally generates and installs a user configuration profile (.mobileconfig file). To avoid the account being added as offline the user is also prompted for their Exchange account password.

Usage

I have tested this script on OS X El Capitan (10.11) with multiple Office 365 Exchange accounts.

1. Install Joseph Chilcote's Outset script.
2. Download the addexchangeaccount.sh script and customise the required DOMAIN and EXCHANGE_HOST values.
3. Then copy the customised script into /usr/local/outset/login-once/ and remember to make it executable.

That's it! The first time a user logs in they are prompted to enter their Exchange account password and then the script does the rest.

Munki Business - A Guide to Munki 2

A lot has changed since my original post on Munki 1, with Munki 2 well and truly out I have taken the opportunity to write an updated guide on Munki 2.

What is Munki?

Munki is a community driven project created by Greg Neagle, allowing IT Administrators to efficiently deploy software to large numbers of Macs.

A Munki implementation can be broken down into two core parts;
a) repository hosted on a web server
b) bunch of clients running the Munki software
 

A Munki Repository

Since a Munki repository is simply a collection of organised files served out by a web server it can be hosted on any web server (e.g. IIS, Apache, etc.) regardless of platform. In the situation where the repository is hosted on a remote server, Administrators can remotely edit the repository over a network share.

Every Munki repository is comprised of the following four directories:
pkgs: All package (.pkg) and disk image (.dmg, .iso) files.

pkgsinfo: For each piece of software in the pkgs directory there is an associated file in pkgsinfo. These files contain detailed information about that piece of software and the catalog(s) that software is assigned to. Conventionally these pkgsinfo files have the .plist extension.

catalogs: Catalog files are generated from the contents of pkginfo files, they are used to separate production (tested) from development (untested) versions of software.

manifests: Clients are configured to download a particular manifest file. These manifest files contain a list of software to install and the catalog (version) to use.

Note: Apart from the contents of pkgs every other directory contains standard Extensible Markup Language (XML) files.

With the release of Munki 2, there are three additional directories:
artwork: A place to store any images used within software descriptions.

client_resources: Home to the Managed Software Center application theme files.

icons: Contains images (.png) used as software icons in the Managed Software Center application. The recommended icon resolution is 300x300.

Setting Up a Repository

The steps for setting up a Munki repository vary depending on web server and platform. For OS X the standard procedure involves creating a ‘munki_repo’ directory in ‘/Users/Shared/‘, populating it with the directories listed above. Then creating a symbolic link from ‘/Users/Shared/munki_repo’ to ‘/Library/Server/Web/Data/Sites/Default/’ and enabling the OS X Server web server.

View fullsize

Managing Munki Repositories

Download and install the latest release of Munki Tools here.

Part of Munki Tools are the Munki Admin Tools for command-line management of Munki repositories. Unless you enjoy working purely in the command-line, I recommend downloading Hannes Juutilainen’s MunkiAdmin, a user-friendly application for managing Munki repositories. 

Install AutoPkg

AutoPkg automates the process of downloading and importing third party software updates straight into the Munki repository. Look at setting up AutoPkg by following my guide here.

Manually Importing New Software

If you wish to manually import a piece of software here are the steps:

Before we can use the Munki Admin Tools we need to complete the initial setup. To start the setup open Terminal and type:

munkiimport --configure

View fullsize

The 'Repo fileshare URL' can be left blank if the Munki repository is stored on the local disk, otherwise provide a network share path (e.g. smb://SERVERADDRESS/munki_repo).

I recommend following the guidelines below, to keep your Munki repository tidy:
First rename the software you wish to import:

• Match the name to the software (e.g. jre-7u67-macosx-x64.dmg > java.dmg).
• Only use lowercase letters (e.g. Firefox 32.0.3.dmg > firefox.dmg).
• Do not use dashes, underscores or spaces (e.g. Skype_6.19.0.452.dmg > skype.dmg).
• Delete version numbers (e.g. vlc-2.1.5.dmg > vlc.dmg).
• Omit the developer’s name (e.g. googlechrome.dmg > chrome.dmg).

Once renamed open Terminal and type ‘munkiimport ‘ (take note of the trailing space).
Drag the renamed package onto the Terminal window and hit return.
When prompted for an item name enter the name of the package without the extension (e.g. firefox.dmg > firefox).
The display name can contain spaces and capitals (e.g. Flash Player).
The description can be left blank for now, as it can be added in later with MunkiAdmin.
The version number is pulled from the software, verify it is accurate and hit return, otherwise type in the correct version number.
When prompted for a category, use the Mac App Store categories as a guide (e.g. Productivity, Utilities, etc).
Enter the developer’s name (e.g. Apple, Google, etc).
When prompted for Catalogs hit return.
You will be presented with a summary of your input, if you are happy that it is all correct type y and hit return.
Just hit return when asked for a subdirectory path.
Munki may offer to extract an icon, type y and hit return. 
You are given a chance to make any alterations to the newly generated pkginfo file, simply press control + X.
Lastly you are asked if you would like to rebuild catalogs, type y and hit return.

View fullsize

Assigning Software to Manifests

To put it simply manifests contain lists of software to install and the catalogs (software version) to use. Software can either be set as mandatory (managed_installs) or optional (optional_installs). Optional installs provide a self-service experience similar to the Mac App Store.

View fullsize

MunkiAdmin makes the process of assigning software to manifests simple, just add a new item under either the Installs tab (mandatory) or the Optional Installs tab.

View fullsize

As seen in the diagram below, every Mac installs a SOE (Standard Operating Environment) suite of software. Depending on the Mac’s location (e.g. Art, Music, etc.) and the intended user type (e.g. staff or student), additional software (e.g. Photoshop, Sibelius, etc.) is installed. Since Munki clients can only check a single manifest, I have dealt with this limitation by stacking manifests.

View fullsize

It may seem confusing at first, but once the manifest infrastructure is in place, assigning new software to all relevant clients is simple. The green bubbles are manifests that clients check and we normally avoid adding any software directly to these. Yellow are purely for merging manifests, again nothing should be added to these. Blue are core attributes (e.g. laptop, staff, science, etc.) and software is assigned to these.

Configuring Munki Clients

Once Munki Tools is installed, clients need to be configured with the Munki repository's address and which manifest to check. Often these settings are configured using DeployStudio, a payload-free package or another means of script execution. This can be performed manually in Terminal with:

defaults write /Library/Preferences/ManagedInstalls.plist SoftwareRepoURL http://SERVERADDRESS/munki_repo
defaults write /Library/Preferences/ManagedInstalls.plist ClientIdentifier MANIFESTNAME

Testing Software

Before pushing out software to every Munki client it is important to thoroughly test that it works as expected. You should configure at least one test machine the same way as the rest of your client’s with the exception of pointing it to a testing manifest.

A testing manifest should include both the development and production catalogs, as well as a manifest directly accessed by clients.

Once that piece of software has been deemed stable, add it to the production catalog and watch as the rest of your clients install it.

Frequently Asked Questions

If you have read this far, you should be starting to get an understanding of how useful and feature rich Munki is. For readability I have chosen to tackle common queries I receive regarding Munki.

How does Munki know what is already installed?
Any applications installed by simply dragging and dropping them into Applications are detected by Munki. If a user deletes a drag and drop app from Applications Munki will notice its absence and reinstall it.

With package files, Munki indirectly checks for the existence of receipt files, therefore deleting the associated .plist and .bom files of a package in /var/db/receipts will cause Munki to reinstall that package.

Managed Software Center keeps attempting to install the same package over and over. What’s going wrong?
If MSC loops on a package, compare the receipts listed in the pkginfo file to the receipts present in the '/var/db/receipts/' directory. Once you figure out the missing receipt(s) mark them as optional (ignored).

You can also use Terminal’s ‘pkgutil’ command to search for installed receipts. In the example below I am searching for receipts containing the word xerox, the (?i) part ignores case and .* are wildcards.

View fullsize

Can we customise the banners in Managed Software Center?
Absolutely! You can even customise the sidebar and footer links. The official Munki wiki does a great job covering this in detail here.

How frequently does Munki check for updates?
After ten seconds of inactivity at the login window Munki will automatically install any locally cached updates.

By default a launch daemon is set to run ‘/usr/local/munki/supervisor’ ten minutes past every hour. The supervisor generates a random delay of up to sixty minutes to help stagger clients contacting the Munki repository. Once the delay is over supervisor triggers ‘/usr/local/munki/managedsoftwareupdate’, if there are new updates the logged in user is notified by Managed Software Center.

Note: Munki is also capable of installing software without any user intervention. This is achieved  by enabling 'Unattended install' in MunkiAdmin.

View fullsize

Will Managed Software Center work outside of the organisation?
As long as the web server hosting the Munki repository is externally accessible MSC will also work externally. If you plan on hosting a Munki repository on a public web server you should also configure SSL Client Certificates to ensure access to the repository is limited to permitted clients. 

How can I remotely trigger Munki clients to check for updates?
Using Apple Remote Desktop you can trigger groups of Macs to instantly check the Munki repository for updates and install.

Trigger Munki instantly regardless of whether a user is logged in:

/usr/local/munki/managedsoftwareupdate;/usr/local/munki/managedsoftwareupdate --installonly

Trigger Munki to run the moment the current user logs out or if nobody is currently logged in:

touch /Users/Shared/.com.googlecode.munki.checkandinstallatstartup

Tip: You can save those commands as Unix command templates in ARD.

View fullsize

How do I go about troubleshooting a Munki issue?
Since the Munki repository is just a bunch of files served out by a web server, almost all troubleshooting is performed from Munki clients.

On a client open Terminal and run:

sudo managedsoftwareupdate

This will immediately display any issues with the repository. You can also check the client log files stored in ‘/Library/Managed Installs/Logs/‘.

How do we update the version of Munki Tools running on clients?
AutoPkg makes it easy to keep your Munki clients up-to-date with frequently updated software (e.g. Flash Player, Java, etc.). You can quickly set up AutoPkg by following my guide here. There is a munkitools2.munki.recipe override included in my collection of recipe overrides. This will automatically import the latest release of Munki Tools into your Munki repository, as four separate packages:
munkitools_core.pkg: The required core command-line tools used by Munki.
munkitools_admin.pkg: The optional admin command-line tools for managing Munki repositories.
munkitools_app.pkg: The user-friendly Managed Software Center application.
munkitools_launchd.pkg: The launchd items to automate checking for updates.

View fullsize

The only package that should be assigned to a manifest is the munkitools_app, the rest are either marked as ‘required’ or ‘update for’ packages that would be installed regardless.

Installing & Automating AutoPkg with a Launch Daemon

UPDATE (1/12/15): Since AutoPkgr now supports recipe overrides I recommend using AutoPkgr over my headless script.

---

AutoPkg is a great tool for downloading and packaging software for distribution. It also integrates nicely with Munki. After testing AutoPkg I looked into methods to further automate the updating process. I came across Sean Kaiser’s blog detailing how he created a script and triggered it using a launch daemon. I took his script as an example and began to build my own, with a few extra tweaks.

My AutoPkg Wrapper triggers AutoPkg to run once daily at 8:30am, dynamically checking for updates to user recipe overrides and sending an email in the event of a new package.

Without further ado I will walk you through setting up AutoPkg and automating it with my AutoPkg Wrapper.

Note: If you haven’t already, it is important to install Munki and AutoPkg.

Configuring AutoPkg

First we need to add the main recipe repository to AutoPkg, we do this by opening Terminal and typing:

autopkg repo-add http://github.com/autopkg/recipes.git

Note: AutoPkg requires Git to be installed, if it is not installed you will be prompted to install it from Apple Software Update.

View fullsize

Next we need to set the location of our Munki repository:

defaults write com.github.autopkg MUNKI_REPO "/PATH/TO/MUNKI_REPO"

AutoPkg uses recipe overrides to override default or unspecified recipe attributes. My Munki repositories follow a consistent naming convention and therefore I create recipe overrides for every AutoPkg recipe used. Below are the criteria for packages added to my Munki repositories:

• Packages are placed directly into pkgs and not into subdirectories.
• Packages are named in lowercase (e.g. Firefox.dmg > firefox.dmg).
• Packages do not contain the developer’s name (e.g. googlechrome.dmg > chrome.dmg).
• Packages are initially added to the development catalog.
• The pkginfo display_name attribute is set to match the package name with proper case and spaces (e.g. flashplayer.dmg > Flash Player).
• The unattended_installs pkginfo attribute is disabled.
• The developer and category pkginfo attributes are set.

Optionally you can download and install my collection of AutoPkg recipe overrides from GitHub:

git clone https://github.com/Error-freeIT/AutoPkg-Recipe-Overrides.git ~/Library/AutoPkg/RecipeOverrides

With AutoPkg configured let’s test a recipe:

autopkg run -v AdobeFlashPlayer.munki

View fullsize

Automating AutoPkg

If that worked it’s time to automate AutoPkg, download and run the autopkgwrapper installer:

git clone https://github.com/Error-freeIT/AutoPkg-Wrapper.git /tmp/autopkgwrapper && cd /tmp/autopkgwrapper && sudo ./install.sh

The install script requires administrator privileges and therefore will prompt for a password, as it copies the script and launch daemon into place and opens the script in Nano for configuration.

Update the ACCOUNT_NAME value to match the account name (a.k.a. username) containing the recipe overrides and update the EMAIL_FROM and EMAIL_TO addresses.

Note: To save changes in the Nano text editor press control + X, type y and hit return.

View fullsize

That’s it! Once set up you will be emailed when new items are added to the Munki repository. Standard workflow would then involve testing the new software and if the new software is stable, simply add it to your production catalog.

Troubleshooting The AutoPkg Wrapper

This AutoPkg Wrapper was intended to only be run as a launch daemon (by root) to manually run the AutoPkg Wrapper type:

sudo "/Library/Scripts/AutoPkg Wrapper/autopkgwrapper.sh"

View fullsize

You can update your email settings by typing:

sudo nano "/Library/Scripts/AutoPkg Wrapper/autopkgwrapper.sh"

By default the installed launch daemon is set to run daily at 8:30am, if you want to further customise how often the script is run I recommend editing the launch daemon with Lingon X.

Apple's iPad/iPhone Out-of-Warranty Service

I often find those with broken iPads/iPhones are unaware of Apple’s Out-of-Warranty Service. Apple's Out-of-Warranty Service encourages users with accidental damage to stay with Apple without paying full price for a new iPad/iPhone. This is a huge saving as with today's pricing, a 64GB iPhone 5S would cost AU$1,129 outright and if the device was damaged, replacing it through Apple's Out-of-Warranty Service would cost only AU$348.95!

Apple’s Out-of-Warranty Service covers devices that have been water damaged, cracked or are outside of their warranty period. The only requirements are that the device needs to be in one piece and cannot be damaged due to an unauthorised modification/repair.

The web pages containing the Out-of-Warranty Service information can be hard to find. Below are direct links:

iPad - Service Answer Centre

iPhone - Service Answer Centre

Simply walk into an Apple Store with your device and pay the Out-of-Warranty Service fee. Apple will replace your iPhone/iPad with a new or equivalent (refurbished) device of the exact same model and capacity.

PHP ARD (Apple Remote Desktop) Import List Generator

In the past, adding new computers to Apple Remote Desktop has been through either Bonjour discovery (local subnet) or scanning IP address ranges. These methods work great until you have hundreds of Macs and your ARD computer list starts to become out of sync from your colleagues.

Since we keep an asset database tracking our Mac's hostnames and last known IP addresses, I have written a PHP function for generating an ARD friendly import file.

You can find the source code on GitHub here.

This function only requires a filename and an array of Mac's with their hostname and last known IP address. Examples of these are included at the top of ardgen.php. With very little work, this script could be integrated into any database containing Mac's with their recent IP addresses.

An earlier version of this function also included device MAC addresses. However, during a migration to a new database, MAC address information was not ported over, therefore the optional MAC address data was removed from the plist generation. If you have access to the MAC addresses of your computers it is worth including it in the plist.

How to import an ARD import list file

Open Apple Remote Desktop and click 'File' > 'Import List...'

View fullsize

Select your newly created plist file.

View fullsize

Assuming all your Mac's use the same Remote Management user account, uncheck 'Verify user name and password before adding' and then click 'Add.'

View fullsize

With a single import, all your Macs are now in ARD!