One of the more visited articles on this site is several years old – this one on adding a user to the local admin group.

I thought I should update that information since it is somewhat out of date. Apple’s preferred and recommended way to add a user to the local admin group is to use dseditgroup, like so:


/usr/sbin/dseditgroup -o edit -a gneagle -t user admin


This -a(dds) “gneagle”, which is an object of -t(ype) “user”, to the group “admin”.

To delete a user from the local admin group:


/usr/sbin/dseditgroup -o edit -d gneagle -t user admin


You can also use dseditgroup on a network directory service if you have admin credentials for the directory server:


dseditgroup -o edit -n /LDAPv3/ldap.company.com -u dsadminusername -p -a gneagle -t user group_on_network_directory


This will prompt you for the dsadminusername’s password interactively. You can include the dsadminuser’s password like so:


dseditgroup -o edit -n /LDAPv3/ldap.company.com -u dsadminusername -P dsadminuserpassword -a gneagle -t user group_on_network_directory


dseditgroup can do many other things, like create and delete groups, add nested groups to an existing group, and check membership of a given user for a given group.

man dseditgroup for more info.

On the MacEnterprise list recently, there was a discussion about installing Firefox extensions.

Specifically, the originator of the thread wanted to install a PDF plugin for Firefox so all users of a machine could use it without having to manually install it.

I had looked at this issue a while back, and didn’t find a satisfactory solution.

Here were the options I saw:

1. Just let users install it themselves. Since by default, Firefox extensions install in their Firefox profile in their home directory, this is possible. But the user has to know to look for the extension, download it and install it. Plus, as a policy, you may not want to encourage users to download and install software themselves.
2. Follow the instructions in this mozillaZine article to install a global extension. This installs the extension inside the Firefox application bundle and makes it available to all users. But each time a new version of Firefox is released, you’ll have to do this again, which quickly becomes a pain. Additionally, in my testing, this method doesn’t actually make the extension directly available; instead, on the next launch the user is prompted to install it.

Neither option appealed to me, but since the first was no more work for me, I went with that. But in the MacEnterprise discussion this Mozilla link was brought up, which describes a new option for Firefox 3 and later.

Basically, you just need to copy the extension to


/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}


and it becomes available to all users of the machine. Since it’s not in the Firefox application bundle, it can survive updates to the Firefox application.

I found that instead of copying the .xpi file there, I got better results by first installing the extension into my user profile, then copying the installed extension to the directory above. The PDF plugin installs in a directory named “colesbury@gmail.com”, so the process looks something like this:


cd /Users/gneagle/Library/Application\ Support/Firefox/Profiles/cuak0rwz.default/extensions
cp -R colesbury@gmail.com /Library/Application\ Support/Mozilla/Extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/


The extension is now available to all users, and the users are NOT prompted to install it — it just works. Even better, you can package it up and deliver it to all your machines via radmind, ARD, Casper, etc.

One of the most-visited articles I’ve written here is one on managing Firefox default settings. I continue to get questions about this, so I thought it was time to revisit the issue.

I still use the basic techniques described in the original article. But I’ve made two changes worth pointing out.

Originally, I edited two existing files and added a third file. But now, I just add two files.

The first file tells Firefox to use your new config file.

Create a new file: /Applications/Firefox.app/Contents/MacOS/defaults/pref/local-settings.js

(Note: an earlier version of the post took the MozillaZine article at its word and used a different path: /Applications/Firefox.app/Contents/MacOS/greprefs/local-settings.js – and I posted without testing. I’ve actually been using the /Applications/Firefox.app/Contents/MacOS/defaults/pref/local-settings.js path, and it works…)

Edit the contents like so:


// MyOrganization additions
pref("general.config.obscure_value", 0);
pref("general.config.filename", "firefox_AA.cfg");


Now the actual configuration file:

Create a new file: /Applications/Firefox.app/Contents/MacOS/firefox_AA.cfg.
For our implementation , the contents are similar to:


