Category Archives: Deployment

IOS, Apple Configurator, WiFi association and Failing MDM enrollment

While attempting to manage my first IOS cart, I ran into a catch-22. We were using VPP app distribution, so an MDM server was needed, but when I went through the “Prepare” phase of Apple Configurator, or reset the iPads when they returned to the cart, they would fail to enroll to the MDM.

No MDM, no software install.

Our campus WiFi network utilizes 802.1x authentication, so the Prepare / Reset workflow in Apple Configurator should look like this:

IOS Install -> 802.1x WiFi mobileconfig -> MDM Enrollment profile -> App Install

This was supposed to happen each time an iPad returned to the cart (to return it to a fresh state), but about 70% of the time the iPads would fail to re-enroll to the MDM.

With the help of our crackerjack wireless folk, I was able to track this down to an over-aggressive timeout within Apple Configurator when applying the MDM enrollment profile. It simply would die with the error that the server was unreachable before the WiFi connection had been established. No check-and-retry – just march straight to failure.

After consulting with our Apple SE, and him in turn consulting with an internal IOS deployment specialist, a hidden preference came to the surface:

defaults write com.apple.Configurator EnrollmentProfileInstallationDelay 20

(or some other number of seconds – don’t exceed 120).

This is applied in the user scope, so no “sudo” is needed. I upped mine to 40 seconds, restarted Apple Configurator and tried again with a stopwatch in my hand. It appears that this is a timeout value, because there was no 40 second delay, but it DID allow it to wait longer for the WiFi association to occur, and now my devices appear to associate without issue.

Other admins appear to have worked their way around this by staging the mobileconfig profiles. First pass, apply the WiFi config. Second pass, apply the MDM enrollment. While this works for 1-to-1 deployments, if you have a classroom cart with iPads that need to be wiped upon return it takes a ton of involvement by the admin – you must Unsupervise the devices, then Prepare, and finally apply the MDM enrollment in the Supervise stage each time they have to be wiped.

Increasing the enrollment delay appears to solve this so the staged enrollment technique isn’t necessary.

Setting your Munki ClientID as part of a Deploy Studio workflow.

1) Use the hostname form. Important fields are “Computer Name” and “Computer Information #4”
2) Ensure that you have the “Configure” step set up in the workflow and are applying those fields
3) Install Munki Tools and your generic ManagedInstalls.pref
4) Include this script – execute after restart. The script will first check the “Computer Information #4” field, and if empty will reference the “Computer Name” and set ClientIdentifier in the ManagedInstalls.plist file to that value. If neither is filled in, then it silent exits and touches nothing.

Script is below:

#! /bin/bash

### This script checks for a value in the fourth custom field set by ARD/DeployStudio
### and then the computer name (in the Sharing prefpane).
### If a value exists in the custom field, it sets the Client Identifier in 
### ManagedInstalls.plist to that value, other wise it sets the ClientIdentifier to
### the Computer Name.
### -- Tim Schutt, December 13, 2012  taschutt@syr.edu

SYSCLIENTID=$(scutil --get ComputerName)
CUSTCLIENTID=$(defaults read /Library/Preferences/com.apple.RemoteDesktop Text4)

if [ -n "$CUSTCLIENTID" ]
then
	defaults write /Library/Preferences/ManagedInstalls ClientIdentifier $CUSTCLIENTID
elif [ -n "$SYSCLIENTID" ]
then
	defaults write /Library/Preferences/ManagedInstalls ClientIdentifier $SYSCLIENTID
fi

exit 0

Deploy Studio Script – hide Bootcamp partition from OS X.

Place this in your deploy studio workflow, and defer execution until first boot.

#!/bin/bash

## Script by Tim Schutt, 2012 ##

##########################################################
## find the bootcamp partition MUST BE NAMED "BOOTCAMP" ##
##########################################################

BC=$(diskutil list | grep BOOTCAMP | grep -o 'disk[0-9]s[0-9]';) 

