Tag Archives: deployment

Mac OS X Mac OS X Server Mass Deployment

Delete nvram

A nifty little new option that came in OS X 10.9 Mavericks and stays in Yosemite is the ability to delete all of the firmware variables you’ve created. This can get helpful if you’ve got a bunch of things that you’ve done to a system and want to remove them all. If you run nvkram followed by a -p option you’ll see all of the configured firmware variables:

nvram -p

If you run it with a -d you’ll delete the given variables that you define (e.g. boot-args):

nvram -d boot-args

But, if you run the -c you’ll wipe them all:

nvram -c

Articles and Books Mac OS X Server

Chapter 3 Of My Next Book Available

The next chapter of my next book is again available free for TidBits readers at http://tidbits.com/article/14799:

This article is a pre-release chapter in the upcoming “Take Control of OS X Server,” by Charles Edge, scheduled for public release later in 2014. Apart from “Chapter 1: Introducing OS X Server,” and “Chapter 2: Choosing Server Hardware,” these chapters are available only to TidBITS members; see “‘Take Control of OS X Server’ Streaming in TidBITS” for details.

Hope you enjoy! And thanks again to Adam and Tanya for their awesome editorial!

Mac OS X Mac OS X Server Mac Security Mass Deployment public speaking

MacSysAdmin 2014!

Well, it’s that time of the year when one of my favorite conferences opens up registration! Come one, come all to MacSysAdmin for good times, good people and lots of fun Macinnerdiness! I hope to see you there! The official page is up at http://www.macsysadmin.se.
Screen Shot 2014-04-13 at 8.02.49 PM

Mac OS X Mass Deployment

Enable Safari Status Bar Using Defaults

Nice and easy one today. By default, the Safari status bar is disabled at the bottom of a Safari screen. To enable:

defaults write com.apple.Safari ShowStatusBar -boolean YES

iPhone Mac OS X Mac OS X Server

Apple ID Bulk Importer

Some iOS and/or OS X deployments require us to create a boatload of Apple IDs. This could be to redeem VPP codes, to do iOS backups, to configure Messages, now giving the ability for OS X Server users to password reset for themselves, etc. I have sat and manually created Apple IDs for a number of clients. I’ve created dozens at a single sitting and there are some serious annoyances and challenges with doing so manually. For example, you’re gonna’ fat finger something. If you type 10 things in for 50 accounts then it’s hard to imagine you’re not gonna’ mess something up in one of those 500 fields. It’s also time consuming and well, just annoying.
AppIcon

Then, along came a script. That script allowed us to create loads of IDs on the fly. Now, we have a very nice GUI tool called the Apple ID Automation Builder that can be used to batch create a number of Apple IDs on the fly. Brought to us by Greg Moore and hosted by enterpriseios.com, this is one of those rare finds that is a serious time saver and very valuable when you need it in your bat belt. Great little tool, well worth the money and I look forward to providing Greg with plenty of accolades should we ever meet!

iPhone Mac OS X Mass Deployment

JAMF Nation User Conference 2012

JAMF has announced the 2012 rendition of their National User Conference. Having been to two of these, I can say that if you use any JAMF products that it is a great event to attend. It is a lot of very specific information about integrating, mass deploying, mass managing, mass document distributing and mass 3rd partying for Apple products.

The National User Conference will be held October 23-25 2012, 8:00 am – 5:00 pm in beautiful Minneapolis, Minnesota (where all the cool kids live). The venue is one of the best conference spots I’ve seen in the Guthrie theater, overlooking the stone arch bridge. In previous years, there have been announcements, new versions, people discussing their specific integrations, etc. I would also think that if you use another product that you might find the conference helpful, as you get to see whether the grass really is greener on the other side!

Anyway, I recommend coming out to Minneapolis for this one if you can. And if you do, let me know!

Mass Deployment

Deploying and Managing Firefox Part 2: Working with Munki

A special thanks to Nick McSpadden for his third submission to krypted.com. With all the new changes in OS X/Server I haven’t even had time to write as many in such a span!!!

