Disabling iCloud as default save location

Krypted.com has a new post on disabling iCloud as the default save location for new documents.

This feature affects apps that can save to iCloud, and only if the user has an iCloud account configured for the current login.

Still, you might want to turn this off by default for all users in your organization so they don’t accidentally store company documents on Apple’s servers. The Krypted.com post shows a command-line way to change this setting for a single user. How might you do this for all users?

One way would be to install a computer-level profile that installs the right settings. Here’s one.

If installed as root using the /usr/bin/profiles tool:

sudo profiles -I -F DontSaveNewDocumentsToiCloud.mobileconfig

This setting will be applied Once to all users as they login.

DontSaveNewDocumentsToiCloud.mobileconfig was created using Tim Sutton’s mcxToProfile tool.

Flash Dance

In comments on my previous post here, TGB makes some interesting points:

While you’re not wrong that Flash Player deployment isn’t ideal, and it should be as easy as dragging and dropping a pkg, I don’t see how the repackaging route is any more of a waste of time than any other product. Adium, Mactracker, Firefox, Chrome and a whole bucket of other apps all require packaging to be deployed. Sure, they might auto-update, but you have to get an initial version out there, not to mention getting your preferred default settings out too.

Most, if not all the items mentioned (Adium, Mactracker, Firefox, and Chrome) are distributed as “drag-n-drop” disk images where the user is expected to drag the application to the /Applications folder. I’d argue that is an industry standard deployment method. The software deployment system I use (Munki) can install items like this without the need to package them. If your software deployment mechanism does not, perhaps you should be requesting that feature from your vendor, since this is a very common distribution format, and code-wise, requires  little effort to support. When a new version of Firefox or Chrome comes out, I just download the disk image and directly import it into Munki — no packaging needed.

Adobe Flayer Player cannot be distributed as a drag-n-drop application disk image — it’s not an application. So the “correct” distribution format for this software is the Apple package format.

Preferred default settings is a completely different issue. As long as vendors use Apple’s preference file format, this is solved with MCX or Lion/Mountain Lion profiles.

TGB also writes:

Not to mention, with any of these products, testing them (yes?) is more time and effort-intensive than any actual packaging. 3/4 of deployment and integration is non-technical work. A couple of minutes difference doesn’t really matter in the scheme of QA, UAT and change management process (or are others just not doing that?).

Flash is not needed by any business-critical application where I work, yet our users demand (or at least expect) it and Apple and Mozilla demand it stay up-to-date, or they will disable the plug-in. So for us at least, testing is quite minimal for Flash. If it installs and can display some Flash content, it’s good.

But yes, I do understand and sympathize with admins that must test each release of Flash with business-critical applications — and Adobe’s distribution format is not the key issue here; frequency of releases is. I’d argue that this is an impetus to reduce or eliminate your internal dependency on Flash.

Where I disagree with TGB: Adobe’s non-standard distribution adds more than a “couple of minutes” to preparing a new release of Flash for enterprise distribution. If we could be sure that Adobe will never change anything about their installer and updater, we could just figure out a process and repeat it for each new release. But Adobe can and has changed things, so for each release we must also test that our packaging/repackaging/custom deployment steps actually end up with the desired results. This is usually not a huge deal, but also cannot be ignored. But more importantly, theirs is a one-off solution. If we have to keep track of and test different deployment solutions for each vendor and product, we end up wasting a lot of time and effort, and making a lot of mistakes. Where would it end? Unique software deployment methods for each vendor? (Oh that there was only ONE unique deployment method for Adobe software!)

No, a line must be drawn. Here. No farther.

Mountain Lion and Software Update

Mountain Lion introduces a small, yet significant change in how OS X clients communicate with Apple’s Software Update servers.

Mountain Lion clients by default now consult an HTTPS URL to check for updates on Apple’s servers.

This has the implication that you can no longer use DNS trickery with Mountain Lion clients to get them to access your internal SUS instead of Apple’s. Some organizations configured their internal DNS servers to resolve requests to swupdate.apple.com to an internal server.

The appeal of this approach (DNS hijacking) was that you did not need to touch any client machine to get it to use your internal Softwar Update server; any client using your network would “automagically” use your internal Software Update server.

HTTPS connections do certificate verification of the host. Since your internal SUS can’t offer a certificate proving it is Apple’s server (because it’s not!) a Mountain Lion client will refuse to talk to it. (It’s also possible that your internal SUS is not accepting HTTPS connections anyway, but even if you were to turn that on, it would not help.)

HTTPS prevents exactly the sort of DNS impersonation that made this hack work in the first place. Apple has closed that door.

