Deploying OS X Configuration Profiles Without MDM

mobileconfigI was recently in a conversation with someone who needed to deploy configuration profiles to OS X clients, but they did not have the ability or authority within their organization to open the network ports required to implement a Mobile Device Management (MDM) solution.  This post describes how to install configuration profiles with an installer package.

The first step is to create and export your configuration profile as a .mobileconfig file.  These files can be created on a computer running OS X Server, using Profile Manager.  For more details on creating and downloading configuration profiles, see Apple’s Profile Manager Help documentation.

Once you have the .mobileconfig file, you’ll want to create a package that will deploy this file to a known location on your client systems.  I recommend a folder in the root Library named for your organization such as…

/Library/myOrg

For instructions on creating packages, refer to the documentation for your favorite package building tool.  My favorite is Composer.

Simply deploying the .mobileconfig file to this location won’t install it.  Apple provides a command line tool called profiles.  The profiles command can be used as part of a postinstall script included in the package that deploys the .mobileconfig file.  Below, find the two lines to include in this script…

#!/bin/bash
/usr/bin/profiles -I -F "/Library/MyOrganization/Company Wi-Fi.mobileconfig"

 

If the .mobileconfig profile should be deleted once installed, the following command can be added to a third line in the script…

rm "/Library/MyOrganization/Company Wi-Fi.mobileconfig"

 

Of course, “/Library/MyOrganization/Company Wi-Fi.mobileconfig”  should be replaced in each command with the quoted path to the .mobileconfig file deployed by the package.

I hope this is helpful.

Email to SMS Gateways

System administrators may find themselves wanting to send SMS messages to mobile devices for a variety of reasons, such as sending over the air enrollment invitations to devices to be enrolled with the Casper Suite. Many carriers, though certainly not all, employ an SMS gateway that allows email messages to be received by the carrier’s gateway and in turn transmitted to devices as SMS messages. In some cases, MMS messages are supported as well.

Addressing a mobile phone number through one of these gateways is accomplished by sending an email to @. For example, a Verizon Wireless phone with the number 212-555-1212 can receive SMS messages at the email address 2125551212@vtext.com.

Below, find listed the SMS gateway domains I have been able to find for official iPhone carriers. Where I’ve been able to find the pertinent information, I have noted carriers with special considerations, such as an activation process. The note “difficulties reported” indicates domains that are frequently referenced as not working. If your carrier isn’t listed below, I recommend contacting their customer service line to find out if they offer an SMS gateway. if they do, ask for the domain name and whether activation is required. If you discover any domains not listed below, I’d appreciate a comment on this article so I can update it for future reference.

Carrier Domain Country
AT&T (SMS) txt.att.net United States
AT&T (MMS) mms.att.net United States
Boost Mobile myboostmobile.com United States
C Spire cspire1.com United States
Cricket sms.mycricket.com United States
MetroPCS mymetropcs.com United States
Sprint messaging.sprintpcs.com United States
T-Mobile tmomail.net United States
U.S. Cellular email.uscc.net United States
Verizon Wireless (SMS) vtext.com United States
Verizon Wireless (MMS) vzwpix.com United States
Virgin Mobile vmobl.com United States
Telstra onlinesms.telstra.com
• Note the absence of .au
Australia
Optus optusmobile.com.au Australia
Vodafone Service not offered Australia
Bell txt.bell.ca Canada
Fido fido.ca Canada
Koodoo msg.koodomobile.com Canada
MTS text.mtsmobility.com Canada
Rogers pcs.rogers.com Canada
Sasktel sms.sasktel.com Canada
Telus msg.telus.com Canada
Virgin Mobile vmobile.ca Canada
3 three.co.uk United Kingdom
EE mms.ee.co.uk
• Difficulties reported
United Kingdom
O2 mmail.co.uk
• Include +44
• Must activate by texting “EMAIL” to 2020
United Kingdom
Orange omail.net
orange.net
• Difficulties reported
United Kingdom
T-Mobile t-mobile.uk.net
• Include leading “0” in number
• Must be activated via customer service line or account web portal
• May not be functioning since joining EE alliance
• Unverified
United Kingdom
Vodafone vodafone.net United Kingdom
O2 o2online.de
• Use leading 0
Germany
Telekom (T-Mobile) t-d1-sms.de
• Use 12 digit number, leading 0
t-mobile-sms.de
• Use 11 digit number
Germany
Vodafone vodafone-sms.de
• Use leading 0
Germany
Orange search ongoing France
SFR sfr.fr France
Bouygues Telecom mms.bouyguestelecom.fr
• Difficulties reported
France
Virgin Mobile search ongoing France
Free search ongoing France
1010 csl1010.com Hong Kong
Three sms.three.com.hk Hong Kong
Broadway search ongoing Hong Kong
Fortress search ongoing Hong Kong
one2free search ongoing Hong Kong
SmarTone search ongoing Hong Kong
Wilson Communications search ongoing Hong Kong
Softbank username@softbank.ne.jp
• Note username is used, not phone number
Japan
Mobily Gateway not offered Saudi Arabia
STC Support did not respond Saudi Arabia