// This file sets some default prefs for use at MyOrg
// and locks down some other prefs.
//
// proxy
pref("network.proxy.autoconfig_url", "http://www.myorg.com/auto.proxy");
pref("network.proxy.type", 2);
//
// application updates
lockPref("app.update.enabled", false);
lockPref("app.update.autoUpdateEnabled", false);
lockPref("extensions.update.autoUpdate", false);
lockPref("extensions.update.enabled", false);
lockPref("browser.search.update", false);
//
// Password Manager
pref("signon.rememberSignons", false);
//
// Default browser check
pref("browser.shell.checkDefaultBrowser", false);
//
// Home page
pref("browser.startup.homepage","http://www.myorg.com");
pref("browser.startup.homepage_reset","http://www.myorg.com");


Make sure the first line starts with double slashes as in the example above – if the first line isn’t comment, it doesn’t work.

We’ve moved the homepage settings into our Firefox_AA.cfg file; previously we were editing /Applications/Firefox.app/Contents/MacOS/browserconfig.properties.

Since we’re now dropping in two new files, instead of editing existing files, this is much easier to package up and deploy.

For more information about this technique, and more info on how to find more settings you can manage, check out this mozillaZine article:
http://kb.mozillazine.org/Lock_Prefs

Note that in the mozillaZine article, they encode the .cfg file using ROT13. I don’t bother for my deployment, but if you need to obscure the values in the .cfg file, you can. If you do so, be sure to remove the “pref(“general.config.obscure_value”, 0);” line from the local-settings.js file.

If you try this and have problems, make sure the two files are plain text and the names don’t have a hidden extra extension — some people tried using TextEdit with its default settings to make these files and ended up with files named “local-settings.js.rtf” or “local-settings.js.txt”…

When doing unattended installs of suites of software, sometimes you want to install something other than the default set of applications and add-ons. For example, if you are doing a remote/unattended install of iLife ‘09, maybe you want to install only iDVD, iPhoto, and iMovie, and leave off iWeb and GarageBand.

With most Apple packages, you can specify a “ChoiceChangesXML” file, which tells the command-line installer to make changes to the choices of what to install. For example, this XML file tells /usr/sbin/installer to install only iPhoto from the iLife ‘09 install media:

<array>
    <dict>
        <key>attributeSetting</key>
        <false/>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>iDVD</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <false/>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>iMovie</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <false/>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>GarageBand</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <false/>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>iLifeSoundEffects</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <false/>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>iWeb</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
        <true/>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>iPhoto</string>
    </dict>
</array>

It’s used like this:

/usr/sbin/installer -applyChoiceChangesXML choicesXMLpath -pkg pkgPath -target /

Variations on this XML can be used to install various combination of the individual tools in iLife ‘09.

Unfortunately, at least in my testing, this technique fails completely when trying to install parts of Final Cut Studio 3. No matter what I tried, the installer seemed to ignore the ChoiceChangesXML file.

But I wanted to be able to install only Final Cut Pro (and the required helper apps) on some machines, and not install DVD Studio Pro, Soundtrack Pro, Motion, and Color. Other machines might get only Final Cut Pro and DVD Studio Pro. Here’s how I solved the problem.

In the Final Cut Studio 3 install media, the actual install package is a metapackage located at <path to Final Cut Studio Install media>/Installer/FinalCutStudio.mpkg.

FinalCutStudio.mpkg is a bundle, and inside the bundle’s Contents directory is a FinalCutStudio.dist file. This .dist file is actually an XML file, and included within are the various choices and paths to the actual install packages for each choice.

So: I made a read/write disk image of the install DVD and mounted it. I then duplicated the FinalCutStudio.mpkg and named it FinalCutProOnly.mpkg. Inside the bundle, I renamed “FinalCutStudio.dist” to “FinalCutoProOnly.dist”. Then I set to work editing the .dist file.

Within the .dist XML are a series of <choice> items, each describing an installation choice. Each choice has some interesting attributes: “start_enabled” and “start_selected”. In the original XML, some of these are set to true, some are set of false, some are set to the value of a JavaScript function. I went through these items slowly and for the items I did not want installed, I set “start_selected” to false:

start_selected='false'

When I was done, I had a new metapackage that installed only Final Cut Pro from the Final Cut Studio media. I repeated the technique with the other major apps in the Suite, and now I can install any required combination of the core apps. The Installer directory now looks like this:


ls -1 /Volumes/Final\ Cut\ Studio\ Install/Installer
ColorOnly.mpkg/
DVDStudioProOnly.mpkg/
FinalCutProOnly.mpkg/
FinalCutStudio.mpkg/
MotionOnly.mpkg/
Packages/
SoundtrackProOnly.mpkg/