This is a follow up post to the Firefox Management guide.

Knowing how to use the CCK to manage Firefox, the next big question is: how do we get this into Munki? It’s unfortunately not as cut and paste as we’d hope, because, with all things, Firefox tends to make us do a bit of work to get what we want from it.

Importing Firefox 10.0.10 ESR (current version as of writing time) into Munki is easy. You can add whatever other stuff you need to the pkginfo, but it tends to take care of itself.

Importing the CCK into Firefox is where this gets fun. Luckily, some very smart people have figured this out, thanks to the MacEnterprise mailing list. See the conversation here: https://groups.google.com/d/topic/macenterprise/YUqrm96QSFo/discussion. Credit goes to Nate Walck for the script and Greg Neagle for the advice.

If you are deploying the CCK into the internal Firefox application distribution directory, then you may notice that a vanilla install of Firefox does not have the Firefox.app/Contents/MacOS/distribution/bundles/ directories. We’ll have to create them as part of the install process.

If you want to put the Firefox CCK files somewhere other than inside Firefox, you’d need to change the add-on scopes for Firefox to load it. This isn’t really ideal either, because it requires micromanaging the Firefox install, which means that every time you import a new Firefox update, you have to do a lot of manual labor to make sure all these preferences get included.

One solution is to repackage Firefox with the CCK itself and deploy that as one. It works just fine, but it’s a lot of work – especially with Firefox’s release schedule. You’d have to rebundle it for Munki every six weeks. Pox on that, I say. But editing Firefox preferences is also undesirable for the extra work it generates.

Greg’s suggestion: a symlink! Throw the CCK anywhere, such as /Library/Application Support/FirefoxCCK/, and then create a symlink into Firefox’s bundles directory.  In this post, I’ll be using the example CCK configuration named “test-sacredsf-cck@extensions.sacredsf.org” as in my last post.

There are a few pieces to this we need to incorporate:

  1. A postinstall script for Firefox that guarantees the establishment of the symbolic link between the CCK location and the internal Firefox bundles directory.
  2. A package for the CCK itself that drops the items in the location you want, with the appropriate installs key to ensure it reinstalls if deleted.
  3. The CCK package should also establish a symbolic link to itself if one does not already exist.
  4. A guaranteed reinstall of Firefox, should it be deleted, that also incorporates the re-establishment of the symbolic link.

We can accomplish part of this in a postinstall script for Firefox in Munki:

#!/bin/bash
mkdir -p -m 755 /Applications/Firefox.app/Contents/MacOS/distribution/bundles/
mkdir -p -m 755 /Library/Application Support/FirefoxCCK/
if [ ! -L /Applications/Firefox.app/Contents/MacOS/distribution/bundles/test-sacredsf-cck@extensions.sacredsf.org ];
then
 ln -s /Library/Application Support/FirefoxCCK/test-sacredsf-cck@extensions.sacredsf.org /Applications/Firefox.app/Contents/MacOS/distribution/bundles/
fi

The if statement above is potentially unnecessary, since it’s unlikely there would be a situation in which Firefox would install but somehow the internal contents of /Contents/MacOS/distribution/bundles/ is preserved, but I figure the extra check won’t hurt.

You can also set this same script to be a postinstall_script for the CCK package, so that if you ever have to add more addons to Firefox, you can guarantee that the symbolic link will be established.

To guarantee the sanctity of our CCK, we’d have to add an installs item to check that the unpacked CCK exists. We check the CCK’s path, and that the CCK’s md5 matches the expected one (so that we can guarantee it hasn’t been changed). The CCK’s existence and its md5 should be installs keys for the CCK itself.  In this case, I do not explicitly call for an installs check on the symlink itself, on the basis that it’s extremely unlikely someone will delete the symbolic link but not Firefox.app.  Unless the user has administrative privilege, they can’t delete either of them anyway.  If your users have administrative privileges, then it doesn’t really make sense to manage Firefox for them.

