Adobe Acrobat Pro 9 (CS5 Suite) – Silent Install and Serialization

[Dee]

Dear All,

I’m facing issues deploying Adobe Acrobat 9 as part of CS5.
We know that Adobe has released a tool to create the apple packages for the CS5 products but not for Adobe Acrobat which is also being included with a different serial number.

I would like to have it serialized (unfortunately I have different serials) during the imaging process or the deployment without creates single packages for single serials.

Googleizing I found this links but is not working for me.

Is someone out there using this method with more luck than me?

——————————————————————————
I’ve seen a few questions about installing Acrobat 9 Pro silently on Mac OS X. Maybe someone’s already dealt with this, but I thought it might be helpful. Installing Acrobat 9 Pro silently (and across multiple machines) is possible. I have not, however, figured out how to install Acrobat 9 updates silently (I could just be missing some documentation), so if anyone has any clues on this, please let me know.

The key to installing Acrobat 9 Pro silently is licensing the application silently. This isn’t documented (as far as I can tell), but you can use an application.xml.override file ( as outlined by the CS3 deployment docs: <http://www.adobe.com/support/deployment/cs3_deployment.pdf> ) to put in the license information. This file goes in “/Contents/Resources/AMT/”.

So here’s a possible workflow for setting up a silent install:
1) package Acrobat 9 in a .pkg using Package Maker or a similar tool
2) create an application.xml.override file like so, replacing “YOUR KEY GOES HERE” with your key:

YOUR KEY GOES HERE
Suppress
Suprress
Suppress

3) write a shell script that installs the .pkg via installer (installer -pkg “Acrobat 9 Pro.pkg” -target /) and copies the application.xml.override to the correct directory (cp application.xml.override “/Applications/Adobe Acrobat 9 Pro/Adobe Acrobat Pro.app/Contents/Resources/AMT/application.xml.override”)
4) run the shell script with root privileges (via sudo) and you’re done!

thanks

Dee

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

[Dee]

Hi bskinner,

“finally” (NOT) i put myself into it again.
I’m testing the application.xml editing and seems it is working. I’ll back if I find issues.

Thanks for your replay

Dee

[sketch]

Could you please me more detailed as to the edits you made to the application.xml file?
Thanks

[QUOTE][u]Quote by: bskinner[/u][p]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.[/p][/QUOTE]

[Author]

Posts