Fix for Adobe CS6 activation issue

Adobe has posted some information and a fix for the recent issue with Adobe Photoshop CS6 registration/activations:

http://blogs.adobe.com/oobe/2013/01/32767-days-left-but-whos-counting.html

This issue appears to have been triggered by the Photoshop CS6 13.0.2 and/or 13.0.3 updates. The official recommendation on a fix is to update Photoshop CS6 to 13.0.4, then use the APTEE tool to remove and reapply serialization. See the above post for more details.

The APTEE tool is not exactly easy to use to deploy this fix in an enterprise environment; you need to install it on all your machines and also run a script (which you must write, test, and debug) on all your machines to perform the unserialization/reserialization.

Later today I will post a tool to help you create a standard Apple package to perform these steps. If you have some way to distribute and install Apple packages on your machines, you’ll be able to do the unserialization/reserialization by installing a package.

Check back later!

Advertisement

Adobe CS6 Serialization fun

Recently (starting some time after the first of the year), we’ve started having users call and tell us that their formerly working install of Adobe Photoshop CS6 was now asking for a sign-in:

We could not figure out why this was happening. An uninstall and reinstall of our AAMEE3-generated installation package seemed to get things working. But then the same users would call back the next day with the same issue.

MacTech Conference 2012

MacTech Conference 2012 is a little over two weeks away! If you haven’t registered yet, get $400 off the regular registration price by following this link: http://www.mactech.com/events/IKnowASpeaker

I’ll be presenting again this year. More exciting, on Wednesday evening, October 17th, MacTech Conference attendees will be guests at a special event at Walt Disney Animation Studios. Not only will they get a behind-the-scenes look at the Animation Studios and talk with Disney technologists and artists, but also have a rare look at how Walt Disney Animation Studios uses advanced technology to create their animated films.

I look forward to seeing you there!

Flashpoint and Counterpoint

TGB is back with more interesting comments.

Thanks for your comments, TGB! Let me respond to a few:

Vendor-supplied DMGs are standard for distribution, however they are not standard for deployment.

You say that only because your deployment software doesn’t support deploying  directly from a drag-n-drop disk image. I think this is a case where we should bow to reality — since a lot of software is distributed this way, your software deployment system should make it easy to deploy software distributed in this format.

Default settings are part of deployment. They simply are.

Most consumers seem to be able to purchase, install and use third-party software with the default settings as chosen by the vendor. We find that also to be the case in our environment — we don’t have to customize settings very often. But when we do, we have lots of available tools to do so. Not having to (re)package the software itself gives us more time to spend on adding value for our organization.

I’m completely comfortable packaging Flash by hand.

That’s great. So am I. But not every admin is, judging by all the packaging questions I’ve seen. More importantly, what’s the value of hundreds or thousands of admins repeating the same task, but perhaps doing it slightly differently? Let’s have the vendor do that work.

I don’t work in a rigid corporate environment.

Neither do I!

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.

Flash Mob

My recent posts on deploying Flash Player 11.3 and 11.4 have generated a lot of comments. Some frequent themes: “Why are you bothering with all this? Just deploy the embedded package and be done with it!” and “Just repackage it with PackageMaker/Composer/etc and push that package!” These are certainly valid approaches you might decide to use in your organization.

But I worry that the larger point is being missed.

By recommending and supporting a non-standard deployment mechanism, Adobe is forcing enterprise admins to make choices about how to deploy their software. Some of those choices break the auto-update mechanism. Some are cumbersome to implement. Even Adobe’s recommended solution has several failure modes. But most importantly, it creates more work for the admin, since Adobe’s Flash distribution is not deployable as-is.

This is a colossal waste of time in the aggregate. Not only do I have to waste time packaging, repackaging or otherwise wrapping or modifying the Flash installer in order to deploy it; I must do so for each new release of Flash. And so must thousands of other admins all over the world.

Worse, because of all the possible choices (and no clear winner among them), there’s going to be many different permutations of what gets installed and how. This lack of consistency is a real problem, and must create additional support burdens, not only for local support, but for Adobe itself, as Adobe can’t even count on what is installed. I’m sure Adobe would like to get new releases of Flash out there as fast as possible; their choices actually make that harder to accomplish.

The only real path out of this madness is for Adobe to adopt and support a standard software distribution mechanism on Mac OS X: Apple packages. Enterprise admins should be able to take a Flash Player package and import it into their software distribution system without additional modification.

Part of the issue here is that there appears to be two parts to Adobe Flash Player: the actual Flash plugin, and the auto-update mechanism. These appear to be developed by two different teams. The team developing the Flash plugin itself seems to be doing (mostly) the right thing — they ship the Flash Player plugin as an Apple package that works perfectly with enterprise deployment tools.

