krypted.com

Tiny Deathstars of Foulness

One of the primary use cases for Apple Configurator 1 and Apple Configurator 2 is to get apps on devices. Even with MDM, you can use Apple Configurator 2 for app deployment. The value here might be that you end up transferring 10 gigs of apps over a USB cable, rather than over the air in larger deployments. Here, we’ll look at a basic app deployment using Apple Configurator 2. To get started, first download the app and get it in iTunes. This can be accomplished by copying the .ipa file for an app onto a device, or syncing an iOS device with iTunes that has the app installed. Take care that the Apple ID associated with the app will be applied on the device. Then, open Apple Configurator 2 and choose a Blueprint (View -> Edit Blueprints) you’d like to apply, or deploy, this app to. Once uploaded and assigned, any device that you apply the Blueprint to will receive the app. Right-click on the Blueprint and click on Add and then choose Apps in the submenu. Screen Shot 2015-11-04 at 9.10.58 AM You will need to authenticate to the iTunes Store using an Apple ID. Notice that if you’ve previously connected Apple Configurator 2 to the iTunes Store that you will routinely get prompted to reconnect when the key expires (seems to be after a good 4 hours of inactivity, but not sure yet exactly when to expect – this might be a bit annoying for environments that have students that don’t have that password doing some of the work). Screen Shot 2015-11-04 at 8.42.45 AM The when you authenticate, you’ll be prompted for a list of apps to install. Here, we’re just going to choose some generic app and click on Add Apps (yes, that’s plural, you can choose more than one). Screen Shot 2015-11-04 at 8.43.51 AM The app will be listed. Any device the Blueprint is applied to then receives the app. Screen Shot 2015-11-04 at 8.44.05 AM You can also assign an app to a device manually. To do so, control-click (or right-click) on a device and then use Add to choose the Apps… option. The rest of this process is pretty much the same. Screen Shot 2015-11-04 at 8.46.53 AM Overall, these options are similar but a bit more matured than they were in Apple Configurator 1. There are a few other pretty cool options that we’ll explore soon, but for now this should get you started in getting apps as a part of your Apple Configurator 2 deployment.

November 9th, 2015

Posted In: Apple Configurator, iPhone, Mass Deployment

Tags: , , , , , , ,