Since the actual packages are in the Packages sub-directory, the additional mpkgs don’t take up much additional space. I then converted the disk image back to read-only compressed.

Editing the dist files was tedious and required trial-and-error to get to the result I wanted. So I’ve zipped them up and you can download them here.

To use them, you’ll still need to duplicate the FinalCutStudio.mpkg as described above, but instead of having to edit the dist file yourself, you can just replace it with mine. Be sure to test – while this works for me on the machines I manage, there’s always a chance that things may behave differently in different environments.

You could use this technique with any dist-based metapackage installer, so this might be applicable for other install problems.

Silent installs of Adobe products are a bane of an OS X administrator’s existence. However, there are some officially supported methods to do silent installs of CS3/CS4 apps, and even to install updates to those apps.

Some links:

CS3 Deployment
CS4 Manual Deployment
CS4 Enterprise Deployment Toolkit

But updates to Acrobat Pro 9 are in a completely different format than all other Adobe installers/updaters and can’t be silently installed with any of the supported methods.

I started tearing apart the patching app on one of the update disk images and discovered it was running some shell and Python scripts to do the actual patching. That got the wheels turning…

The result: a Python script you can use to silently install all of the (so far) released updates to Acrobat Pro 9.

This script skips all of the process checking done by the original patching app, so it’s best to run it when no-one is logged in.

You could use this script via SSH or ARD to install the updates:

Install the script itself somewhere on the target machine. Copy the needed disk images to the target machine. Install each update in order, something like this:


./updateAcrobatNine.py /path/to/AcroProUpd910_all.dmg
./updateAcrobatNine.py /path/to/AcroProUpd911_all.dmg
./updateAcrobatNine.py /path/to/AcroProUpd912_all.dmg
./updateAcrobatNine.py /path/to/AcroProUpd913_all.dmg
./updateAcrobatNine.py /path/to/AcroProUpd920_all.dmg


Here’s some output from an install session:


root# ./updateAcrobatNine.py AcroProUpd910_all.dmg
Mounting disk image AcroProUpd910_all.dmg
Searching for Adobe Acrobat Pro.app
Getting info on currently installed applications...
Updating Adobe Acrobat Pro.app
Updater log at /var/root/Library/Logs/Adobe/Acrobat/Acrobat 9 Pro Patch0.log
Patching Adobe Acrobat Pro.app complete.
Searching for Acrobat Distiller.app
Updating Acrobat Distiller.app
Updater log at /var/root/Library/Logs/Adobe/Acrobat/Acrobat 9 Pro Patch1.log
Patching Acrobat Distiller.app complete.
Searching for Acrobat Uninstaller.app
Updating Acrobat Uninstaller.app
Updater log at /var/root/Library/Logs/Adobe/Acrobat/Acrobat 9 Pro Patch2.log
Patching Acrobat Uninstaller.app complete.
Done.


Enjoy.

ADDENDUM:

If you do install Acrobat Pro 9 updates, unattended uninstalls using the methods from the Adobe Enterprise Deployment Toolkit now fail, because Adobe Setup no longer thinks Acrobat Pro 9 is installed and gets very confused. Manual uninstalls using the uninstaller in /Applications/Utilities/Adobe Installers still work, though. Grrrr….

Since we’ve examined some ways to script around Software Update’s limitations, I thought maybe now would be a good time to describe changes I’d like to see to Apple’s Software Update so we don’t have to hack at it…

When a client is managed via MCX to use an internal Software Update Server, there should be an additional management option that causes Apple Software Update to behave in the following manner:

1. Available updates are downloaded in the background. (This exists currently)
2. When all available updates have been downloaded, if a user is logged in, the user is notified that updates are available (This also exists currently)
3. When the user clicks “Install”, the updates should be installed without requiring administrator credentials. Since the admin has “approved” the updates by making them available on the internal Software Update Server, and has enabled the proposed “non-admin” install option via MCX client management, no further administrative approval should be needed/required. (This would be new behavior).
4. If no user is currently logged in, all managed updates (those on the internal SUS) are installed, but there is a progress window displayed over/instead of the loginwindow so a user does not login or power off a machine during a software update session. (This would be new behavior).

