Yesterday, I posted this as part of a quick response to question on the MacEnterprise mailing list:
“At one point I though the Adobe Acrobat updates were not scriptable but Mr. Neagle found a way around that.”
I later received a direct communication regarding my comment from someone on the Acrobat update/install team at Adobe explaining:
“I’m trying to understand what folks are doing for silent install in 9, hoping to make this better in the future.”
Below is my response. Yep, it’s long-winded but, frankly, this is such a huge problem that it warrants all the detail. Sadly, I’m not saying anything that hasn’t already been said. I’m just adding my voice, adding my experiences and happy that someone’s paying attention.
“No problem that you’re contacting me directly. I appreciate the outreach. And I hope you don’t mind that I’ve copied our Adobe representative on my response. I’d like someone there to note that I appreciate you contacting me.
“First, yes, you’ve found the article I was referencing and today I am using Greg Neagle’s method as part of my deployment toolset, which is mostly Casper Suite and a bit of Apple Remote Desktop for maintenance and monitoring.
“Interesting that you’re asking about silent installs with Acrobat 9.0. You do realize that there’s nothing in the product nor the updates that enables silent installs, right? Had Greg Neagle not discovered the ability to use Python scripting, I and other administrators would be stuck with just three options:
- Touch every machine by hand (as an admin) and update manually
- Repackage Acrobat with the updates and re-deploy
- Don’t update
“I’m going to assume you’re reaching out because your group has heard about enterprise struggles with Acrobat deployment. Hopefully, this issue has come to your attention. If you’ll indulge me a little, I’d like to tell you mine. This is from the point of view of someone administering Macs…
“None of the above are good options.
“In the enterprise users are not admins on their machines. They shouldn’t be. My company is a publishing company that has Acrobat on just about every workstation we deploy and that’s about 5,000 computers (mostly Windows but a couple hundred Macs too). If we allowed users to be admins then they would install their own software, update their own software or use software that someone else isn’t using–all in the name of ‘getting the job done’. This, however, would lead to software conflicts and huge licensing issues. I won’t even touch on the IT support needed when someone disables his entire system and can’t work because he clicked on a link in a website to run antivirus software.
“So, that means in order for our support staff to update any version of Acrobat somebody has to coordinate with the user to log in to his machine either physically at the console or remotely, copy the updater and run it. Enterprises have spent literally millions of dollars throughout the years to avoid this time suck. This is time that we’re not spending helping the user and not spending improving our systems. But it can only happen when third party software developers make their installer software compatible with the tools administrators are using. Adobe’s not doing that.
“Repackaging is not uncommon. I do this a lot and I consider it a necessary administrative practice because sometimes third party software developers don’t make their installers and updaters compatible with enterprise deployment tools. Repackaging involves me using a tool such as JAMF’s Composer to ‘watch’ what I do as I install a piece of software and then run the updates. When I’m done Composer will pull together a list of new and changed files for me to weed through. I’ll keep the application files I just installed and discard irrelevant files that were found to be new or changed. I’ll then combine these files into a package that’s compatible with my deployment system.
“Why doesn’t this work with Acrobat? Two reasons. The Acrobat application is a drag-n-drop install, which is fine, but it has a nasty first-run process that requires administrator privileges to complete a secondary install. It tries to install printer software, it tries to install web browser tools and it tries to become the default PDF viewer application. None of this is scriptable. Even if I repackage everything that’s installed after the first-run Acrobat has another nasty mechanism called SELF HEAL that requires administrator privileges. Many administrators have posted tips, tricks and articles devoted to how to thwart the SELF HEAL process. See these examples that I found just using Google:
http://itmac.wordpress.com/2008/12/09/adobe-acrobat-admin-password-self-heal-problems/
http://groups.google.com/group/macenterprise/browse_thread/thread/ed98ce131fd7f969/0db8effb12370dd0
http://www.brunerd.com/blog/2010/02/05/make-acrobat-pro-9-for-mac-shut-the-hell-up/
http://www.tug.org/pipermail/macostex-archives/2005-July/016625.html
http://subvert.org/?p=84
“In my experience, it’s still hit and miss. When it’s miss then I have a user calling me and telling me that he can’t use his software because it’s asking for an administrator name and password.
“My third option is to simply ignore updates and just deal with them when I need to do so. Because of the portability of the PDF format and its ever increasing complexity, though, it has become a security concern. Adobe quite often releases Acrobat updates to address security vulnerabilities. In the enterprise I have to pay attention to these risks on my systems because we’re dealing with customer data, financial data and even HIPAA regulated data. Yes, on the Macs! My company and others have groups devoted to just IT security concerns like this and their reaction to anything released by Adobe as a ‘security fix’ is to get it installed quickly. That means once again a small staff of administrators must physically visit or remote control each machine and install the update.
“What do I need from the Acrobat team?
- A scriptable installer for Acrobat.
- An installer that can be run while someone is logged in or no one is logged in.
- An installer that can be deployed to a non-boot volume (such as when imaging a machine).
- An installer that will handle all components requiring administrator privileges at one time, including serial number.
- An installer that I can customize to disable self-healing.
- An installer that I can customize to disable automatic checking for updates.
- An installer that I can use in conjunction with my deployment toolset (an Apple package).
- An installer that’s not separate from the Creative Suite installer when deploying the suite.
- An updater that is a combo updater to patch all earlier versions of Acrobat.
- An updater that only patches the installed software and doesn’t attempt to replace the software I’ve chosen to not install.
- An updater that does not attempt to do anything unrelated to updating like resetting the default application.
- An updater that I can use in conjunction with my deployment toolset (an Apple package).
“FYI, these are installer ‘best practices’. They’re not administrator whims. That’s very important to note!
“I know you’ve probably had your dealings with Mr. John C. Welch and I’ll leave you to your impressions and experiences with him, but he does a great job at vocalizing the anger and frustration all enterprise-level Mac administrators have felt toward deploying and maintaining Acrobat. If you can look past the colorful language then read his post on this subject and then read the comments.
“IT folks are generally not Microsoft bashers, not Quark maligners and not Adobe haters. We appreciate software that works well regardless of who makes it but when software is made in such a way that it’s a nightmare to deal with (and Acrobat wins this prize) then you’ll hear about it. You’ll also hear about it when it’s a pleasure to deal with. I guarantee it. 😉
“Feel free to contact me again and ask any further questions. I’m glad to answer.”
Remember the Human 