The team responsible for the updater, however, is using non-standard deployment tools, leaving us with a mess. Not only is the installation a problem, but the updater doesn’t work when no-one is logged in. This was a nasty problem with Flash Player 11.3; the “fix” in Flash Player 11.4 seems to be that the updater just refuses to run if no-one is logged in. Here’s hoping that’s a temporary/quick fix until the “real” fix is in.

AFP548.com New Look

AFP548.com introduced a new look today. Lots of new, great articles on the site, including one by yours truly:

http://afp548.com/2012/06/05/skinning-a-cat-lots-of-ways-to-deploy-lion/

 

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:

Mac App Store

If, like me, your job involves managing large numbers of Macs, yesterday’s announcement of the upcoming Mac App Store probably raises questions. Here’s a few I have.

In the Mac App Store demo on Wednesday’s Apple Event, the presenter bought and installed Pages without being asked for an admin password. Presumably that will be the experience when using the Mac App Store. So how does that work? A couple of possibilities:

1. The App Store runs with special privileges, and can install apps for the user without needing admin credentials.
2. Mac App Store applications are installed somewhere the user has rights to modify without elevating privileges — like their own home directory.

Parts of the new Mac App Store Guidelines have leaked on the web, and there’s evidence that the second possibility is the “right” one:

Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations. Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected.

By requiring that all Mac App Store apps be self-contained bundles, it makes it possible to “install” such an app simply by copying it anywhere the user has write access. This could be in the user’s home, or possibly a new location created when the new Mac App Store debuts. Time will tell. This also means that “uninstalling” such an app is simple as well — just delete the app bundle.

If the download/install location is within the user’s home directory, that implies some other issues:

1. Apps downloaded and installed by one user of a machine will not be usable by another user of the same machine.
2. Users with network home directories may run into quota issues, or find their apps don’t behave perfectly when run from their network home
3. If your organization backs up user data and/or transfers it from a user’s old machine to a new one, you now have a whole new class of “data” to worry about.

If the Mac App Store installs apps in a globally writable space outside any user’s home — something like /Users/Shared/Apps/, some of the above issues no longer apply, but new issues might raise their head:

1. Can a user delete an app purchased, downloaded, and installed by another user?
2. Can a user update an app installed by another user?
3. If you migrate local user data from a user’s old machine to a new one, this will be a new location to be worried about.

So let’s assume that non-privileged users will be able to buy, download, and install apps using the Mac App Store. Will you as an administrator have any control over this?

It seems likely that you could exercise draconian control simply by not installing the Mac App Store application when it becomes available, or removing it on machines on which it is pre-installed. But we can hope for more fine-grained control via MCX.

Hopefully, more answers will be available in the next 90 days…

More Adobe Installer disappointments

By now it’s fairly well-known that the current installer for the Adobe CS5 products has a serious shortcoming: it fails when no-one is logged in. As this normally an ideal state in which to deploy software in enterprise environments (no-one is logged in, so you don’t have to worry about interfering with a user’s work, or worry that users will attempt to use applications that are being installed/updated/removed), this is a big problem. Adobe plans to address this in the future.

I thought I’d check to see if a similar issue affects the AdobePatchInstaller.app that is part of the Adobe CS5 updaters.

At least for the Adobe Bridge CS5 4.0.2 update, it fails when no-one is logged in, but for different reasons that the failure of a CS5 product install. Here’s the end of the log of a failed session:


-------------------------------------- Summary --------------------------------------
- 1 fatal error(s), 3 error(s), 1 warning(s)
WARNING: Display requirements not met for {2C8FBE83-2D3E-4CE6-A912-4BED85BCAC06}
ERROR: Unable to locate folder for token UserInternetPlugins.
ERROR: The following payload errors were found during install:
ERROR: - Adobe Bridge CS5_4.0.2_AdobeBridge4-mul: Install failed
FATAL ERROR: Database file 'Install.db' does not exist.

Search the same string above to find when the error occured.
-------------------------------------------------------------------------------------
Exit Code: 7 - Unable to complete Silent workflow
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
END - Installer Session
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*


This looks to me like it’s failing because it’s looking for the InternetPlugins folder for the current user, and since there _is_ no current user, it aborts.

If I log in to the GUI and try again, it succeeds:


-------------------------------------- Summary --------------------------------------
- 0 fatal error(s), 0 error(s), 0 warning(s)
-------------------------------------------------------------------------------------
Exit Code: 0 - No error
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
END - Installer Session
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*


It’s beyond exasperating.