I had a very interesting debate with someone the other day. The debate was around the Total Cost of Ownership of an app on a desktop computer. Let’s say that you have a $5 app. Now let’s say that in order to package that app up and test it for end user deployment, that the cost to your organization is about $400. That’s going to seem high if you just look at it as a number. But when you consider that it takes time to customize an app package so that end user data is preserved and end users aren’t prompted a dozen times, then it takes time to test that package (thus my continued interest in crowdsourced automated regression testing these days), and then it takes time to deploy that package, potentially with rollbacks and customer issues when done en masse, $400 might end up being very low for some software titles and very high for others. The debate. I’ve been on a lot of deployments with 25,000 or more users/devices. And something that always comes up is “OMG how can people have this much software out there?” One deployment, the customer estimated that there were about 20 apps on their 10,000 devices and there ended up being well over 1,000. This was OS X, not iOS. On iOS it’s a much easier conversation. But on OS X and Windows, a lot more work must go into preparing apps for deployments. In OS X, users can be a bit more irritable about tampering with systems, so extra care must be taken to not bug users when you deploy software. In most software titles for Windows, you have more patches. It ends up being a similar amount of time to manage your Definitive Software Library (DSL) for each. Now let’s say that for your 1,000 apps, you spend $400 per app to manage that, per patch, with around 4 patches per year as a round average number. This means that each unique application title ultimately costs you $1,600 to own (not including logistical concerns around chasing down licensing, the cost of the initial app, and any services attached to apps). For 1,000 apps, you could be looking at $1.6 Million dollars just to keep your repository up-to-date. Scale helps. In Casper, we’re working on “Patch Management” as a feature. This is why. At 318, I worked with my team to get the open source AutoPKG linked to our Casper environments so we could have a tool that used recipes to automatically import known software into our Casper servers. We could then have a release management process around regression testing the software and ultimately releasing it to users for UAT and then to the full compliment of users, or in waves. Let’s say that implementing such a tool saves you 25% of your time. Well, in the previous example, you’re now down to $1.2 Million dollars worth of labor to manage your DSL. Politics doesn’t help. Now let’s say that you are faced with not having the staff to deliver all that time to manage all those software titles in your DSL. Well, bummer. I guess you’re going to have to look for the least distributed software titles and remove them from the list of apps users can have. There are many, many apps that only one person uses. As your compliment of machines grows, the distribution of apps with less than 5 people using them displays as a hockey stick. But, each app could end up saving 5-50% of an actual humans time. And in my experience, some of these smaller distributed apps can be the most hyper-focused on a job-specific need. Some apps are absolutely frivolous. But we’re not talking about people asking you to support Angry Birds on their computers, we’re talking about business machines. Unless you work for Rovio… You don’t have to own it all. Or do you? If you deploy an app, do you have to support it as well? If you give users admin passwords, they can deploy their own apps and you don’t have to package some of those random apps. But if you let users deploy their own apps, how do you make sure you aren’t opening your company up to the risk that the app deployed is actually owned and properly licensed? And if the user gets a new machine, how do you give them that app? If all apps were distributed through an App Store (be it Apple’s Mac App Store, etc) then this would be tracked in an MDM solution. While it would be nice for administrators who have a lot of machines to manage, that would seem draconian to developers. But doesn’t it look more and more like the future? Understanding your users is key. I’ve seen many environments where administrators took an accounting of what apps people used and then surveyed users to ask if they actually used many of the less obvious apps in their environments. After doing so, between 20 and 50 percent of apps were no longer needed. Of those, a few percent ended up coming back, because users didn’t take the survey or didn’t think to mention the app in the survey and forgot about it until a few months later when that quarterly process they use the app for came back around. I’ve also seen workflows where a slightly more expensive app that did the task of 3 or 4 smaller apps could be used. The cost to license the new apps was justified by offsetting the cost of packaging, distribution and testing. In all of these environments, chargebacks for software AND the associated management caused a business analyst within a group to redefine requirements and find a better way. A packaging administrator cannot fully understand the needs of every user in a large organization; but a business analyst charged with helping a smaller group can get innovative and cut costs while providing even more value to end users. Is the Mac a Mobile device? All of this comes into focus because on a call, someone said that managing Macs had been marketed as similar to managing iOS devices. No. That’s not the case. Some of the same tools are use, which help to simplify management. And the focus is on empowering users rather than limiting users. The work that we do in packaging is just to provide a better user experience. However, when I speak to organizations on technical requirements and integrating services, I often ask “what is the workflow for Windows?” For example, NetBoot. I always ask “what do you do for PXE-booting,” which helps set the stage for my next question “can we get an IP helper, just like the one you created for PXE?” When you frame a request in a way that there’s a historical analogy, administrators more easily understand the intent, technology, and desired end state. While imaging a computer in the Post-PC era may be arguably dead technology, it still serves some troubleshooting purposes and so cannot be fully discounted. And if you disagree with that, the analogy still holds true for other technologies, such as defining MIME types for a server that’s distributing .ipa files. So in conclusion, the arguments here are supporting a very basic question: how do you calculate the ROI of an app that is distributed to only a few users, and whether the ROI is greater than the productivity or creativity gain that the app provides. Obviously, the answer is “it depends” which is not a basic answer. However, you can take these questions and derive whether containment makes sense for your organization or not. Chances are, you can remove a good chunk of apps that are deployed in your environment. And then you can focus on packaging and support of the remaining apps. Of the successful large-scale deployments I’ve worked on, this has been an absolute pre-requisite to getting to the point where they can support machines with one tech/engineer per more than 1,000 systems. Now don’t even get me started on virtualization of these apps…

October 27th, 2015

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

Tags: , , , ,

I mentioned the JAMF Nation User Conference on the site before, but now I need to mention it again. Mostly because I’ll now be doing a presentation now. I know, I said I wasn’t going to be doing much public speaking. But the only conference I’ve been to in the last decade that I wasn’t speaking at has been the JAMF Nation User Conference. Sooo, how could I not, when the conference is, after all, in the city I live in! Anyway, my session has been added to the sessions page: http://www.jamfsoftware.com/events/user-conferences/jamf-nation-user-conference-2012/sessions Hope to see you there!

