Tiny Deathstars of Foulness

The NetBoot service allows administrators of Apple computers to leverage images hosted on a server to boot computers to a central location and put a new image on them, upgrade them and perform automations based on upgrades and images. Since the very first versions of OS X, the service has been called NetBoot and so the name remains at the command line, but is listed as NetInstall in the Server app. In the Server app, Apple provides a number of options surrounding the NetInstall service, based on Automator-style which we’ll explore further in this article.

The first step to configuring the NetInstall service is to decide what you want the service to do. There are three options available in System Image Utility (available under the Tools menu of the Server app in OS X Server):

  • Create a NetBoot Image: Allows Macs to boot over the network to a disk image hosted on a server.
  • Create a NetInstall Image: Leverage NetBoot as a boot disk so that an image hosted on a server can be used to run a macOS installer.
  • Create a NetRestore Image: Leverage NetBoot as a boot disk so that you can restore a computer that has been configured over a network. Use this option to restore an image that has been prepared.

For the purposes of this example, we’re going to use a macOS Sierra (10.12) installer running Server 5.2 to boot a Mac over the network. The first step in doing so is to create a Network Disk Image (in this case 10.12), or the 10.9 installation media (which is the Install macOS Sierra bundle for this example). Before setting it up, download the Install macOS Sierra installer app into the /Applications directory from the App Store.

Create An Image

To then set up the NetBoot disk image (you can’t start the NetInstall service until you give it an image to serve), often referred to as the NetBoot set, open the Server app and then click on System Image Utility from the Tools menu of OS X.

When System Image Utility opens, click on the Install macOS Sierra entry in the list of available sources and click Next.


Then, in the list of options, click on NetBoot Image and then click on the Next button.


At the License Agreement screen, click Agree.


Then provide an account name, short name and password in the Image Settings screen. Also choose the language of the user and select if you want the account to log in automatically. Once provided, click Next.

Next, select any profiles, packages or post-install scripts to run on the NetBoot image once created. Here, you can use a profile to deploy a printer, bind to Active Directory, or use a package to install software. Post-install scripts allow you to do pretty much anything you’d like to a system, provided it’s allowed by SIP.


At the System Configuration screen, choose how you’d like systems to receive names. Here, you can provide a name as a base for computers to get a computer name or you can use a file to deploy names. In most cases, you should also check the box for “Match to client after install.” Click Next once you’ve selected how this should occur.


At the Directory Servers screen, click on the plus sign if you’d like to bind the system to a particular directory server.


In this example, we’re binding to Also provide an account with access to bind to where you’re binding. In this case, we’re using the built-in admin account for Active Directory. Click Add once you’ve provided the appropriate directory server and credentials.


At the Image Settings screen, provide a name for the image, as well as how the index number for the image is created. Note that each image should have a unique image index, so unless you’re storing your image on multiple servers, it’s best left at the defaults. Click Next.


At the Supported Computer Models screen, you can choose which models of computer you don’t wish to support for this image. We’re not doing that here, but it’s useful, for example, if you’d like to preclude desktops from an image.


At the Filter Clients By MAC Address, you can choose to explicitly allow or deny given MAC addresses for computers. We’re not going to do that as part of this workflow, so just click Next (unless of course you’d like to do that).

Then, when prompted, select a location to store the Disk Image, provide any tags to be applied to the files that comprise the image and click on Save.

The computer will then start creating the NetBoot set.

Setup The NetInstall Service

Once finished, it’s time to set up the NetInstall service in macOS Server. To get started, go back to the Server app.

First, define which disk will host NetBoot Images. To do so, click on the Edit Storage Settings button. At the Storage Settings overlay, select the volume that Images will be hosted as well as the volume that Client Data will be hosted. The Image is what you are creating and the Client Data is dynamic data stored in images.

If you only have one disk, as in this example, click on “Images & Client Data” for that disk. Then click on the OK button. Once you’ve selected a disk to store your image, we need to copy the disk image into the Library/NetBoot/NetBootSP0 folder of the disk used for images.


Once in the appropriate folder, click on the Edit button for Network Interfaces and select the appropriate network interface you wish to serve images over, and click OK. Refresh the Server app (Command-R) and provided the image was created and moved into the /Library/NetBoot/NetBootSP0 directory of a volume set to host images, the image will appear in the images list, with a green indicator light.


