[bskinner]

I am trying to do a similar deployment and I’m running into the same issues; Adobe has made this far from simple. So far we have managed to avoid building a package and simply modified the disk image. I have found two approaches that work most of the time.

[b][u]Adding application.xml.override[/u][/b]
This worked the best initially but ran into issues fairly quickly. In order to preserialize Acrobat, I created the “Contents/Resources/AMT/application.xml.override” directly in the application on the Acrobat 9 disk image but after version 9.0 this stopped working. After setting up a couple of DTrace triggers it looked like the AdobeSelfHealing.framework was to blame. In the initial 9.0 release, it would properly look for the override file in the AMT resources and preserialize Acrobat. In the later versions, however, it completely ignored the file (didn’t even TRY to stat(2) it). I ended up replacing the newer AdobeSelfHealing.framework with the original framework and things started working again. Replacing the framework introduces the chance for some pretty horrible breakage down the line, though.

[b][u]Editing application.xml[/u][/b]
Another approach I tried was adding the Serial, Registration, and other elements to the “application.xml” file. This worked for preserialization but, IIRC, it did not suppress the updates. There were also reports from several people that Acrobat reported errors with the licensing system but they were few and far between and we were unable to definitively point the finger at the application.xml edits as the root cause. Given that the file is signed, I would assume that there is a good chance the edits were causing at least some of the errors.

[Author]

Posts