##########################################################
## find the UUID of the previous bootcamp partition.    ##
##########################################################

UUID=$(diskutil info $BC | grep -o '[0-9a-zA-Z]\{8\}-[0-9a-zA-Z]\{4\}-[0-9a-zA-Z]\{4\}-[0-9a-zA-Z]\{4\}-[0-9a-zA-Z]\{12\}';)

##########################################################
## Disable auto-mounting of Bootcamp partition. You can ##
## still mount the partition manually with Disk Utility ##
##########################################################

echo "UUID=$UUID none ntfs ro,noauto 0 0" > /etc/fstab

exit 0

OS X – Allow non-admin users (including Network accounts) to manage printers

There seem to be many ways to skin this cat, many that involve butchering the cups.conf file. It’s always felt a bit like rusty-spoon surgery to me doing it that way.

Today, I found what I feel is a much more elegant way to do it. Simply add “everyone” to the lpadmin group.

Here’s how:
From a sudo-able account, execute the following:

sudo dseditgroup -o edit -a everyone -t group _lpadmin

Now, any user on your system can manage their own printers.

My only queasiness is the concept of “everyone” rather than “Authenticated users”.

Feedback is welcome.

Windows 7 imaging with FOG – how I got it to work (85% of the time)

http://fogproject.org

Tasked with deploying about 90-100 computers this summer (~60 PCs, and 35 Macs), it became clear to me that building each by hand was NOT a valid option. The building where I reside has a 20+ year old network. The simple act of applying Windows updates after the first install was a multi-hour proposition on each system. There was simply no time.

So armed with a basic gigabit switch, a reasonably good PC loaded with Ubuntu, FOG, two network cards, and enough drive space to store the system images, I got started.

I will detail my FOG server configuration in a future post

Almost immediately, I discovered that FOG works like a champ with Windows XP, but not with Windows 7. It was a bumpy ride working the kinks out of this system, but in the end I consider it a considerable success and worth the effort.

NOTE: I had VERY similar hardware for this rollout, so I didn’t have to generalize the installation / get into sysprep. I ran out of time this summer, but plan on tackling that in the coming months.

Here is the distilled process I settled on:

  • Install Win 7  – update update update.
  • Disable hibernation (open a CMD window -> “powercfg -h off”)
  • Install Office. Third party software beyond this was causing issues for me, so I limited the image to Office only. Update update update.
  • Browse to [yourFOGserver]/client – download FOG Client Service and Fogprep. Install FOG service and point it at your server.
  • Turn off Virtual Memory (Computer -> Properties -> Advanced System Settings -> Performance “Settings…” -> Advanced -> Virtual Memory “Change…” -> uncheck “Automatically manage…”)
  • Defrag the hard drive – I used Defraggler http://www.piriform.com/defraggler
  • Shrink the NTFS partition (Computer -> Manage -> Disk Management -> Rt. click on partition -> Shrink Volume). When prompted for the new volume size, add 2GB to it. You will appreciate this breathing room.
  • run fogprep as admin and immediately shut the system down. If you boot from this volume before capturing the image, you will need to run fogprep again.
  • On your FOG server: create a new image – Multi partition single disk, non-resizable.
  • PXE boot your client – select “full system inventory…” option. It’s a Windows 7 system and assign it to the image you just created. DO NOT IMAGE IT YET. Shut it down.
  • On your FOG server – select the machine from inventory, click on “Basic Tasks” and upload the image.
  • Restart your client machine, PXE boot – it will automatically grab the image from the hard drive.

Now, you should have a working template image that can be deployed to similar hardware.

When you deploy this to a new system, PXE boot the system to the FOG menu, inventory the machine and assign it to that image. Then choose to image the system immediately. It will restart (you may need to tell it once again to boot from the network) and pull the image down to the system.

Once the new system has the image, then simply expand the NTFS partition and re-enable virtual memory. In that order. I typically leave hibernation disabled.