The green indicator light means the image is being served over the network. Double-click on an image.

At the image settings screen, you can select NFS over the default HTTP protocol for “Make available over”.Note, you can also restrict access to the image to certain models of Apple computers and/or certain MAC addresses by using the “Image is visible to” and “Restrict access to this images” options respectively. Additionally, use the Make this image available for diskless booting option to allow computers without hard drives to boot to the image.


Click on the OK button. Click on the image and then click on the cog-wheel icon. Click on “Use as Default Boot Image” to set an image to be the default images computers boot to when booting to NetBoot. Now, it’s as easy as clicking on the ON button. Do so to start the service.

Once started, open a Terminal window. Here, let’s get a status of the service using the serveradmin fullstatus option (along with the service name, which is still netboot from the command line):

sudo serveradmin fullstatus netboot

The output of which shows the various components, logs and states of components:

netboot:state = "RUNNING"
netboot:stateTFTP = "RUNNING"
netboot:readWriteSettingsVersion = 1
netboot:netBootConnectionsArray = _empty_array
netboot:logPaths:netBootLog = "/var/log/system.log"
netboot:dhcpLeasesArray = _empty_array
netboot:stateDHCP = "STOPPED"
netboot:stateHTTP = "RUNNING"
netboot:serviceCanStart = 1
netboot:timeOfSnapshot = "2016-09-27 02:07:32 +0000"
netboot:stateNFS = "STOPPED"
netboot:stateImageArray:_array_index:0:_array_index:0 = 1
netboot:stateImageArray:_array_index:0:_array_index:1 = 0
netboot:stateImageArray:_array_index:0:_array_index:2 = 0
netboot:stateImageArray:_array_index:0:_array_index:3 = 1
netboot:stateImageArray:_array_index:0:_array_index:4 = 2
netboot:stateImageArray:_array_index:1:_array_index:0 = 0
netboot:stateImageArray:_array_index:1:_array_index:1 = 0
netboot:stateImageArray:_array_index:1:_array_index:2 = 0
netboot:stateImageArray:_array_index:1:_array_index:3 = 0
netboot:stateImageArray:_array_index:1:_array_index:4 = 2
netboot:stateImageArray:_array_index:2:_array_index:0 = 0
netboot:stateImageArray:_array_index:2:_array_index:1 = 0
netboot:stateImageArray:_array_index:2:_array_index:2 = 0
netboot:stateImageArray:_array_index:2:_array_index:3 = 0
netboot:stateImageArray:_array_index:2:_array_index:4 = 2
netboot:stateImageArray:_array_index:3:_array_index:0 = 0
netboot:stateImageArray:_array_index:3:_array_index:1 = 0
netboot:stateImageArray:_array_index:3:_array_index:2 = 0
netboot:stateImageArray:_array_index:3:_array_index:3 = 0
netboot:stateImageArray:_array_index:3:_array_index:4 = 2
netboot:servicePortsRestrictionInfo = _empty_array
netboot:netBootClientsArray = _empty_array
netboot:servicePortsAreRestricted = "NO"
netboot:setStateVersion = 1
netboot:startedTime = "2016-09-27 02:06:53 +0000"
netboot:stateAFP = "STOPPED"

And to start the service when not running:

sudo serveradmin start netboot

There are also a number of settings available at the command line that are not in the graphical interface. For example, to allow writing to the NetBoot share:

sudo serveradmin settings netboot:netBootStorageRecordsArray:_array_index:0:readOnlyShare = no

Or to get more verbose logs:

sudo serveradmin settings netboot:logging_level = "HIGH"

To stop the service:

sudo serveradmin stop netboot

In the beginning of this article, I mentioned that ways to configure NetInstall images. I’ll cover NetInstall and NetRestore in later articles as they tend to be more involved workflow-wise than copying a volume into a Network Disk Image. But to end this one, many an old-school admin might wonder where all the settings went that used to be in the GUI. Well, serveradmin still maintains a lot of the older stuff. To see a list of all available settings, run serveradmin with the settings verb and then netboot:

sudo serveradmin settings netboot

If there was a feature you want to use (e.g. maximum users), you should see it in the resultant list:

