Silent installs for Acrobat Pro 9 updates

GregN

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

UPDATE 02 July 2012:

I’ve updated the link to the Python script.

Silent installs for Acrobat Pro 9 updates

24 thoughts on “Silent installs for Acrobat Pro 9 updates”

  1. nate says:

    what about hosting the updater dmgs on a web server? hdiutil can mount over http, and it saves the time and bandwidth needed to push the files to client machines.

  2. Sure, you could do that as well. I’m not so certain about bandwidth savings, however – you’re still pushing the same data to the client; either up-front, or “on-demand”…

    1. nate says:

      i’ve been going the http route lately because there’s less to clean up on the clients afterward. even if you dump the dmgs in /tmp or something that will get wiped on boot, they still consume some space. half dozen of one…, i guess.

    1. Hooray!

      There is some chatter that the 9.3.0 update modifies/replaces the SelfHeal.xml files — if you’ve modified them to prevent Acrobat from asking for an admin password upon launch, you may need to modify them again…

  4. Thanks Greg, works great! Except I would like to point out to readers that find this after me that the installer/updater will not complete if you have a previous version of Acrobat installed as well as 9.
    I don’t have time or skills to see why, so I just zipped Acrobat 8 and hope no one complains.

  5. Greg, you’ve made patch management for a truly troublesome application easy. I’m able to quickly take a 9.0.0 install to 9.3.2 in just a few minutes. Thanks a ton for this!

  6. Paul Benham says:

    Thanks so much for this. Hopefully the Acrobat team will take the path of the CS5 team and start making updates a more reasonable process.
    If I wanted to do something similar for Acrobat Reader is there anything I need to modify in the updateAcrobatNine.py script to get it to work (I am not much of a scripter!)?

    1. No, Acrobat Reader has utterly defeated me. It uses yet another format, and I’ve not been able to do anything useful with it from the command line.

      Sent from my iPad

  8. Don Montalvo says:

    Confirmed this works with all updates up to and including the just-released 9.4.1 update.

    Thanks,
    Don

  9. Ben says:

    Hi Greg:

    Great script….having an odd error….it says “Cannot patch Adobe Acrobat Pro.app because it was not found on the startup disk.” However, it surely is installed on the startup disk in the normal location. Any thoughts? Thanks again great script.

    Ben

    1. This happens when System Profiler has no record of Acrobat Pro — if you look in the list of applications that System Profiler generates, you’ll probably see Acrobat Pro missing. You can work around this problem by editing the script and changing some code in the updateAcrobatPro function. Change this:

      
(appname, status) = line.split("\t")
print "Searching for %s" % appname
sys.stdout.flush()
candidates = [item for item in getAppData()
      if item.get("path","").endswith("/" + appname) and 
      not item.get("path","").startswith("/Volumes")]
# hope there's only one!

      to this:

              
(appname, status) = line.split("\t")
print "Searching for %s" % appname
sys.stdout.flush()

# first look in the obvious place
pathname = os.path.join("/Applications/Adobe Acrobat 9 Pro", appname)
if os.path.exists(pathname):
    item = {}
    item['path'] = pathname
    candidates = [item]
else:
    # use system_profiler to search for the app
    candidates = [item for item in getAppData()
          if item.get("path","").endswith("/" + appname) and 
          not item.get("path","").startswith("/Volumes")]
                      
# hope there's only one!

      This causes the script to look in /Applications/Adobe Acrobat 9 Pro/ first, and only consult System Profiler if the app isn’t in its default location.

  10. Ben says:

    Thanks so much Greg! I knew that was likely the problem, but had no clue what to modify in the script. Really appreciate the help.

    Ben

  11. NancyL says:

    Can you list the specific steps to do this for those of us who have never done anything like this before?

  12. Zedat says:

    Greg, great script, works fine, but with 9.4.2 & 9.4.3 after installing every user requires to type an adminpassword to finish the update. Do you have also a solution for that problem? Most of our users don’t have adminpriviliges to do that.

    1. Jim says:

      There is some more about this topic here:

      http://www.brunerd.com/blog/2010/02/05/make-acrobat-pro-9-for-mac-shut-the-hell-up/

      For 9.3, I did something like this:

      /usr/bin/sudo /usr/bin/defaults write /Library/Preferences/com.adobe.acrobat.90.sh NoViewerSelfHealNeeded Mar 12 2011 -bool TRUE

      You can get this date by updating Acrobat on a system, launch Acrobat, and enter an admin username/password when prompted. Then run:

      defaults read ~/Library/Preferences/com.adobe.acrobat.90.sh

      You also need to disable the self-heal feature, I believe these are the files that you need to edit:

      /Library/Application Support/Adobe/Acrobat/AcroENUDist90SelfHeal.xml

      /Library/Application Support/Adobe/Acrobat/AcroENUPro90SelfHeal.xml

      I used some code like what I have pasted below in a postflight script:

      # search for files
      my @files = `/usr/bin/find “/Library/Application\ Support/Adobe/Acrobat” -name “Acro*SelfHeal.xml”`;
      foreach my $file ( @files ) {
      chomp ($file);
      print “Disabling Self-Heal in file $file\n”;
      # use sed to change the files
      system(“/usr/bin/sed -Ei.bak.$datefile ‘s/(YES|REQUIRED)/NO/g’ \”$file\””);
      }

      1. Jim – I think there’s a downside to disabling the self-heal feature. The various Acrobat 9 Pro updates only update things inside the /Applications/Adobe Acrobat 9 Pro/ folder, and rely on the self-heal feature to update other elements, like the Acrobat web plugin and any printing resources. So if you turn off self-heal, those components will not be updated.

        Zedat – there’s not really a good answer to this problem. If you turn off self-heal, your users won’t be prompted for admin credentials on launch, but some Acrobat components won’t be updated. It might be possible to write a script that replicated the functionality of Self-Heal, but I haven’t had the time to attempt such a thing.

        Why Adobe couldn’t have written their updaters to update _everything_, rather than updating only some things, and leaving the self-heal functionality to update the rest, it beyond me.

  13. Roy Nielsen says:

    Hello Greg,

    The script is working for me – we’re using it to update from acrobat 9 -> 9.5, and it’s working great!

    Not everyone would like to do it this way, but we’ve got a package that has Acrobat, all the updates & an application.xml.override. I’m putting all in one package, it installs Acrobat, then uses your script to install updates, then installs the application.xml.override.

    Regards,
    -Roy

  14. Lukas Huggenberg says:

    Hello Greg,

    I’m interested in trying out your script, but unfortunately your mobileme account has been disabled. Would you be so kind as to let me download it from another location?

    Thanks,
    Lukas

Comments are closed.