The installs keys for Firefox:

<key>installs</key>
<array>
 <dict>
  <key>CFBundleIdentifier</key>
  <string>org.mozilla.firefox</string>
  <key>CFBundleName</key>
  <string>Firefox</string>
  <key>CFBundleShortVersionString</key>
  <string>10.0.10</string>
  <key>minosversion</key>
  <string>10.5</string>
  <key>path</key>
  <string>/Applications/Firefox.app</string>
  <key>type</key>
  <string>application</string>
 </dict>
</array>

The installs keys for the CCK package (obviously you’ll need to change your checksum accordingly):

<key>installs</key>
 <array>
 <dict>
 <key>path</key>
 <string>/Library/Application Support/FirefoxCCK/test-sacredsf-cck@extensions.sacredsf.org</string>
 <key>type</key>
 <string>file</string>
 </dict>
 <dict>
 <key>md5checksum</key>
 <string>8c994a5e24ebee8f8227f5d2e37b97dc</string>
 <key>path</key>
 <string>/Library/Application Support/FirefoxCCK/test-sacredsf-cck@extensions.sacredsf.org/cck.config</string>
 <key>type</key>
 <string>file</string>
 </dict>
 </array>

We do it this way to guarantee that the CCK is always linked to the correct place in Firefox, even if Firefox is updated, or installed separately. Since Firefox always creates the symlink as part of its install, we don’t have to worry about it breaking if the user deletes Firefox, or Firefox gets updated to a new version (which won’t have the directories or symlink inside it by default).

The CCK will only get reinstalled if it’s missing from the /Library/Application Support/ folder (or wherever you initially stashed it).

This way, as long as the CCK is listed as an update-for for Firefox, you’ll always guarantee that the correct Firefox management is installed.  The only thing you need to remember to do is copy the postinstall_scripts to each new version of the Firefox and CCK pkginfos (although the CCK pkginfo will need a new checksum if you make changes).

Mass Deployment

Deploying and Managing Google Chrome: The Rough Guide

The following is a post from the most excellent Nick McSpadden. It is very well written and I am proud that it is the first article published on this site using the new submissions page. Looks like it’s time to change the banner from my Notes from the Underground, er, I mean, Field, to just Notes from the Field!

Greetings!

This is a sort of follow-up to my guide on managing Firefox, this time focusing on managing Google Chrome. I’m working on current Chrome version 18 (which just today got updated to 19), and I don’t know for sure how far back this will work, but I think anything higher than v16 properly supports the MCX policies.

The good news about Google Chrome is that it supports MCX! Unlike Firefox, which requires specific and somewhat obtuse procedures for managing it (including depending upon an add-on that is independently maintained by a hard working individual), the most important parts of Chrome management can be done with already-existing MCX controls.

First let me start off with a link to a very helpful set of information: http://www.chromium.org/administrators
That link covers just about everything you’ll need to know about Chrome policies and management, though some of it is buried. I discovered (much to my chagrin) that the Chromium site is much more thoroughly documented that Google’s official “Chrome for Administrators” site.

Some important notes about Chrome MCX: all Chrome policies are required to be set to “Always.” They’re like Profiles from Profile Managers – there’s no middle ground. Even if you set it to “Once” or “Often,” Chrome will treat the policy as permanent and prevent the user from changing it. Any policy being managed by MCX in Chrome will be grayed out to user interaction (and there will be a message in the “Options” window about how some settings are being managed by the administrator). So you’re going to have to “Always” manage these settings whether you like it or not.

The good news is, there’s an alternative, the Master Preferences. The downside is that the Master Preferences is a “once” option, and doesn’t prevent the user from changing it. It’s a good way to provide default settings without restricting the users’ ability to personalize it later on. More on that later.