netboot:netBootFiltersRecordsArray = _empty_array
netboot:netBootStorageRecordsArray:_array_index:0:sharepoint = yes
netboot:netBootStorageRecordsArray:_array_index:0:clients = yes
netboot:netBootStorageRecordsArray:_array_index:0:volType = "hfs"
netboot:netBootStorageRecordsArray:_array_index:0:okToDeleteSharepoint = no
netboot:netBootStorageRecordsArray:_array_index:0:readOnlyShare = no
netboot:netBootStorageRecordsArray:_array_index:0:path = "/"
netboot:netBootStorageRecordsArray:_array_index:0:okToDeleteClients = yes
netboot:netBootStorageRecordsArray:_array_index:0:volName = "Macintosh HD"
netboot:netBootPortsRecordsArray:_array_index:0:deviceAtIndex = "en5"
netboot:netBootPortsRecordsArray:_array_index:0:nameAtIndex = "USB 10/100/1000 LAN"
netboot:netBootPortsRecordsArray:_array_index:0:isEnabledAtIndex = yes
netboot:logging_level = "MEDIUM"
netboot:filterEnabled = no
netboot:netBootImagesRecordsArray:_array_index:0:RootPath = "NetBoot.dmg"
netboot:netBootImagesRecordsArray:_array_index:0:IsInstall = no
netboot:netBootImagesRecordsArray:_array_index:0:Kind = "1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:0 = "MacBookAir6,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:1 = "MacBookAir5,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:2 = "MacBookAir7,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:3 = "MacBookAir2,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:4 = "MacBookAir5,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:5 = "MacBookAir4,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:6 = "MacBookAir4,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:7 = "MacBookAir6,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:8 = "MacBookAir7,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:9 = "MacBookAir3,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:10 = "MacBookAir3,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:11 = "MacBookPro5,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:12 = "MacBookPro9,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:13 = "MacBookPro6,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:14 = "MacBookPro6,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:15 = "MacBookPro8,3"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:16 = "MacBookPro11,3"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:17 = "MacBookPro7,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:18 = "MacBookPro11,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:19 = "MacBookPro10,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:20 = "MacBookPro12,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:21 = "MacBookPro11,4"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:22 = "MacBookPro11,5"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:23 = "MacBookPro3,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:24 = "MacBookPro4,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:25 = "MacBookPro8,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:26 = "MacBookPro10,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:27 = "MacBookPro5,3"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:28 = "MacBookPro5,5"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:29 = "MacBookPro5,4"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:30 = "MacBookPro5,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:31 = "MacBookPro9,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:32 = "MacBookPro11,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:33 = "MacBookPro8,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:34 = "iMac14,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:35 = "iMac9,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:36 = "iMac7,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:37 = "iMac12,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:38 = "iMac11,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:39 = "iMac14,4"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:40 = "iMac11,3"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:41 = "iMac13,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:42 = "iMac15,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:43 = "iMac12,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:44 = "iMac8,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:45 = "iMac10,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:46 = "iMac13,3"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:47 = "iMac14,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:48 = "iMac14,3"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:49 = "iMac13,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:50 = "iMac11,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:51 = "Macmini5,3"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:52 = "Macmini5,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:53 = "Macmini4,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:54 = "Macmini5,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:55 = "Macmini3,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:56 = "Macmini6,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:57 = "Macmini6,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:58 = "Macmini7,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:59 = "MacBook8,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:60 = "MacBook7,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:61 = "MacBook5,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:62 = "MacBook6,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:63 = "MacBook5,2"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:64 = "MacPro3,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:65 = "MacPro5,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:66 = "MacPro4,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:67 = "MacPro6,1"
netboot:netBootImagesRecordsArray:_array_index:0:DisabledSystemIdentifiers:_array_index:68 = "Xserve3,1"
netboot:netBootImagesRecordsArray:_array_index:0:Description = "NetBoot of OS X 10.11 (15A178w) Install (9.12 GB)."
netboot:netBootImagesRecordsArray:_array_index:0:Name = "NetBoot of Install OS X 10.11 El Capitan"
netboot:netBootImagesRecordsArray:_array_index:0:imageType = "netboot"
netboot:netBootImagesRecordsArray:_array_index:0:Index = 3089
netboot:netBootImagesRecordsArray:_array_index:0:osVersion = "10.11"
netboot:netBootImagesRecordsArray:_array_index:0:BackwardCompatible = no
netboot:netBootImagesRecordsArray:_array_index:0:SupportsDiskless = no
netboot:netBootImagesRecordsArray:_array_index:0:EnabledSystemIdentifiers = _empty_array
netboot:netBootImagesRecordsArray:_array_index:0:Language = "Default"
netboot:netBootImagesRecordsArray:_array_index:0:BootFile = "booter"
netboot:netBootImagesRecordsArray:_array_index:0:IsDefault = no
netboot:netBootImagesRecordsArray:_array_index:0:Type = "HTTP"
netboot:netBootImagesRecordsArray:_array_index:0:Architectures = "4"
netboot:netBootImagesRecordsArray:_array_index:0:IsEnabled = yes
netboot:netBootImagesRecordsArray:_array_index:0:pathToImage = "/Library/NetBoot/NetBootSP0/NetBoot of Install macOS 10.12 Sierra.nbi/NBImageInfo.plist"
netboot:afpUsersMax = "50"

