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


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" "">
<plist version="1.0">
     <key>4x6 Borderless</key>
          <string>4x6 Borderless</string>
          <string>4x6 Borderless</string>
          <string> </string>

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, 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" "">
<plist version="1.0">
     <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>
          <string>__APPNAME__ is trying to set the DVD region code for the first time.</string>

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" "">
<plist version="1.0">

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:

 #: 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.

Setting A Default Paper Size

printerThis post is in response to a reader request.

In Mac OS X, the default paper size is a setting that determines the size of paper that applications will try to print to unless the user chooses otherwise. For most systems and applications this defaults to US Letter.  In order to provide a positive user experience, especially for end users outside of the United States, it may be desirable to set a different default paper size.

The file that contains this preference is:

This makes the preference domain:

The Key that governs the preference is called : DefaultPaperID

DefaultPaperID contains a string value that corresponds to a paper size. See the chart below:

Paper Size String
US Legal na-legal
US Letter na-letter
A4 iso-a4
A5 iso-a5
JIS B5 jis-b5
B5 iso-b5
Envelope #10 na-number-10-envelope
Envelope DL iso-designated-long-envelope
Tabloid tabloid
A3 iso-a3
Tabloid Oversize arch-b
ROC 16K roc16k
Envelope Choukei 3 cho-3-envelope
Super B/A3 arch-b-extra

To set this preference with a script use the command below, replacing with the correct string for the intended paper size.

For a single user, run as the user:
defaults write ~/Library/Preferences/ DefaultPaperID

For all users, run as root:
defaults write /Library/Preferences/ DefaultPaperID

This process has been tested on Mac OS X v10.6 (Snow Leopard), v10.7 (Lion) and v10.8 (Mountain Lion).

I hope you find this useful.

Lock It Down

securityIn the previous article, we discussed the consumerized model of IT.  Now let’s have a look at a locked down model, and some guidelines that will help maintain sanity both for the IT group and the user community at large.

Why Lock Down?

After considering the consumerized model, one might think that it sounds so progressive & cost effective that no one should bother locking down computers any more.  Well, no solution is one-size-fits-all.  If there is an existing user community accustomed to a certain level of support and management, or if there are legal requirements to satisfy, we can’t simply board up the help desk and redirect the support line to the nearest Genius Bar.

By far, I see legal requirements as the most common and important reason to maintain a locked-down environment.  Legislation such as SOX & HIPAA, and standards such as PCI all place limits on how certain computer systems are allowed to operate.

In some organizations, it may be important to remove distractions and potential wrong turns in workflows.  There are still plenty of computer illiterate people in the workforce.  If these folks dominate an organization, it may be wise to limit the damage they can do through a series of electronically-enforced policies and restrictions.

No Admins

When implementing a locked-down model, I believe in one cardinal rule: In a locked-down environment no user outside the IT team should have administrative privileges.

If  this rule is broken, the environment is no longer locked down.  Administrative privileges are the keys to the proverbial kingdom.  A user with administrative privileges can change or remove any or all enforced settings, add or remove software as they see fit, and disable reporting to any inventory or compliance systems.  In short, IT cannot maintain any sort of Support Level Agreements or ensure compliance if the users have administrative privileges.

Even within the IT team, administrative privileges should be used only when necessary, meaning that IT staffers should be using non-admin accounts to do their routine work but have the means to elevate their access when needed and within carefully considered limits to balance security, accountability and efficiency.  An IT team that operates with administrative rights will usually have no idea of the issues faced by the typical non-admin user.  In addition, IT staffers are people too, and as such are prone to mistakes and bad judgement just like the rest of us.  Detailed and strict processes help to mitigate human error.

IT departments often face political pressure or directives from superiors to make exceptions to a “no-admins” policy.  If you find yourself in this position, I recommend preparing a cost-benefit analysis for your superior(s).  This report should include things like  data loss, lost productivity, support costs, and the costs of lost opportunities.  I have always felt that it is part of the job of an IT staff to let management and the business know when they’re trying to do something detrimental.  It is more desirable and generally less costly to prevent problems than fix them after the fact.  When an employer asks for something dumb, it’s a good idea to tell them it’s dumb and why it’s dumb in a quantifiable (and tactful) fashion.  If they still insist on the dumb thing, they can’t blame you for not doing your due diligence and informing them of the pitfalls.

When Not To Lock Down: Social Issues

Technology is often called upon to solve social issues.  I see this as a waste of time and resources as well as an unnecessary restriction of user capabilities.  Rather than limit everyone for fear that someone may misbehave, I feel it is much more productive to only punish the miscreant if misbehavior occurs.  There are many reasons to lock down computers and their functions, but in this sysadmin’s opinion, solving social issues should never be one of them.

Another Mac sysadmin once said “you can’t teach a backpack not to carry a Playboy” in response to a request to ensure that “naughty pictures” couldn’t appear on a school’s computers.  If little Bobby is caught with a Playboy in his backpack, it is confiscated, he’s sent to the principal’s office and Bobby is given the prescribed punishment, all because Bobby has misbehaved.  If however, Bobby accesses similar material in a computer lab, the IT staff ends up taking much of the blame because it happened on a computer, even though it’s still Bobby that misbehaved.  Misbehavior is still misbehavior whether it involves a computer or not.  If little Bobby is looking at naughty pictures in school, that is a disciplinary issue to dealt with accordingly.  Similarly, if Sally in accounting is playing solitaire all day and not doing her work, then Sally’s boss needs to have a chat with her and/or start looking for a new Sally. Technology is a moving target and users, especially children, are very resourceful and have nothing but time on their hands.  An IT staff that tries to manage social issues with technology will find themselves fighting a battle that is impossible to win.