October 4th, 2012

Posted In: iPhone, Mass Deployment

Tags: , , , , ,

For many iOS deployment projects, iTunes is used as the primary deployment vehicle for the devices. iTunes can be used to “Backup” and “Restore” an iPad, similar to how you image desktop and laptop computers. The actual deployment process is straight forward. First we’ll create a backup in iTunes. Then we can deploy the backup using the Restore option within iTunes. Provided the backup is encrypted, the Restore option will maintain the maximum amount of data available. For example, if a device has been activated then the fact that it has been activated is maintained across a restore. As are the applications that are installed on the device. Create iTunes Backup To Create an iTunes Backup:
  • Open iTunes and dock the device with the master configuration.
  • Check the box to “Encrypt local backup.”
  • At the Set Password screen, provide a password for the encrypted backup.
  • In order to ease restore, check the box for “Remember this password in my keychain (passwords are set to user names).
  • Control-click on the name of the device in the DEVICES section.
  • Click on “Back up”.
  • If prompted, click Set Password (subsequent backups will not require passwords).
Restoring with iTunes To Restore an iTunes Backup:
  • Open iTunes and dock the device to be restored.
  • Control-click on the device.
  • Click “Restore from Backup”
  • At the “Restore From Backup” screen, select the name used in the previous backup.
  • Click Restore.
  • If prompted, enter the Password.
  • Rename the iPad once the restore process is complete.
  • Once the Restore is complete, if prompted to “Set Up Your iPad”, uncheck the Automatically sync songs and videos to my iPad box and “Automatically sync apps to my iPad”, putting the students Active Directory name in the Name field and clicking Done

August 9th, 2012

Posted In: iPhone, Mass Deployment

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

If you deploy a large number of computers to users who are somewhat likely to play practical jokes on each other then you will run into some interesting issues. If you are deploying one computer to every user and you want each user to be an administrator of their computer then you might be tempted to allow all users to be administrators of all computers. If you do then prepare for an infinite number of sometimes amusing practical jokes. But really, being proactive about this brings up an interesting point: how do you deploy a computer and make only the user who you want to be an administrator an administrator. In a large deployment of Mac OS X, you are going to likely have a map somewhere between what user has each computer. You may even go so far as to name the computers the same name that you name the user associated with the computer. If you do this, then you have a pretty straight-forward task ahead of you. Basically, you’ll add the user who you are handing the computer to an administrator by adding them to the admin group. In order to do so, can check the “Allow user to administer this computer” as you can see in the following figure. If you have a sizable deployment you’ll want to automate this task rather than log in as each user and set the setting. You can automate the task using the dscl command along with the append verb. For example to place the user cedge into the admin group:
sudo dscl . append /Groups/admin GroupMembership cedge
That works as a one-off operation but not in bulk. If your computer name is the same as the user who will be using the system you can then use the scutil command and “–get” the ComputerName:
scutil –get ComputerName
NOTE: The –get options in this article are two hyphens rather than one, WordPress just merges them for some reason… You can then use this as the variable to use for augmenting the GroupMembership for admin:
sudo dscl . append /Groups/admin GroupMembership `scutil —get ComputerName`
Pop that into a post-flight package and you’ve got yourself a solution where you make the primary user of a system the admin of the local box and then make the subsequent users standard accounts. If your ComputerName doesn’t match your user name then all is not lost. One way to grab what admin user you’d like for each host would be to populate something on the client with that information. Another would be to put it in a csv and read the line for the csv that is associated to the computer in to obtain it. If you populate something on the client it could be the Text1 field from Apple Remote Desktop. This can be done using the Remote Management option in the Sharing System Preference, clicking on Computer Settings and then typing the data into the Info 1: field. To insert the information at image time (or at least programmatically), you could use defaults to write it into com.apple.RemoteDesktop.plist, located in /Library/Preferences:
defaults write /Library/Preferences/com.apple.RemoteDesktop Text1 “cedge”
To then read that variable:
defaults read /Library/Preferences/com.apple.RemoteDesktop Text1
The command to set the admin user based on the Text1 field would then be:
sudo dscl . append /Groups/admin GroupMembership `defaults read /Library/Preferences/com.apple.RemoteDesktop Text1`
There are probably about as many other ways to go about this as there are Mac OS X mass deployments. For example, instead of inserting data into Text1 from a defaults command, you could use kickstart with the -computerinfo option to write data into -set1 -1 or something like that (which is likely safer than defaults, albeit more difficult if you decide to do it to your non-booted volume). But hopefully these options, somewhere down the road, will help someone (after all, that’s why we post this kind of thing, right?!?!).