Boot to Your NetBoot Image

Next, you’ll want to have a computer boot to the NetBoot image you just created. Once upon a time, you would use the bless command to select a path to an image that you wanted to boot to in order to do so. Or you’d just boot holding down the N key and let the system pick an image. As of OS X 10.11, due to SIP restrictions, you’ll use the csrutil command to set a NetBoot address, continuing into macOS 10.12. To do so, run csrutil followed by the netboot option and then the add verb, followed by an address. In the following example, we’ll set the system to boot to the NetBoot server at

csrutil netboot add

Once you’ve finished any NetBoot workflows, use the remove verb to remove that address:

csrutil netboot remove

And to list any available NetBoot servers, use the list verb:

csrutil netboot list

Overall, all of this usually takes me a good 10 minutes of work, plus maybe up to half an hour of waiting for an image to create. You can use NetBoot to remotely boot systems, or NetInstall to remotely install systems. There are lots of articles out there (including here) on how to make sure clients can access these images over a network client, so I won’t rehash.

October 19th, 2016

Posted In: Mac OS X Server

Tags: , , , , , ,

Leave a Comment

April 26th, 2016

Posted In: Apple TV, iPhone, Mac OS X, Mac OS X Server, Mac Security, MacAdmins Podcast

Tags: , , , , , , ,

I love answering a question with a question. Is asr still in OS X? Is NetInstall still in OS X Server? Can OS X still NetBoot? Does System Image Utility still work? The answer to all of these is yes. Therefore, the answer to “Is imaging dead” is clearly no. Is it on its way out, maybe. Debatable. Is it changing? Of course. When does Apple not evolve?

What have we seen recently? Well, the rhetoric would point to the fact that imaging is dying. That seems clear. And this is slowly coming out of people at Apple. The word imaging is becoming a bad thing. But, as a customer recently asked me, “what do you do when a hard drive fails and you need to get a system back up”? My answer, which of course was another question was “what do you do when that happens with an iPad?” The answer is that you Restore.

What is the difference between an Image and a Restore? Yes, I meant to capitalize both. Yes, I realize that’s not grammatically correct. No, I don’t care. It’s my prose, back off. But back to the point. What is the difference between the two? Am Image can have things inserted into /Applications, /Library, and even /System (since it’s not booted, it’s not yet protected by SIP). An Image can have binaries and scripts automatically fire, that Apple didn’t bake into the factory OS. On an iPad, when you Restore, you explode an .ipsw file onto disk that can’t be altered and acts as an operating system.

The difference here is that one is altered, the other isn’t. Additionally, iOS ripsaw files only contain drivers for the specific hardware for a given device (e.g. one for iPad Mini and another for iPhone 6). But, you have pre-flight and post-flight tasks you need to perform. Everyone understands that. Think about automation via profiles. You can run a script with a profile. You can apply a profile at first boot. You can install a package (the future of packages is IMHO more debatable than the future of images) and a .app with a profile. These might take a little more work than it does with a NetInstall and System Image Utility. But then, it might not. You’d be surprised what’s easier and what’s actually harder (for now) with this new workflow. Complexities are more logistical than technical.

So, Imaging is dead, long live Restoring? Arguably, any older workflows you have will be fine for some time. So any good article has a call to action somewhere. The call to action here is to try to subtly shift your deployment techniques. This involves implementing a DEP strategy where possible. This involves putting the final nails in the coffin of monolithic imaging. This involves moving to as thin an image as possible. This involves (I can’t believe I’m saying this) de-emphasizing scripting in your deployment process. This also involves completing the move that you’ve hopefully started already, from MCX to profile or mdm-based management.