IPSW File Primer

ipswBecause I have been asked a few times, here’s some basic information about IPSW files used by iOS devices for a short Friday post.

IPSW files (iPod Software) are the files used by iTunes, Apple Configurator, and Xcode to restore or update an iOS device’s firmware.  This includes the iOS operating system and the built-in apps.  These files are compressed archives and can be downloaded manually from Apple’s iOS Dev Center, or automatically using iTunes or Apple Configurator.  Once updated, there is no Apple-supported method for downgrading iOS on a device.

There is a different .ipsw file for each iOS version and device model.  For example, an iPhone 5, iPad Mini Wi-Fi, iPad Mini Wi-Fi + Cellular, and a 4th Generation iPod Touch can all run iOS 6.1.2, but they will each use a different .ipsw file to install the iOS system software.

Looking at the name of an .ipsw file, we can learn all we need to know about its contents.  For example, an ipsw file called…

iPod4,1_6.1.2_10B146_Restore.ipsw

…is for a 4th Generation iPod Touch, as indicated by “iPod4,1”, which is known as the model identifier for this product. After the first underscore, we find the commonly used version number of the iOS software contained within – in this case, 6.1.2.  Next, we find the build number, or developers’ detailed version number – in this case, 10B146. After the final underscore, we see “Restore.ipsw” which is the common suffix for every .ipsw file.

Mordac the Preventer is Dead

Dilbert.com

The title of this post refers to a character from the Dilbert comic strip by Scott Adams. Mordac is a systems administrator whose “demeanor suggests he simply takes pleasure using his management and technical powers to make the users of “his” systems suffer. This sort of system administrator has long been accepted or even the norm in enterprise IT departments while at the same time being the bane of end users’ existence.

Practitioners of this style of administration are living on borrowed time, unless they change their attitudes.  Systems that lock, block and prevent users from doing things generally create minimal, if any, value and can cause severe hindrances to productivity and morale.

In most organizations, IT is an expense and distraction from the organization’s goals which tend to be things like making money or educating people.  As such, it is in IT’s own best interests to support the success and efficiency of those who contribute to the organization’s primary goals.  When a “Mordac” controls the user experience,  and the standard answer to questions users pose about new and innovative products and workflows is “no”, there are only a few outcomes, none of which are ultimately good.  Assuming the users comply with the denial, the organization may be missing out on increased efficiency and/or competitive advantage.  More likely though, the users will do as they like anyway, potentially exposing sensitive data, or simply getting the job done better without IT.  Either way, IT is far from the hero in this scenario.  I have lost count of the number of times I have visited an office and found the computer issued by the organization sitting in the corner, powered down and the employee working away on a personal laptop.  When asked about the organization’s computer, the usual answer is something like “I can’t use the [expletive deleted] thing, IT is too restrictive”.

Be proactive.  Enter a dialog with the end users.  Have them define their needs as well as wants.  So long as they serve the organization’s goals and don’t run contrary to any legal requirements imposed on the organization, do your best to fulfill them.  When you can’t, let the users know why.  They may have influences you don’t and can help overcome obstacles.  If a particular obstacle can’t be overcome, at least they know you tried and that you’re on the same team.

iOS Deployment Models for OS X Deployments

