Adobe Enterprise Deployment Toolkit versus disk images…

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.


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 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 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 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.

Adobe Enterprise Deployment Toolkit versus disk images…

2 thoughts on “Adobe Enterprise Deployment Toolkit versus disk images…

Comments are closed.