What else do you think this involves? Insert running commentary below!

December 5th, 2015

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , ,

In case you were there and would like a copy, here’s the slides from the presentation I did this week at the JAMF Nation User Conference 2012. If you weren’t there, then perhaps they will help you in some way.


The session was recorded so I’ll try and post when it becomes available for download.

October 26th, 2012

Posted In: Mac OS X, Mac OS X Server, Mass Deployment

Tags: , , , , , , , , , , ,

According to Wikipedia, fsevents is an API from Apple that allows applications to register for notifications of changes to a given directory tree. This means that when something changes, an application (or daemon/agent) can see the change and take action or track what happened. For Linux, there’s a similar tool in iNotify.

This time of the year, a lot of imaging and packaging is going on at schools and companies around the world. A lot of people are also moving various settings out of images and into either post-flight packages, automations or managed preferences of some sort. In OS X, it’s easy to make a change on a computer and then isolate what files the change touched. Therefore, you can quickly and easily figure out what changes to make (e.g. to a property list via a management profile if you’re getting away from Managed Preferences or even to a configuration file).

One tool that can help you discover what files were changed on a system is fseventer. This small donateware app is easy to use and quickly informative. To use it, just open and click on the play button at the empty screen.

Once the tool starts running it will show you what’s changing in the background on the computer. Now make the changes that you need to make and click on the pause button.

Click on the middle button beside the play/pause button and you’ll also

Looking at the files changed then tells you what the changes are. Toggling changes back and forth and looking at the impact on the file results in knowing the changes to script/automate/profile manage for each.

You will encounter tons of apps that write generated keys here and there rather than easy to find settings such as what you see above. In those cases there are almost always command line interfaces specifically developed for changing a setting. For example, networksetup should be used to change settings that would otherwise be configured in the Network System Preference pane. This is only one of about 1,000,000,000 ways I’ve seen to do this. Happy to invite others to comment on their favorite way to track what’s changing and script it in OS X and other platforms as well.

July 12th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , , , ,

Imaging can be a complicated task. Many imaging environments have a lot of scripts, packages, base images and other aspects of automation. The more of these that you have, the more potential combinations you have for the state of a system once they’ve been run. This gets complicated when you want to make sure that each possible combination of images will have a consistent result when installed. For example, take something simple, like a property list. Each possible combination of packages, scripts images and even managed preferences might have a different impact on that poor property list.

A simple defaults command can often give administrators the ability to see what settings have been applied to a system. For simple tasks that can be programatically trapped for, this might be enough. You can argue that everything can be programatically discovered, but I would argue that is an immature way to look at such things. The example I used in the Enterprise Mac Administrator’s Guide was looking at Microsoft Word. Let’s say that you install 24 fonts. When you open Word, you end up needing to check and make sure that each font loads. You can verify fonts test clean, but you can’t verify that they show up in Word. Microsoft gives you the ability to list fonts that appear in the font menu programatically. But you would literally need to open Word and look in the fonts menu on each regression of each system image in order to tell if the fonts actually appear in the list and if so, whether they look right. One small example. In many environments, each application will have 10 or more tests, with a lot of applications potentially being deployed – and the list grows as failures are discovered year over year…

Now let’s say you’ve got 80 packages in your self service library. At this point, in order to tell that every combination is cool, you’d need to manually open Word on a lot of image combinations in order to verify that your fonts load properly. EggPlant is a tool that enables administrators to run a script that clicks on things for us and reports back on what happens when we do. Now, AppleScript can do some of this as well. But eggPlant gets very in depth in terms of scripting logic and is cross platform. EggPlant leverages a Vine server that gets installed on clients. Screen shots are then taken through a Vine client and compared to screen shots you make and save in eggPlant to compare to the ones that are captured from Vine. That’s a bit of overs implication, but at the end of the day, bolt some simple scripting on top of that and you’ve got a pretty advanced solution. EggPlant now also supports iOS by jail breaking devices to load the Vine server.

EggPlant is one of the best tools for this kind of thing for the Mac platform. It’s more popular amongst those who do a lot of web testing, but it shoehorns nicely into post-flight imaging regression testing. I had a good conversation with @tvsutton at the Penn State Mac Admins conference about eggPlant and he mentioned a tool called Sikuli that I hadn’t used before, so hat tip to him for the rest of this article. While eggPlant has way more logic in it, for simple regression testing, you can leverage Sikuki in its place, which wouldn’t cause some of the potential conflicts that running a localized Vine server might cause on client systems.