So, following the Mac Quick Start Guide: (http://www.chromium.org/administrators/mac-quick-start)

1. Inside a fresh copy of Google Chrome is a nice fresh copy of the manifest. Access it here: /Applications/Google Chrome.app/Contents/Resources/com.google.Chrome.manifest/Contents/Resources/com.google.Chrome.manifest

2. Load this manifest into WGM

3. Here’s the full description of all policies in the Chrome manifest: http://www.chromium.org/administrators/policy-list-3

4. There are some particularly important settings that will be relevant to most. Here’s what my plist looks like for a lab computer (no individual users):

  • AutoFillEnabled – False (disables the ability to store autofill information)
  • BookmarkBarEnabled – True (forces the bookmark bar to show up on all tabs, all the time)
  • HideWebStorePromo – True (prevents the web store from trying to sell you things, but does not disable the web store)
  • HomePageIsNewTabPage – False (if you don’t disable this, the homepage will be set to the default Chrome tab page, which opens up the “Most Visited/Apps” switcher)
  • HomepageLocation – URL (even if you set this, if HomePageIsNewTabPage is set to true, this URL gets ignored)
  • PasswordManagerEnabled – False (for lab machines, I don’t want them saving passwords, intentionally or accidentally)
  • RestoreOnStartup – 0 (0 forces it to open the homepage URL on startup)
  • SyncDisabled – True (same reason as Password Manager – I don’t want these personalized at any time).

That gives you a basic setup for most things you’ll need to worry about. If you deploy this, you’ll notice a few problems, though. The first time you launch Chrome, it gives you an undismissable dialogue box asking you if you want to make Chrome the default or submit other info. That’s bad. The above manifest also provides no way to control the auto update mechanism, if that’s something you want to do.

This is where the Master Preferences file comes in – http://www.chromium.org/administrators/configuring-other-preferences. By specifying a Master Preferences file, we can load up default preferences for user accounts *when they are created.* Note that the Master Preferences file has absolutely no effect on already existing Chrome profiles – only upon new-user generation does Chrome load this file. It literally copies and pastes the settings in here into the appropriate places in ~/Library/Application Support/Google/Chrome/Default/Preferences.

On Mac OS X, the Master Preferences file must be located at:
/Library/Google/Google Chrome Master Preferences
(yes, really – the file must be named “Google Chrome Master Preferences” with no extension), and must obviously be readable by any user who can launch Chrome (i.e. use 644 permissions).

The Master Preferences file is a JSON file that can contain any of the preferences normally used by Chrome. If you want the full list of all possible preferences, load up a default Chrome profile and take a look at the Preferences file I mentioned at the path above. It has everything you’d ever want (and a lot of stuff you probably don’t). To save you some time, here are some important ones you’ll want to use specifically for deploying Chrome:

{
"homepage_is_newtabpage" : false,
"browser" : {
"show_home_button" : true,
"check_default_browser" : false
},
"bookmark_bar" : {
"show_on_all_tabs" : true
},
"distribution" : {
"skip_first_run_ui" : true,
"show_welcome_page" : false,
"import_bookmarks" : false,
"import_bookmarks_from_file" : "/Library/Google/chrome_bookmarks.html",
"make_chrome_default" : false
},
"sync_promo" : {
"user_skipped" : true
}
}

The chromium.org page I linked above goes into a bit more detail about this, but I want to give a quick note about the interaction between preferences and MCX. MCX always wins. Any policy managed by the MCX and also specified in the Master Prefs will always go the MCX policy. In the example above, if I had set “homepage_is_newtabpage” to true, it would still be false because MCX sets it to false, and that policy is always enforced.

The really import part is the “distribution” section. “skip_first_run_ui” will get rid of that annoying dialog box that comes up when you first launch Chrome. The “import_bookmarks” option asks the user through a UI dialog box if the user wishes to import bookmarks from another browser. Obviously, we want to suppress that. There’s an option instead to silently import bookmarks from an HTML file. You can create this bookmarks HTML file by setting up the bookmarks the way you want, and then Exporting them in the Bookmark Manager. I place that bookmarks file in /Library/Google/ because it’s already used, but you can put it anywhere. There is, however, a known bug that has now been assigned a milestone and a solver in Chromium’s bug list – the “import_bookmarks_from_file” is actually ignored if the “skip_first_run_ui” is set to true. So right now, you can’t silently import your bookmarks in.

The “sync_promo” item doesn’t seem to be necessary if you disable Sync in the MCX settings above, but since MCX policy always wins over Master Prefs, there’s no penalty or downside to including it.

Note that your JSON syntax has to be perfect for this to work. Any incorrect comma placements, and it simply ignores your master prefs file. If you find that your Master Prefs isn’t loading up as expected, run Chrome from the Terminal with the debug log turned on to see what’s happening:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome –enable-logging –v=1
This places a file called “chrome_debug.log” in ~/Library/Application Support/Google/Chrome/Default/ (i.e. default user data directory). The first line will tell you exactly what went wrong with your Master Prefs file.

Now, there’s still one more problem here: new tabs open up to the default Chrome “New Apps / Most Visited” switcher page (called the newtab page). Unfortunately for us, there’s no way to change this behavior present in the UI. The good news is, this behavior annoys plenty of other users, and there are a million extensions you can use to get rid of it. More good news, is that you can silently include extensions in your MCX manifest!

So simply add this to your MCX settings above (forgive the pseudo XML here, just to indicate type of key):
<array> <string>lcncmkcnkcdbbanbjakcencbaoegdjlp;https://clients2.google.com/service/update2/crx</string> </array>

This silently forces the install of an extension called “Empty New Tab Page,” and specifies an update URL for it (required, since Chrome autoupdates its extensions too if they come from the Chrome Web Store / Extensions pages). The extension does what you think it does – you get a blank page. There are other extensions for customizing the new tab pages, or anything else, so as long as you get the extension ID (it’s the long block of letters in the beginning), you can load whatever you want in here.

There you go! I’ve tested this using Local MCX on my 10.6 and 10.7 machines, and it works perfectly (deployed through Munki as well). On the whole, Chrome is a bit easier to manage and deploy than Firefox, just because it doesn’t require modifying the app itself to do this. Also, the Master Preferences file works for any instance of Google Chrome – even if the users install a copy somewhere other than /Applications. This also does work for Chromium, the open-source version of Chrome.

Hope this helps someone.

Mass Deployment

Deploying and Managing Firefox: The Rough Guide

Another Great Article Submitted From Nick McSpadden:

After working with this for a bit, I’ve come up with a step by step installation process for Firefox 10 ESR + CCK deployment on Mac OS.

Firefox CCK Guide – Part I
Most of the information about add-ons that you’ll need is in Mike Kaply’s blog:

http://mike.kaply.com/2012/02/09/integrating-add-ons-into-firefox/

1) Install CCK Wizard in Firefox 10 ESR
2) Run and configure CCK Wizard the way you want
3) Save the CCK data into a “CCK” folder anywhere you’d like.  This folder will contain:

  • cck.config
  • cck.xpi
  • xpi/ directory