As Apple continues to blend systems and features between OS X and iOS, lessons learned from iOS deployments are increasingly valuable to OS X deployments.  In Apple’s iOS 6 Education Deployment Guide, three deployment models are identified.  These models are adapted to OS X deployments below.

  • The Personal Ownership model  is described as “similar to the typical consumer experience. The education institution may or may not own the iOS device, but the end user takes responsibility for ongoing maintenance and retains ownership of all apps and content.”  This model is applicable to a great many OS X deployments.  I often define this as the user’s “functional ownership” of a computer even though the user may not have financial or legal ownership of the computer(s) in question.  Bring Your Own (BYO) programs clearly fall into this model, however it’s not uncommon to find organization-owned computers deployed in such a manner. If the end user has an administrator account, you may be dealing with a personal ownership model.
  • The Institutional Ownership model is what I have often described as a “traditional IT environment”.  Words and phrases such as “lock down” and “prevent” are prevalent here.  The user typically doesn’t have an administrator account and is often limited in how much they can deviate from the organization’s Standard Operating Environment (SOE, a useful term not very widely used in the USA, but prevalent elsewhere).  Given a clear, finite and realistic set of requirements based on the functions needed by the end users, this model can be used to great effect. The environments where this model works best are those with well-defined workflows. Creative users tend to be stifled in such an environment, and it takes a great deal of work and preparation on the part of an IT staff to ensure that systems deployed under this model are able to respond to changes in user need and advances in the technological ecosystem.
  • The Layered Ownership model blends the two models already discussed.  According to Apple, “The Layered Ownership deployment allows for both the end user and the institution to own their respective content on the same device, and the end user performs the majority of maintenance tasks on the device.”  This seems like the best of both worlds.  The organization protects its data and assets while freeing the user to work in whatever manner they find most efficient.  In this model, the user would have an administrator account, but the computer would receive some configuration and management from the organization’s IT staff.

Data

Proprietary and/or confidential data should be a primary concern of any IT organization.  iOS neatly sandboxes each application’s data making it easy to protect through managed apps, but this is not yet an option in OS X.  The growth of cloud systems, both public and private, may provide a solution.  Sensitive data can be accessed via secure websites and/or applications.  If the data is never resident on the client’s hardware, there’s nothing to leak.

Nomenclatural Consistency; RIP Imaging

This post is, in part, a response to Anthony Reimer’s well thought out article on deployment terminology, appearing at AFP548 on 21 May, 2013.

I do agree with a great many of Mr. Reimer’s points.  It is helpful to the profession at large, if we adopt some sensible terminology that is not only consistent, but aligned with Apple’s own lexicon.  After all, this is Apple’s world and we’re just living in it.  It surprises me how often Apple-focused technology professionals, at times even Apple-badged employees, display an ignorance of, or on rare occasions, contempt for Apple’s own established lexicon.

Some words in common use are archaic and should be culled from our collective vocabularies.  The entry for the word “machine” in the Apple Style Guide reads: “Don’t use when you mean computer” (italics Apple’s) and appears thirty times in Mr. Reimer’s article.  In the blue-collar mentality many of us have, “machine” brings about grand romantic illusions of a hardworking sweaty engineer in the bowels of an engine room.  The term also serves to portray the computer as a Victorian engine, whirring and clicking along as it solves a never-ending list of calculations.  This may be a lovely vision if you’re a fan of steampunk, but this vision is far from the reality of the solid-state computers and iOS devices with virtually no moving parts being deployed today.  I bring up this point not to nitpick, but to suggest consistency.  Apple has developed and published its own lexicon.  Why should we ignore that and invent our own terms?  I believe it is far more efficient to use Apple’s terminology whenever applicable and only invent new terms where there is an absence of terminology from Apple.

Another term you’re likely to hear, particularly from sales professionals, is “silos”. A common theme is to draw hard lines of distinction between organizations with terms such as “education”, “enterprise” and “government”.  Why create unnecessary divisive language?  Having worked in and for all of these types of organizations, I can attest that, at least for IT staff, they are purely artificial distinctions and serve only to satisfy the misconceptions and/or egos of the C-level or non-technical management staff.  Computers are computers regardless of whether the goals of the organization using them is to make cheese, cars, laws or to educate children.  Each organization is unique in the set of requirements it lays out for itself, with most organizations assembling their requirements without regard to whether an individual requirement is believed to be an education, enterprise or government item.