These changes would allow systems administrators to deploy Apple software updates to a group of machines without resorting to scripting hacks, running background command-line processes that can interfere with active users, or third-party tools that largely (and incompletely) duplicate Apple’s solutions.

In addition:

1. Admins should be able to mark updates on their internal Software Update Servers as mandatory.
2. When an OS X Client is managed to use an internal SUS, updates marked as mandatory should not be able to be deselected by the user.

This change would allow systems administrators to use an internal Software Update Server to deploy critical updates (like Security Updates) without resorting to scripting hacks or third-party tools.

At work, I’ve been working on a solution for handling Apple Software Updates for non-administrative users. Each approach I’ve tried has serious obstacles. Here’s a brief history of what I’ve tried and what worked and what didn’t.

First, a little background: Apple provides a Software Update Server as part of Mac OS X Server. This allows you to cache Apple’s updates on a local server for more efficient use of Internet bandwidth, and more importantly, a local Software Update Server allows you to choose which items you want to make available to your organization — for example, you can choose to not make an update available to machines in your organization until after you’ve finished testing it in your environment.

But hosting a local Software Update Server does not solve a fundamental problem: how to get the updates onto a machine without requiring administrator privileges for the machine’s user(s). Hosting a local Software Update Server is no different than relying on Apple’s servers in this regard; someone must authorize Software Update.app with administrative credentials.

So if you want to use Software Update to distribute updates to your machine, this means either providing all your users with administrative credentials, or having admins visit each machine. It would be better if we could find a way to install updates without requiring a user to type in an admin password.

If you are using a third-party solution for installing software and handling non-Apple updates, something like radmind, LANrev, FileWave, or Casper, these products may have their own mechanisms for handling Apple Software Updates. If they don’t, you always have the option of downloading the updates from Apple and importing them into your management system just as you would any third-party software.

But a downside to doing this is that you may lose the logic Apple uses to determine which updates are applicable to each machine. You may find yourself having to replicate this logic in some way. The larger the number of unique hardware and software configurations you have, the harder and more tedious this becomes. So you may want to find a way to leverage Apple’s tools.

The obvious first approach: as root (via cron, launchd, ARD or ssh), run the command-line Software Update tool:

/usr/sbin/softwareupdate -i -a

This is simple, but has several problems:

1. The only safe time to do this is when no-one is logged in, since a restart may be required, or applications that are in use might be updated. But if you do it when no-one is logged in, and you provide no user feedback as to what is happening, you run the risk that the user will shutdown, restart, or log in while the process is happening. The first two could cause you to have an unbootable machine; a user logging in could be a problem if a restart is required or the user attempts to use applications that are being updated.
2. Since a user might be waiting to use the machine while this process is happening, ideally you’d want to have some sort of progress indicator, and also you’d like to do the downloads separately from the install so that the time your users are forced to be logged out is minimized. But /usr/sbin/softwareupdate’s output is almost impossible to use to construct meaningful progress info, and it has no way to download items in advance.
3. You are thinking “But what about softwareupdate -d -a? Doesn’t that download all the available updates?” Why yes, it does. Unfortunately, there’s no way to tell softwareupdate to use those downloads, if you later run softwareupdate -i -a, it will download them all over again.

If you are willing to make the user wait for the entire download and install process while the machine is logged out with no real progress feedback, then this approach might work. If you have a bunch of desktop machines that will be on (or can be set to wake up/power up) in the wee hours of the morning, this approach might work, as the lengthy updating can happen when no-one is around. If, on the other hand, you have a large number of laptop machines, this approach is less likely to be accepted by your users. They’ll have to participate in the updating of their machines, and won’t like having no indication of how long an update might take. They are more likely to get annoyed or impatient and simply turn off the machine in the middle of the update, because it may appear that the machine is locked up.

So that brings us to the next approach: again, with a script running as root, use softwareupdate -d -a to find and download the available updates, then use /usr/sbin/installer to install them. This seems promising, because /usr/sbin/installer gives reasonable progress feedback that you could then pass to the user.

Unfortunately, not everything downloaded via softwareupdate -d -a is in a format that /usr/sbin/installer knows how to install. And so far, I haven’t been able to preflight these items to know in advance what can be successfully installed and what cannot — you just have to try and see if /usr/sbin/installer throws an installation error back at you. So unless we can figure out how to detect and deal with the “broken” downloads, this is not an ideal solution, as there will be updates that are not installable via this method.