4) When done, open up CCK/xpi.config
5) Copy the contents of the id=<name> key – this is the name you provided when configuring the CCK addon.  In my example, it is “test-sacredsf-cck@extensions.sacredsf.org”.
6) Rename “xpi” folder into the ID key from Step 5
7) Inside Firefox, create: Firefox.app/Contents/MacOS/distribution/bundles/
8) Move renamed xpi folder from Step 6 into Firefox.app/Contents/MacOS/distribution/bundles/
9) Launch Firefox, enjoy CCK!

Now, this is means that Firefox needs to be specially packaged and distributed during deployment. While this is easy for first-time deployment, it does mean that future versions of Firefox will also require repackaging. If you want to avoid this, it means you’ll have to change Firefox’s addon scopes. If you’re already repackaging Firefox for the CCK as above, then it isn’t a big deal, use the instructions in Mike Kaply’s blog:

http://mike.kaply.com/2012/02/21/understanding-add-on-scopes/

Firefox Changing Add-On Scopes – Part II
1) Make a text file named whatever you want as long as it ends in .js, such as “scopes.js”
2) Add these two lines to the file:

pref("extensions.autoDisableScopes", 0);
pref("extensions.enableScopes", 15);

3) This file needs to be saved in Firefox.app/Contents/MacOS/defaults/pref/ (the blog suggests it should be defaults/preferences/, but for me /prefs/ was already created)