The bit of Mr. Reimer’s article that resonates with me the most is the term “customizing”.  I believe that imaging is dead and it’s successor is customizing.  With the prevalence of high-speed networks, Apple Recovery HDs, and advanced management tools such as The Casper Suite and its ilk, that there are few, if any, reasons to ever apply an image to a Mac.  One of the biggest challenges Mac system administrators have historically faced is that of creating a single operating system image or installer that will work on all of their hardware.  Many solutions have been put forth, most of them quite clever, but all sharing the fatal flaw that they are unsupported by Apple.  When you step outside supported models, you cause the proverbial buck to stop with you.  The last thing I suggest doing in any deployment scenario is to make yourself ultimately responsible for malfunctions.  The solution is at once easy and obvious.  Apple ships each computer with a functioning operating system.  Erasing and replacing that operating system is a waste of time.  Using deployment tools, the factory-installed operating system can be configured to meet the organization’s needs.  The only semi-valid argument I have heard against this approach comes from very security-conscious entities claiming that they can’t trust the installation that comes from Apple’s factory.  To these organizations, I ask: Will you be using Apple’s installer to replace the system you’ve erased; and if so, how is that any more secure than the original installation?

You may be thinking that this is all well and good for a new computer, but what about when a computer needs to be repurposed or reassigned?  This is where NetInstall, the Apple Recovery HD, or Internet Recovery if necessary, comes in.  Using Apple’s own installer, the disk can be erased and a fresh operating system, designed and tested by Apple for the hardware in question, can be installed.  Then it’s a matter of customization for the computer’s new intended use.

Custom Paper Sizes

printerIn response to a reader request, here’s how to create custom paper sizes.

This is another item governed by a hidden preference file.  The preference file that governs custom paper sizes is

~/Library/Preferences/com.apple.print.custompapers.plist

This file does not exist until custom paper sizes have been created.  Let’s have a look at the contents of a preference file that defines one custom paper size – 4″ x 6″ borderless paper.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>4x6 Borderless</key>
     <dict>
          <key>bottom</key>
          <real>0.0</real>
          <key>custom</key>
          <true/>
          <key>height</key>
          <real>432</real>
          <key>id</key>
          <string>4x6 Borderless</string>
          <key>left</key>
          <real>0.0</real>
          <key>name</key>
          <string>4x6 Borderless</string>
          <key>printer</key>
          <string> </string>
          <key>right</key>
          <real>0.0</real>
          <key>top</key>
          <real>0.0</real>
          <key>width</key>
          <real>288</real>
     </dict>
</dict>
</plist>

The first three lines identify the file as an Apple preference file.  The fourth line, “” is a dictionary tag.  Dictionary tags are used as containers for preference keys.  A dictionary is an unordered list of keys, whereas its counterpart – the array, is an ordered list of keys.

The fifth line is the first key in this preference file.  In com.apple.print.custompapers, this key is used to define the custom paper size.  This key’s value, starting on the sixth line is another dictionary containing the details for this custom paper size.  Each key is followed by its value.  See the table below for definitions of each of these keys.

Key Value
bottom Bottom margin, expressed in PostScript points*
custom The value “true” indicates this is a custom setting.
height Paper height, expressed in PostScript points*
id The setting’s identifier
left Left margin, expressed in PostScript points*
name The setting’s name
printer Unknown, possibly used to tie settings to individual printers
right Right margin, expressed in PostScript points*
top Top margin, expressed in PostScript points*
width Paper width, expressed in PostScript points*

*1 inch = 72 PostScript points.  Here are some handy Google search terms: “1 inch postscript point”, “1 centimeter postscript point”.

Crafting a custom paper size dictionary by hand requires a bit of arithmetic to translate the PostScript points to more familiar units and the dictionary syntax can be a bit fiddly for some administrators.  A useful shortcut would be to use the GUI to create the custom paper size entry on a test computer, then harvest the dictionary from the resulting preference file.  Once you have the dictionary, you could use it in a Configuration Profile or Managed Preference.

Cleaner Security Scripting

terminalIn previous articles, we have discussed making changes to the /etc/authorization file, also known as the authorization policy database or authorization database, using text editors.  Apple has a tool in Mac OS X that is specifically designed for that purpose.  /usr/bin/security, in addition to a multitude of other uses, security has a command called authorizationdb that allows for edits to the authorization database.