Now for the third approach.

It is possible to trigger the process that downloads updates in the background into /Library/Updates/ — the same one that, when updates are available, then opens the Software Update.app and prompts you to install them. (On Snow Leopard, this is essentially the same thing as running softwareupdate -d -a; on Leopard, softwareupdate -d -a does something different, downloading them into the Downloads directory of the current user.)

Once these items are staged in /Library/Updates, you can re-write the /Library/Updates/index.plist and touch a file to tell Software Update to install these upon restart; this is a variation of the built-in behavior when you use the Software Update app and choose to install items that require a restart – you are logged out, the items are installed, and then the machine is restarted.

Here’s a shell script that gets the basic steps done:

#!/bin/sh

defaults -currentHost write com.apple.SoftwareUpdate AgreedToLicenseAgrement -bool YES
defaults -currentHost write com.apple.SoftwareUpdate AutomaticDownload -bool YES
defaults -currentHost write com.apple.SoftwareUpdate LaunchAppInBackground -bool YES

#Take away execute & read rights so Software Update doesn't open during a user session
chmod 700 /System/Library/CoreServices/Software\ Update.app
#Check for new updates
/System/Library/CoreServices/Software\ Update.app/Contents/Resources/SoftwareUpdateCheck
#Put execute and read rights back
chmod 755 /System/Library/CoreServices/Software\ Update.app

#This sets up all the files so that it will install on restart
installarray=`defaults read /Library/Updates/index ProductPaths | grep -v "[{}]" | awk -F "=" '{print $1}' | grep -o "[^\" ]\+"`
defaults write /Library/Updates/index InstallAtLogout -array "$installarray"
touch /var/db/.SoftwareUpdateAtLogout
chmod og-r /var/db/.SoftwareUpdateAtLogout

Leveraging this has several attractions: you are using Apple’s processes and logic for installing updates; you get progress feedback for free, since you are using Apple’s tools, and the updates can be downloaded in advance, minimizing the time required at logout to install the updates.

There are some drawbacks:

• You have to trigger a restart to initiate the install; even for items that don’t require a restart.
• When the restart is triggered, a dialog appears telling the user there are updates to be installed and giving them two choices “Restart”, or “Install and Restart”. While it’s good to have the choice, it’s an additional bit of noise if you’ve already asked them to restart to install the updates.
• And the big one: there’s no clean, Apple-supported way to programmatically trigger the install if you are already sitting at the loginwindow.

  If a user is logged in, you can do this:

  osascript -e 'tell application "System Events" to restart

  But if no user is logged in, the above doesn’t work. If you do shutdown -r now, the machine just restarts without installing. If you click the Restart button in the loginwindow, you are prompted to allow the installs to happen, which is what we want. It turns out that in Leopard and Snow Leopard, after a little setup, we can do just that programmatically with:

  osascript -e 'tell application "System Events" to tell process "SecurityAgent" to click button "Restart" of window 1'

  This doesn’t work, obviously, if the administrator (or user!) has disabled the Restart button from appearing in the loginwindow, so it’s not particularly robust, but it’s the best we have right now.

A fourth approach:

A script running as root launches the Software Update.app:

#/bin/sh
/System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update

Ideally, you’d use a launchd job that watched a path writable by non-privileged users. When that path was modified, the launchd job would fire, launching Software Update as root.

Advantages:

• Once Software Update is running as root, the user can download and install anything Software Update makes available without having to enter administrative credentials.
• You’re using even more of Apple’s code and relying less on your own, making this a robust solution.

Possible disadvantages:

• The user can choose to not install some items — this could make it more difficult to apply Security Updates in a timely manner
• Since Software Update.app is running as root, there are potential security risks; it might be possible to use a flaw in Software Update.app to can root privileges elsewhere.
• This approach doesn’t help you install updates when no-one is logged in; it only works with user involvement and cooperation.

So there you are. Four ways to get Apple Software Updates installed on machines without requiring your end users have administrative credentials.

No one approach works in all situations, but perhaps one of these approaches will work for you.

While digging into the Adobe install process, I needed to be able to translate from “AdobeCodes” like “{27B54140-8302-4B5D-83DD-AEE4B18BC7A4}” to product names like “Adobe Encore CS4″ and the installer payload name like “AdobeEncore4All”.