July 27th, 2010

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

Tags: , , , , , , , , ,

During various automations in Mac OS X it helps to grab some key unique identifiers for machines. Two very common identifiers are the serial number of a computer and the MAC Address. To grab a systems serial number I usually use ioreg to run the following, which simply outputs a systems serial number:
ioreg -l | grep IOPlatformSerialNumber | cut -c 37-46
Because a system can have multiple MAC addresses (one per unique adapter), I will also use ioreg to grab those:
ioreg -l | grep IOMACAddress
Or to just see an output of the first in the list (en0):
ioreg -l -w 0 | grep IOMACAddress | cut -c 37-48 | head -n 1

May 12th, 2010

Posted In: Mac OS X, Mass Deployment

Tags: , , , ,

Fast User Switching allows a user of Mac OS X to switch accounts without logging out of the account they are currently in. There are a number of uses for this, from troubleshooting to managing workflow. The back end functionality comes from the CGSession binary located in /System/Library/CoreServices/Menu Extras/User.menu/Contents/Resources. There are a couple of options you can use with CGSession, -switchToUserID and -suspend.
/System/Library/CoreServices/Menu Extras/User.menu/Contents/Resources/CGSession -switchToUserID 1022
If an account has no password then the switch should occur automatically. If there is  password then you can simply bring up a login window using the following command (you can also switch to a given user id but it will ask you for a password):
/System/Library/CoreServices/Menu Extras/User.menu/Contents/Resources/CGSession -suspend
You can also invoke CGSession from other languages. AppleScript seems to be a common one that we use. To do so you might use the following line in AppleScript to bring up the fast user switch screen via AppleScript:
do shell script ” /System/Library/CoreServices/Menu Extras/User.menu/Contents/Resources/CGSession -suspend”
You could also use the following to switch to a known user en masse (rather than a UID), such as localadmin here:
set userid to do shell script “id -u localadmin” do shell script “/System/Library/CoreServices/’Menu Extras’/User.menu/Contents/Resources/CGSession -switchToUserID ” & userid
If you would also like to add a password as a part of the AppleScript then you would tell “System Events” to tell a window of SecurityAgent to set the value of the password text field to the password you would like to use. You could then loop that through every option in a dictionary of possible password combinations if you aren’t then sure what that password should be… Random sidenote: In that resources directory, there are some image files. I have changed my /System/Library/CoreServices/Menu Extras/User.menu/Contents/Resources/greenmarker.tiff file to be a different icon, allowing me to have a little custom image. It’s the little things…

May 3rd, 2010

Posted In: Mac OS X, Mass Deployment

Tags: , , , , ,

Originally Posted to the 318 TechJournal:
318 has open sourced our mergeSafBookmarks python script. This tool can read in a pair of property lists and merge them into a single resultant bookmarks file for Safari. This takes a lot of the work out of pushing bookmarks to existing users as part of your deployment. You can find it here:
http://mergebookmarks.sourceforge.net Note: The script also looks at existing bookmarks and doesn’t merge in duplicates.

December 22nd, 2009

Posted In: Mac OS X, 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 http://asrsetup.sourceforge.net. 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: , , , , , , ,

All 3 of the Snow Leopard titles I’m working on, editing or in one case done with for Apress are now posted to Amazon and can be purchased.

September 21st, 2009

Posted In: Articles and Books, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , ,

Next Page »