Only Lock What Is Necessary

Heavy handed restrictions are the most likely to be circumvented.  I have been to offices where end users have very expensive company-supplied computers on their desks but never use them because they find the draconian restrictions imposed by an overzealous IT staff make the systems unusable.  These employees end up bringing their own laptops to work, thus creating a de-facto Bring-Your-Own model that the IT group has absolutely no control over, and often no knowledge of.

Each restriction that is not legally or contractually mandated should be carefully examined to determine if it is actually necessary.  What risks are being mitigated, and what are the potential impacts on user productivity?  Does the potential risk outweigh lost productivity and/or user dissatisfaction?  Unless the answer to that last question is yes, the restriction shouldn’t be implemented.

I hope these ideas will help make your restrictions more sensible and useful.

Consumerized IT or Bring Your Own


On any given day, I’m likely to have some form of conversation that includes a discussion of why no one should have administrative privileges, or why everyone should have them and IT shouldn’t care.  To paraphrase Mr. Kenobi, both arguments are correct, from a certain point of view.

The core of the issue comes down to determining what is most important to an organization.  Some organizations need extreme control and security.  In these organizations, having computers and devices locked down and only capable of performing approved tasks is required, often by law.  Many other organizations may not be bound by these laws or have as great a need for security and may instead place greater value on creative freedom and the flexibility to be productive according to an individual’s own work habits and quirks.  Since the locked-down model has been the IT standard for decades, we’ll leave that topic alone for now and instead discuss some of the ideas behind a consumerized model.

What Is Consumerization

The consumerization of IT is a topic that is in relative infancy, but rapidly growing, sort of like “cloud computing” was just a short few years ago.  Being a young and evolving concept, it’s not uncommon to to find varying definitions, and what follows is my own working definition as of December 2011.

“The Consumerization of IT” describes a trend where organizations expect employees to own a computer, be able to use said computer, and be able to obtain service and support for that computer.

Similar to the fact that most employers expect their employees to own and maintain phones and the means to get to work, a company following a consumerized IT model expects employees to own and maintain a computer.  These organizations may give employees a stipend to purchase the computer or may even provide a computer, but offer little to no support for the device or common commercial software.  This approach is often referred to as a bring-your-own or “BYO” model.

The primary goals of IT in a BYO scenario are to provide access to proprietary data and software tools that the user community needs to accomplish the organization’s goals rather than duplicating the support efforts of Apple, Microsoft, et al.  Schools worry about the educational process and a bread company worries about making and selling bread.  Both leave the business of Mac OS X support to Apple, Word support to Microsoft and Photoshop support to Adobe.

Why It Works

At the dawn of IT, we had to cope with baby boomers who grew up with slide rules and musty encyclopedias.  These people needed legions of helpers to translate the digital voodoo that would allow them to do their jobs.  Baby boomers are now retiring in droves.  Their children and grandchildren don’t need the same kind of handholding.

Also consider the fact that the young people who have entered the workforce in the past several years, and will be entering it going forward, have grown up with computers almost since birth.  These people came through school using the Internet, word processors and cellular phones.  Children born on the day the Internet was opened to commercial activity have bachelor’s degrees now.  These young adults may have been using an iPhone for as long as or even longer than their employers.  Aside from having a level of competence with technology, and perhaps because of it, these employees are more likely to chafe against a tightly locked system.

Some Management

Whether it’s software distribution, managing compliance with legal guidelines, providing critical software patches, or configuring an email account, even organizations that have consumerized IT will benefit from some degree of client management.

Since the end user will be in ultimate control of the computer, it is important to have clear communication between IT and the user regarding the management tools used and what is expected of each party.  A balance must be struck between the privacy needs of the employee and the security needs of the employer, and the stipulations of that balance should be well understood by both parties.

How It Works

Since the end user has administrative privileges, common IT terms like “push” and “lock” don’t apply.  To have effective management, we need to link compliance with desired and/or required items.  Examples might include automatically locking out a user’s directory service account if their computer doesn’t comply with security requirements or removing network access and/or email configurations if the device fails to meet other agreed-upon management requirements.  In this way, we are able to give the end user the tools they need, but only when they agree to and comply with the organization’s policies and requirements.

Software installations and even many management tasks may be delivered by a client-driven mechanism, such as The Casper Suite’s Self Service tool or similar mechanisms; although there will likely be some settings such as those discussed above that will be enforced as a mandatory requirement of participating in the BYO program.

It is important to design the systems and processes involved to be as simple, user friendly and foolproof as possible.  While today’s end users tend to be more savvy than their predecessors, not everyone is a technology nerd, and shouldn’t be expected to be one.  Apple users in particular expect things to “just work.”  Maintaining that same high level of usability should be a requirement of any BYO project.  If something can be done in two clicks, don’t make the user do it in three.  Make sure interfaces are labeled well and consistently.  Finally, always use the system yourself.  You can’t relate to your users’ frustrations very well if you never use the systems they use.  If you find yourself not wanting to use a system, that’s a great indication that the system needs work.

I hope this overview proves useful.  We may explore these concepts further in future articles if there is significant response.