I ended up writing a Python script to crawl through the payloads directory of Adobe install media to generate a table. The script is below, and called like:

python adobeparser.py /path/to/payloads

It’s probably not generally useful, though I include it just for completeness…

#!/usr/bin/env python
# encoding: utf-8
"""
adobeparser.py

Created by Greg Neagle on 2009-10-07.
"""

import sys
import os
import optparse
from xml.dom import minidom

def parseAdobeProxyXML(filename):
    payloadinfo = {}
    dom = minidom.parse(filename)
    installer_properties = dom.getElementsByTagName("InstallerProperties")
    if installer_properties:
        properties = installer_properties[0].getElementsByTagName("Property")
        if properties:
            for prop in properties:
                if 'name' in prop.attributes.keys():
                    propertyname = prop.attributes['name'].value
                    propertyvalue = ""
                    for node in prop.childNodes:
                        propertyvalue += node.nodeValue
                    payloadinfo[propertyname] = propertyvalue

    return payloadinfo

def analyzePayloads(dirname):
    payloads = []
    dirname = dirname.rstrip("/")
    if dirname.endswith('payloads'):
        for payloaditem in os.listdir(dirname):
            payloaditempath = os.path.join(dirname, payloaditem)
            if os.path.isdir(payloaditempath):
                for item in os.listdir(payloaditempath):
                    if item.endswith(".proxy.xml"):
                        proxyxmlfile = os.path.join(payloaditempath, item)
                        payloadinfo = parseAdobeProxyXML(proxyxmlfile)
                        payloadinfo['ComponentName'] = payloaditem
                        if payloadinfo:
                            payloads.append(payloadinfo)
                        break

    return payloads

def main():
    p = optparse.OptionParser()
    options, arguments = p.parse_args()
    if arguments:
        payloads = analyzePayloads(arguments[0])
        print "Adobe Code\tName\tVersion"
        for payload in payloads:
            print "%s\t%s\t%s\t%s" % (payload['AdobeCode'], payload['ProductName'], payload['ProductVersion'], payload['ComponentName'])

if __name__ == '__main__':
	main()

I ran this script against the payloads folder on the Adobe CS4 Master Collection installation media. I then sorted the output by AdobeCode and added a header line, and here is the result: a tab-delimited list of AdobeCodes, ProductNames, ProductVersions, and PayloadNames.

I hope this list is useful to someone other than me! Combine this with the info here and you can get a pretty good idea of everything that’s installed.

This post will act as a running log of today’s struggles with the CS4 Deployment Toolkit. This post was updated several times today, so if you read it earlier today, there may be new stuff added….

• Start with the install media for Adobe CS4 Master Collection.
• Run the CS4 Deployment Toolkit app and create a “package” that installs only Flash, Dreamweaver, Fireworks, and Contribute.
• Move the package and install media files to the test machine
• Run the AdobeUberInstaller

Result?

Flash, Dreamweaver, Fireworks and Contribute are installed. But…

So are:
After Effects, Encore, Premiere Pro, and Soundbooth. Or are they?

The application folders are there, but inside: broken apps.

Sheesh.

If you look at the AdobeUberInstaller.xml generated by the CS4 Deployment Toolkit, and go through the painful process of translating “AdobeCodes” like “{3EE73408-5536-4C99-9CEB-06C2A7A726B4}” into product names, we find that After Effects, Encore, Premiere Pro, and Soundbooth are not referenced at all in the XML file. I definitely unchecked them in the CS4 Deployment Toolkit, but they are not mentioned at all. Perhaps the default behavior is supposed to be “donotinstall”, but in actual practice, it seems to be something else.

In my case, the observed behavior is “partially install as broken”.

So I tried a few things; including manually editing the AdobeUberInstall.xml file, adding explicit “donotinstall” actions for the four unwanted apps:

	<!--added by gneagle-->
        <!--Adobe After Effects CS4-->
        <Payload adobeCode="{F706302E-1402-4D8D-8ABB-26B18ECAEFBB}">
          <Action>donotinstall</Action>
        </Payload>
        <!--Adobe Encore CS4-->
        <Payload adobeCode="{27B54140-8302-4B5D-83DD-AEE4B18BC7A4}">
          <Action>donotinstall</Action>
        </Payload>
        <!--Adobe Premiere Pro CS4-->
        <Payload adobeCode="{21EEB50A-C615-4B7B-928B-4262121A7C78}">
          <Action>donotinstall</Action>
        </Payload>
        <!--Adobe Soundbooth CS4-->
        <Payload adobeCode="{5AC26AE4-130C-4296-9BA8-563A99AE1946}">
          <Action>donotinstall</Action>
        </Payload>