In order to use an internal Software Update server (either Apple’s or Reposado) with Mountain Lion clients, the clients must be explicitly pointed to your internal server via MCX or by setting the preference using:
defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL <internalSUScatalogURL>

Mountain Lion and MCX

In my last post, I asserted that Local MCX still works in Mountain Lion. And it does. But that doesn’t mean there aren’t issues to deal with.

There have been various reports of certain MCX settings not behaving correctly — for example, it appears that currently you can’t use MCX to manage Dock settings “Once” — only “Always” management works. (And that’s not useful for us — it doesn’t allow one to set certain Dock defaults and then leave the Dock alone for the user to modify as they’d like.)

There’s another challenge if you use Local MCX in an alternate local DirectoryService node, as described here:

• http://managingosx.wordpress.com/2010/03/07/mcx-in-non-default-local-nodes/
• http://managingosx.wordpress.com/2010/03/07/local-mcx-update/
• http://managingosx.wordpress.com/2010/03/12/yet-again-with-the-local-mcx/

In Mountain Lion, dscl refuses to write to non-default local nodes:

# sudo dscl /Local/MCX create /Computers/foo
create: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)


This makes manipulating things in a non-default local node much harder than it was in Leopard through Lion.

You can still copy files into /private/var/db/dslocal/nodes/MCX, and that can serve as a workaround for now. All of the packages I use to configure Local MCX do exactly that — they install plist files into /private/var/db/dslocal/nodes/MCX/computergroups. But there is one major exception.

I have one package that does the setup for Local MCX. It makes sure the /Local/MCX node is present, makes sure it is in the search path, and makes sure that an appropriate record exists in /Local/MCX/Computers to represent the current local machine. This requires writing to the /Local/MCX node to dynamically create the computer record. We can’t just install a file, because the contents of the data in the computer record are unique for each computer.

So there’s our problem: we can’t use dscl to create a computer record in the /Local/MCX node, yet we must dynamically create an object in that node.

There are two solutions, both which rely on the fact that all objects in Local DirectoryService nodes are actually just plist files.

The first:  We could use another plist creation tool to create the needed plist. We could use defaults or PlistBuddy, for example. But that would require us to take the time to figure out how to use one of those tools to create a file that is the same as if dscl created it.

The second: Use dscl to create the record in the /Local/Default node. Then just move the plist from /private/var/db/dslocal/nodes/Default/computers/foo.plist to /private/var/db/dslocal/nodes/MCX/computers/

The second approach is the one I decided to take, since it seemed easier.

Here is the script I currently use for initial Local MCX setup. If you are currently using Local MCX on Lion or earlier, I hope it is of some help if you want to continue to use Local MCX on Mountain Lion.

Mountain Lion: suppress Apple ID / iCloud prompt

This question has come up a few times in the past few days, so I thought I’d better document it.

On Mountain Lion, how do I suppress the Setup Assistant that prompts for an Apple ID to setup iCloud?

The answer is to use MCX. You can use Local MCX, network directory-based MCX, or Profiles.

You can read more about Local MCX here. (And yes, Local MCX still works in Mountain Lion.)

# dscl /Search mcxread /ComputerGroups/setupassistant
App domain: com.apple.SetupAssistant
Key: DidSeeCloudSetup
State: once
Value: 1

App domain: com.apple.SetupAssistant
Key: LastSeenCloudProductVersion
State: once
Value: 10.8

Here is a profile that will do the same thing. You can use the command-line profiles tool to install it.

NOTE: for whatever reason, this doesn’t work if the management frequency is set to “Always” or “Forced”. It does work when set “Once”. I have not tested “Often”, but I imagine that would work as well.

Penn State MacAdmin 2011

Penn State is hosting the Penn State MacAdmin 2011 conference on May 10th-12th. Registration is only $100 (what a deal!) and there are lots of great sessions:

MCX:

• Client Management – MCX
• Grok Local MCX (and managed preferences in general)

Munki:

• Application Deployment with Munki

Packaging:

• Intro to Packaging
• Creating Packages with The Luggage (or How I Learned to Stop Worrying and Love the BOM)

…and other sessions on imaging, deployment, automation (including Puppet) and more. Full conference schedule is here.

Oslo OS X Workshop

Last week, I had the opportunity to travel to Oslo, Norway, to participate in an OS X workshop for the various public universities in Norway. The idea is for the universities to cooperate on developing best practices and procedures for managing OS X machines in the Norwegian universities, and this workshop was a step toward that goal. I was invited to participate to provide a different perspective and share some of my expertise in/knowledge of/experience with various aspects of Mac OS X management.

The workshop was hosted by the University of Oslo, and took place in their brand-new Department of Informatics building. Very modern, and very Scandinavian in its way.