4) Now user scopes are changed to the settings above.

However, if you want to avoid repackaging Firefox completely every time an update or a change to your CCK configuration comes out, or you want to have different CCK settings for each user on the system, you’ll need to change things up a bit. One way or the other, you’ll need to change the Addon Scopes, because FF10’s defaults lock out the extra directories. If you don’t want to rebundle/repackage Firefox 10, you can use any script to add in the preferences you need into Firefox.app. You can do it simply with echo:

$ echo -e "pref("extensions.autoDisableScopes", 0);npref("extensions.enableScopes", 15);" > /Applications/Firefox.app/Contents/MacOS/defaults/pref/scopes.js

(obviously double check to make sure the .js file can be read by Firefox, although I didn’t have to do anything for it to work)

Doing this allows Firefox to use any of its valid locations for extensions, listed here:

https://developer.mozilla.org/en/Installing_extensions

In other words, you’ll want to move and rename the “xpi” folder from the CCK Guide Step 6 into this location if you want it to affect all users:

/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/test-sacredsf-cck@extensions.sacredsf.org

This unpacked folder (from CCK Guide Step 4) contains the xpi contents:

  • plugins/
  • modules/
  • install.rdf
  • defaults/
  • components/
  • chrome.manifest
  • chrome
  • cck.config

…and so forth.

Use this location if you want it to affect individual users only:
~/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/
(i.e. /Users/…/Library/…)

To summarize:

I. For an individual user, I’d need to change Firefox’s addon scopes, and I’d need the unpacked xpi contents located here:
~/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/

II. For all users, but not packaged within the application itself, I’d need to change Firefox’s addon scopes, and put the unpacked xpi contents here:
/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/

III. For all users, who will be unable to disable or even see the add-on, inside the Firefox.app bundle itself, I don’t need to change addon scopes. I just need to put the unpacked xpi contents here:
/Applications/Firefox.app/Contents/MacOS/distribution/bundles/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/

That’s how you get the CCK configured and installed in its various permutations on Mac OS X. I hope that helps anyone who was struggling or thinking about adopting the Firefox 10 Extended release into their deployment strategy, as the CCK is a great tool for preconfiguring Firefox to suit your enterprise’s needs.

“But wait!” you might say.  “How do I perform an enterprise-level deployment with this method?”  See my post here for details on incorporating this into Munki: http://krypted.com/mass-deployment/deploying-and-managing-firefox-part-2-working-with-munki/.

iPhone Mac OS X Mac OS X Server

Apple Configurator 1.0.1 Released

Apple has released version 1.0.1 of the Apple Configurator tool. To install the first update to Apple’s new tool, go to the App Store on a computer that has Apple Configurator installed, click on Updates and then click on the Update button for Apple Configurator.

The update has a number of new features and fixes. The first is that Enterprise Apps can be installed. Previously, when you went to install internally developed applications, you would get an error that the installation could not proceed. Another great fix is that commas are now escaped when importing application codes from the VPP spreadsheets (a comma in a CSV/comma separated value would kill the ability to import VPP codes before). Another fix is to let you pull redemption codes from unsupervised device (this makes me very happy).

The redemption codes that you buy an app with can also now be used in Configurator, according to the release notes. This worked for me anyway, but I’ve read reports that people had to burn an additional code to use them with Configurator. The remaining redemption codes are now listed properly, as well. Another fix is that Notes and Bookmarks pushed into iBooks and iTunes U are restored properly when supervising devices. The WPA2 passwords had been wonky (according to the content of that payload), so that’s been fixed as well.

Also, a bug I hadn’t noticed, the capacity of an 8GB iPod Touch is now displaying properly…