But still no go – directories were still created under /Applications with broken application bundles for Premiere, After Effects, Soundbooth, and Encore.

So I started poking through the install log in /Library/Logs/Adobe/Installers, in this case named “Adobe Creative Suite 4 Master Collection 4.0 10-07-2009.log”.

I found a section that looked like this:

BEGIN InstallOperationsQueue Unordered operations
  {02FD2912-C5C4-41f0-B7D2-0C1871EB9565} Adobe Flash CS4 Extension - Flash Lite STI es: with operation none
  {046EB5D9-BDAB-4D5A-BC23-45583F6B8EF0} Adobe Premiere Pro CS4 Functional Content: with operation none
  {064F0D64-1F54-4F4B-953E-BAED5D7E69B2} PDF Settings CS4: with operation install

This looked promising. Buried in this section of the log were these lines (they weren’t all next to one another; I’ve put them all together here for brevity):

{0AEC3900-1F89-4649-9D10-B0469D5F6A0B} Adobe Premiere Pro CS4 Third Party Content: with operation install
{D5AD1A24-F381-4D67-BA1C-A2661AEB06A5} Adobe Soundbooth CS4 Codecs: with operation install
{575C8FA0-8180-4554-828A-1AD52446CAA1} Adobe Encore CS4 Codecs: with operation install
{568E0A79-996C-4B04-B613-F06CBE7B320B} Adobe After Effects CS4 Third Party Content: with operation install

Aha!

Somehow, some subcomponents for Premiere, Soundbooth, Encore, and After Effects were being selected for install. A peek inside the broken application bundles seemed to match the payload descriptions above, so I think I’ve found the culprit.

Now to figure out how I can get these items deselected for install…

Back to CS4 Deployment Toolkit.

Start creating a package. Point it at the install files for the CS4 Master Collection. Proceed to the Product Options screen and search for:

Adobe After Effects CS4 Third Party Content
Adobe Premiere Pro CS4 Third Party Content
Adobe Soundbooth CS4 Codecs
Adobe Encore CS4 Codecs

They do not exist in the GUI, and cannot be deselected! Grrrr….

No matter – I’ll just add them manually to the AdobeUberInstaller.xml file:

<!--added by gneagle-->
<!--Adobe Premiere Pro CS4 Third Party Content-->
<Payload adobeCode="{0AEC3900-1F89-4649-9D10-B0469D5F6A0B}">
  <Action>donotinstall</Action>
</Payload>
<!-- Adobe Soundbooth CS4 Codecs-->
<Payload adobeCode="{D5AD1A24-F381-4D67-BA1C-A2661AEB06A5}">
  <Action>donotinstall</Action>
</Payload>
<!--Adobe Encore CS4 Codecs-->
<Payload adobeCode="{575C8FA0-8180-4554-828A-1AD52446CAA1}">
  <Action>donotinstall</Action>
</Payload>
<!--Adobe After Effects CS4 Third Party Content-->
<Payload adobeCode="{568E0A79-996C-4B04-B613-F06CBE7B320B}">
  <Action>donotinstall</Action>
</Payload>

And now to test…

FAIL. Broken app bundles for After Effects, Encore, Premiere Pro, and Soundbooth.

Is this thing just broken? Let’s go back a bit.

I remove all the Adobe apps and shared files from my test machine (AdobeUberUninstall plus some manual cleanup), and then manually run the Setup.app from the CS4 Master Collection media, and choose the same options I chose with the CS4 Deployment Toolkit.

Same result. Broken app bundles for apps I didn’t choose to install.

So in this case, it’s not the Enterprise Deployment Toolkit that’s failing, it’s the underlying install process — you get the same broken results with a manual install.

After getting lots of suggestions, and spending a few days tearing apart the JavaScript files that are part of the Adobe setup/install process, I have some progress to report on the task of getting Adobe Enterprise Deployment Toolkit “packages” to work from disk images.