Sikuli is a simple tool that allows administrators to script graphical events. You can effectively automate anything you see on a screen using the same type of screen shots; however, with Sikuli, you dump the screen shots directly into the script via the scripting interface, known as the Sikuli IDE.

The first step to using Sikuli is to download the IDE from their site and run the installer. Once installed, open Sikuli.

The options along the left side are some common commands that can be run, in serial from top to bottom. Not all of the possible methods are exposed in the GUI sidebars, but many of the more common ones are. Let’s go ahead and manually enter switchApp followed by an application you’d like to open with your script. In my example, I’m going to use


While the command says switchApp, it might as well say openApp, as the application will open when you run the command. Go ahead and see for yourself (assuming you have a Lion Server and can therefore open Now, let’s look at some graphical interfacing, go ahead and click on click in the sidebar, which will dim the screen and bring up crosshairs for taking a screenshot. Here, select some part of the screen. I’m using Users for my example:

Once you take the screenshot, it should appear in the parenthesis after click. Next, we’re going to send a screenshot command to the computer itself. To do so, we’re going to use the type command, which conveniently types content into the screen. You can also use this for dialog boxes and other such things, but we’re going to just use it to send a screenshot command to the server. To do so, we’re going to tell it to type the 3 key, along with KeyModifier.SHIFT and KeyModifier.CMD:

type("3", KeyModifier.SHIFT + KeyModifier.CMD)

Now your screen will look something like this:

Running the workflow should result in a screenshot on your desktop, of the users on the system. Next, let’s just repeat this process by clicking on all the screens, grabbing a little screenshot of each and producing results on the desktop. All we’re going to do is cut/copy/paste the actual commands and then loop through each of the services and screens in Server Admin until we’ve gotten a screenshot of each:

Now is when things can start getting a little more interesting. We could have done everything we did up to now using Automator. But Sikuli has some built in logic. Here, we’re going to use the wait option in the Find section of the sidebar to go ahead and wait each screen that can be latent to show content. After we click the services, we’ll wait for a pattern on the screen not specific to any given system but that only appears when the settings appear, as follows:

This is a basic configuration of Sikuli, with a simple task, take some screenshots of the Server application. It can then be anchored to an imaging workflow by invoking the workflow from the command line. The command line is just a shell script sitting in the Sikuli-IDE, which is by default dropped into Applications. Because you won’t need it for standard systems, you can use it in special regression testing workflows from your imaging solution. Save the workflow you’ve been running as some title (I’ll use ServerApp) with the .sikuli extension. Then, to run it from the command line, fire up sikuli along with the actual project and a -r operator to tell it to run:

/Applications/ ~/Desktop/ServerApp.sikuli -r

You can also use the sikuli-ide.jar or sikuli-script.jar to get an even lighter install, documented at on the site. On that page, it also explains how to pass arguments to Jython’s sys.argv using the –args option as well as using -stderr. The scripting environment from there becomes jython, a mashup language that takes python and java and uses a little duct tape to hold them together. Overall, it’s an interesting concept. There isn’t a lot of logic, unless you’re willing to script things. But if you are willing to script things then you can do pretty much anything you might want. For example, you can have it play bejeweled for you, so you can actually get some work done (although perhaps you’d rather play bejeweled and script your meetings…):

May 17th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , ,

Lion comes with this nifty option called AirDrop, which allows users to share files directly. In many environments, this represents a perceived security risk (whether real or not) and must be disabled. To disable AirDrop:

defaults write DisableAirDrop -boolean YES

To turn it back on:

defaults write DisableAirDrop -boolean NO

This is done per-user and so can also be done via Managed Preferences, profiles and/or at imaging time.

September 10th, 2011

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , ,

LANDesk stores its data files in the /Library/Application Support/LANDesk/data directory. However, there is a uuid file for LANDesk that, if you put the LANDesk client in your image will need to be deleted. The uuid is in the /Library/Preferences/com.landesk.uuid.plist property list. If you rm this file as a postflight imaging task then your client can be deployed on your image:

rm /Library/Preferences/com.landesk.uuid.plist

August 20th, 2010

Posted In: Mac OS X, Mass Deployment

Tags: , , ,

Recently I did a little article on importing computers into DeployStudio lists. I got an overwhelming number of email requests to go a step further and look at importing computers into DeployStudio from the command line. I’m guessing lots of people want to bolt some middleware onto their mass deployment tools (can’t say I blame ’em).

The first thing to know is that DeployStudio stores most everything in standard property lists. This includes workflows, computer groups and computers. When you install DeployStudio you selected a location to place your database. For the purpose of this example, we’re going to use /DSDatabase as our location. Within this directory is a folder called Databases. In this folder you’ll see ByHost, which stores each computer in a property list that is the computers MAC address followed by .plist. For example, if my computer has a MAC address of 00254bcc76fa then 00254bcc76fa.plist would be the file that houses information about my computer in DeployStudio. In the ByHost folder is an additional property list called group.settings.plist. In here is the information about the computer groups that you have created. In the Databases folder there is also a directory called Workflows, which houses all of your workflows. These can be seen in the example folder structure here.
When DeployStudio is started, it dynamically loads the items from the property lists to compile its database. You can add additional property lists easily, but when you do you will need to restart DeployStudio each time (or each batch).

There are a number of keys in the property lists, with many of which mirroring data that can be imported using the DSImporter.csv template in my previous article. These include:

  • dstudio-auto-disable: Used to disable the DeployStudio Runtime following the initial imaging
  • dstudio-auto-reset-workflow: Used to disable the automate checkbox for the workflow
  • dstudio-auto-started-workflow: Used to assign a workflow. When populating this via the command line you will need to specify the ID of the workflow (remember that the Workflows are in property lists in the Workflows directory. Each has a key for ID, which is what would be used here
  • dstudio-group: Adds the client to a computer group
  • dstudio-host-ard-field-1: Fills in the Info 1 Computer Information field from ARD
  • dstudio-host-ard-field-2: Fills in the Info 2 Computer Information field from ARD
  • dstudio-host-ard-field-3: Fills in the Info 3 Computer Information field from ARD
  • dstudio-host-ard-field-4: Fills in the Info 4 Computer Information field from ARD
  • dstudio-host-interfaces: Arrays to configure static IP addresses for each NIC
  • dstudio-host-new-network-location: Sets up a Location in the Network System Preferences pane
  • dstudio-hostname: Sets the HostName
  • dstudio-mac-addr: The MAC address of the client

To add a computer, you can use plistbuddy or just the defaults command. In the following example, we’ll continue to house our DeployStudio Repository in the /DSDatabase directory and write in only the computer MAC address and whether it will receive a network location, which from what I can tell are the only required keys:

defaults write /DSDatabase/Databases/ByHost/00254bcc76f2 ‘{“dstudio-host-new-network-location” = NO;”dstudio-mac-addr” =”00:25:4b:cc:76:f2″;}’
Next, we’re going to add another key to set the first ARD field for a different computer when it is imaged. Your database (ERP, SIS, etc) kicks off the following script, which also puts the intended user’s Active Directory user name in the first ARD field:
defaults write /DSDatabase/Databases/ByHost/00254bcc53ab ‘{“dstudio-host-new-network-location” = NO;”dstudio-mac-addr” =”00:25:4b:cc:53:ab”;”dstudio-host-ard-field-1″=”cedge882″;}’
Once you have done so, open System Preferences and then click on the DeployStudio preference to restart the DeployStudio Server. You can also restart the DeployStudio Server using launchctl with the com.deploystudio.server daemon. Once restarted, your new computer (or computers if you ran both examples) should be listed in DeployStudio. Happy scripting!

August 9th, 2010

Posted In: Mac OS X, Mac OS X Server, Mass Deployment

Tags: , , , , , , , , ,

Originally Posted to the 318 TechJournal
318 has decided to open source our ASR Setup Tool, which can now be found at The ASR Setup Tool is built as a wrapper for the asr command line suite from Apple. The description from SourceForge:

Developed by 318 Inc., ASR Setup Tool is an application for setting up Apple Software Restore (“ASR”). In the context of the ASR Setup Tool, ASR is used for setting up a multicast stream that can then be leveraged for imaging Mac OS X computers. We hope you enjoy!

December 14th, 2009

Posted In: Mac OS X, Mac OS X Server, Mass Deployment

Tags: , , , , , , ,

Next Page »