The authorizationdb command has three options, read, write and delete.  These function in much the same way as the defaults command is used to edit preference files.  Let’s use the previous article on setting DVD region codes as an example.  In that article, we discussed how to enable any user to set the initial DVD region code, but still require an administrative user to change the code once set.

To read the current authorization rule, we’ll use this command…

/usr/bin/security authorizationdb read system.device.dvd.setregion.initial

…which gives us the following output…

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>class</key>
     <string>user</string>
     <key>comment</key>
     <string>Used by the DVD player to set the region code the first time. Note that changing the region code after it has been set requires a different right (system.device.dvd.setregion.change).</string>
     <key>default-button</key>
     <dict>
          <key>en</key>
          <string>Set</string>
     </dict>
     <key>default-prompt</key>
     <dict>
          <key>en</key>
          <string>__APPNAME__ is trying to set the DVD region code for the first time.</string>
     </dict>
     <key>group</key>
     <string>admin</string>
     <key>shared</key>
     <true/>
</dict>
</plist>

Notes: Non-English strings in the default-button and default-prompt dictionaries have been removed for brevity.

The boldface “class” key and its value (emphasis mine) are the operative values that we are working with.  Using the write option for the authorizationdb command, we can make the same change described in the previous article, allowing any user to set the initial DVD region code, with a one-line script.

/usr/bin/security authorizationdb write system.device.dvd.setregion.initial allow

After running this command, if we read the contents of the system.device.dvd.setregion.initial key again using /usr/bin/security authorizationdb read system.device.dvd.setregion.initial, we now receive the following output…

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>rule</key>
     <string>allow</string>
</dict>
</plist>

Not only does /usr/bin/security simplify editing the authorization database, it also results in a cleaner entry.

I hope this is useful.

Mounting the EFI Boot Partition on Mac OS X

terminalHere’s the answer to another reader request…

According to WIkipedia, “On Apple–Intel architecture Macintosh computers, the EFI partition is initially blank and not used for booting. However, the EFI partition is used as a staging area for firmware updates.”  When people look to create non-standard boot environments or attempt to build a hackintosh, the first step is often mounting and modifying the EFI boot partition.  Before you read any further, take note: altering your EFI boot partition is not supported by Apple and The Mac Admin takes no responsibility if you render your computer(s) unbootable by mounting and modifying this partition.

To mount an EFI boot partition, follow these steps:

1. Discover the volume identifier for your EFI boot partition.

Run this command:

diskutil list

The output should look something like this:

/dev/disk0
 #: TYPE                     NAME          SIZE       IDENTIFIER
 0: GUID_partition_scheme                  *251.0 GB  disk0
 1: EFI                                    209.7 MB   disk0s1
 2: Apple_HFS                Macintosh HD  250.1 GB   disk0s2
 3: Apple_Boot               Recovery HD   650.0 MB   disk0s3

 

In this case, the volume identifier of the EFI partition is disk0s1

2. Create a mount point.

A mount point is a directory where a non-booted volume is mounted.  On Mac OS X, mount points are typically created in /Volumes.  We can create a directory called efi within /Volumes by running the following command:

mkdir /Volumes/efi

 

3. Mount the EFI partition at the efi mount point.

Run the command:

sudo mount -t msdos /dev/disk0s1 /Volumes/efi

 

That’s it.  Your EFI volume will be mounted.  Modify it at your own risk.

Restoring a Locked iOS Device

iPhone4If you work with, support, or own iOS devices (iPhone, iPad, iPod Touch), you probably have or will encounter a situation where you have a locked device but have lost, forgotten or never knew the passcode.

Using Device Firmware Update (DFU) mode, you can get the device back to a factory state.  This will wipe all of the data on the device, but  from there, you can restore a backup or set it up as a new device.

Here’s the procedure:

  1. Plug the device into a computer that has an iTunes installation.
  2. Launch iTunes.
  3. Press and hold the Power button and the Home button at the same time.
  4. Hold both buttons for 10 seconds
  5. After 10 seconds, release the Power button but continue to hold the Home button.
  6. iTunes will display a dialog stating that it has detected a device in recovery mode, giving you the option to restore the device.

In DFU mode, the device’s screen will remain completely black. If you see the Apple logo, the device has simply rebooted.  Repeat the steps above and be careful with the timing on steps 4 and 5.