I was hoping to wrap up the installation files, the AdobeUber* programs and the AdobeUber*.xml files into a disk image. I could then copy that disk image to a given machine, mount it, and run AdobeUberInstaller.

My initial testing failed miserably – Adobe’s Setup application failed with “Exit Code 7″ when I tried to run the install from a mounted disk image, yet the same files copied to a local folder installed fine.

A little more digging into the various logs, and I found this:

Found deployment properties:
Setting property "INSTALLDIR" to: /Applications
Setting property "installLanguage" to: en_US
[       0] Fri Oct  2 10:23:26 2009 DEBUG
Supported languages:
[       0] Fri Oct  2 10:23:26 2009 FATAL
Exception: Could not get the list of supported languages
Exit code: 7
[       0] Fri Oct  2 10:23:26 2009  INFO

I tore into the various JavaScript files that are part of the install process, and even added some debugging/logging code to some of the JavaScripts so I could see what was happening. I eventually determined that it failed to get the list of supported languages because it was looking in the wrong place for the payloads! Instead of looking under the InstallerLocation path as specified in the AdobeUberInstaller.xml file, it was looking in “/Volumes/Adobe Photoshop CS4/Adobe Photoshop CS4/payloads/”.

Hmmm. That would be the path if we had mounted the original ESD disk media from Adobe. So as an experiment, I simply mounted the original ESD disk image, and tried again with a new AdobeUberInstaller.xml pointing to this path.

Success.

It appears that there is a bug somewhere in the Setup code (and I have looked at the JavaScripts to no avail, so it’s probably buried in the Setup.app itself) that checks to see if the payloads are on a disk image, and then just assumes the original disk image path from there on, ignoring any other info.

You should then be able to get an Adobe deployment to work from disk image one of these ways:

1. Convert the ESD disk to a read-write image and add the AdobeUber* files to it. Optionally convert it back to read-only.
2. Create a separate disk image containing the AdobeUber* files. Deliver this disk image _and_ the ESD diskimage to the target machine. Mount them both, then invoke AdobeUberInstaller from its disk image.
3. Create a new disk image with the AdobeUber* files and the same folder structure to the payloads as the original ESD disk image. Make sure it has the same name for the mounted volume as the original ESD image.
4. Create a new diskimage with the AdobeUber* files, and embed the original ESD disk image inside that image.
5. Some other variation on these.

For all of these, you must mount the disk image containing the installation payloads at the “normal” place – i.e.: /Volumes/Adobe Photoshop CS4 or whatever. No mounting under /tmp or any other fancy handling. You can pass -nobrowse to hdiutil to prevent the mounted disk from showing up in the Finder.

There is one more way to get diskimages to work without jumping through all these hoops, and that is to trick the Setup.app into thinking it’s not a diskimage.

hdiutil attach diskimage.dmg -notremovable -kernel

This makes the OS treat the mounted filesystem as a non-removable disk, and the Adobe Setup.app now acts just like it would if the files are on the local disk. (It’s the ‘-notremovable’ switch that does the magic, but for some reason I kept getting “No mountable filesystems” until I added the ‘-kernel’ switch.) You can even mount it somewhere other than /Volumes (I like -mountRandom /tmp) and you almost certainly want to use -nobrowse.

Thanks to Brian Ling for this method — he originally suggested the ‘-notremovable’ switch and mentioned he needed to add ‘-kernel’ to get this to work in Snow Leopard; it may not be needed in Leopard, but probably doesn’t hurt, either.

There’s a big downside to this approach, however. When you attach a disk image as -notremovable, you cannot detach it completely without a restart. You can unmount any volumes mounted from the image, but the unmounted disk(s) will still show up in `diskutil list` until a reboot.

This is a bit ugly, but may not be a real issue for you, especially if you restart anyway after the installation.

In any case, we now have a few ways to wrap the Adobe Enterprise Deployment packages and their installation files into a disk image we can store on a fileserver which may not support HFS or AFP.

Of course, all is not rosy yet. I’m still fighting with the actual _results_ of the Adobe Enterprise Deployment Toolkit install – it seems to sometimes install things even though I’ve unchecked them using the CS4 Deployment Toolkit…. And the format of the AdobeUberInstaller.xml file, where each component is identified by an “AdobeCode” like “{3EE73408-5536-4C99-9CEB-06C2A7A726B4}” makes investigating this stuff really tedious.