The first day of the three-day workshop was conducted in Norwegian; but that was my “recover from jet lag day”, so I did not meet up with the workshop participants until the evening at an Irish pub — The Dubliner. Topics and tools covered that day included DeployStudio, InstaDMG, and Puppet. While the workshop participants explored these things, I explored the city center of Oslo. I particularly enjoyed the National Gallery and standing inches from works of art like Rodin’s The Thinker and Munch’s The Scream.

The following days of the conference were conducted (mostly) in English. I spoke a lot the second day, presenting on topics like the systems environment at my place of business, managing clients using MCX, the Apple package format, packaging tools, and of course, Munki. Other presenters looked at The Luggage, Joe Block’s packaging tool and Gary Larriza’s recipes for The Luggage. There was also a mention of pymacadmin.

The third day, the workshop participants broke into smaller groups and attempted to create things based on what we had discovered and learned the previous two days. For example, one group created a customized install of Adobe CS5 Design Premium and another group worked on a customized install of Microsoft Office 2011 (excluding Outlook, Communicator, and Messenger). Still other groups created packages to install a Norwegian (Bokmål) language dictionary and a customized install of Adobe Acrobat X (minus the web plugin).

In all of the tasks that involved creating customized installs of existing packages, we avoided repackaging, instead choosing to use ChoiceChangesXML files or editing the Distribution files (and for the Adobe CS5 suite, using AAMEE 1.2 to build the installation “package”).

All of these packages were tested for automated install using Munki, which was gratifying and terrifying at the same time. Live demonstrations in front of people is always where unexpected bugs show up, but Munki was (mostly) well-behaved this time. We discovered some complexities and pitfalls of modifying packages, using PackageMaker, and using Munki with customized installs.

I think overall, the workshop was a success. Participants learned about some of the management tools available to OS X administrators, got some “hands-on” opportunity to work with these tools, and began the process of figuring out how they could help each other by sharing techniques, processes, and even share actual packages if possible.

Evenings were spent sampling Oslo restaurants. I had excellent dinners at Kampen Bistro and Oslo Spiseforretning. On Friday, I had a chance to visit the broadcast facilities of NRK, the Norwegian National Broadcasting network, and the Holmenkollen Ski Jump, where the FIS Nordic World Ski Championships are being held this week and next. http://www.oslo2011.no/ has more information.
Lunch at the Holmenkollen Restaurant included reindeer steak, which was excellent.

Thanks to Thomas Hansen from the University of Oslo (UiO) for inviting me and serving as an excellent host. Also thanks to Jan Ivar Beddari from the University of Bergen, Anders Bruvik and Frank Paul Silye of UiO, Dag Tore Antonsen from NRK (the Norwegian Broadcasting Corporation) for guiding me around the city and sharing some of their time. I enjoyed my conversations with many of the other workshop participants as well! It’s always interesting to get new perspectives, as well as discuss the common challenges we all face.

I’m hoping to meet up with many of my new Norwegian friends again at MacSysAdmin 2011 in Göteborg (Gothenburg), Sweden.

A few pictures:

Managing Office 2011

One of the more popular posts on this site has been this one on managing Microsoft Office 2008.
Microsoft Office 2011 is now available to volume license customers (and soon to everyone). We’re not yet deploying it at my organization, so I haven’t done much work with it. But others have — so if you are looking for some information on managing Office 2011, check out:

http://www.officeformachelp.com/office/administration/mcx/
http://www.osxdeployment.info/wiki/Office_2011_Settings

New MCX keys for iTunes 10

Tip of the hat to Patrick Fergus on the MacEnterprise list:

Apple Knowledge Base article on managing iTunes 8.1 and later:

http://support.apple.com/kb/HT3490

At the bottom are new keys added in iTunes 10:

disableCheckForApplicationUpdates
disableCheckForDeviceUpdates
disableHomeSharing


Each of these take a boolean value.

Previously there was a single “disableCheckForUpdates” key that, when set to True, would disable both checking for updates to iTunes and checking for updates for iPhone/iPod/iPad devices. Now you can be more granular in your management.

Enterprise Mac Managed Preferences

Looks like the ebook is available now, with the print book available very soon:

http://apress.com/book/view/9781430229377

In this book, Ed Marzcak and I cover Apple’s Managed Preferences, or MCX from a practical standpoint. We discuss how Managed Preferences work, what they can manage, and some of the options you should consider. We cover several implementation scenarios, including Active Directory schema extension and even Local MCX. We also provide several step-by-step “recipes” for managing specific applications and features of Mac OS X. Written with Snow Leopard in mind, most of the examples and discussion is also applicable to Leopard, and in some cases, to Tiger as well.