Update Adobe Reader without disabling updates?
There are a few steps I'd like to disable without forcing the added/extra steps in the subscription-delivered Adobe Reader.
For example I'd rather use a warm welcoming message with a custom script to close Adobe Reader. I think killing the process isn't very friendly.
Additionally, I'd rather just deploy the Adobe Reader update as I want it as-is with its auto-update turned on -- I don't want to be forced to have updates disabled.
Is the only way to achieve this to disable the package and convert it to standard, thus losing the auto-download mechanism feature on the PDQ side?
Or to add my script in the pre
1
Comments
Yes, you either need to convert it to a Standard Package, or add Pre and Post Steps.
@...
If I go to convert it to a Standard package it gives me this warning:
That means I will have to go edit the package each time there's an update to reference the latest Adobe Reader?
Yep, Standard Packages do not auto update.
We configure most packages in the Package Library with their built-in updater disabled because most of our customers want that. Using Deploy to update these applications saves bandwidth because you're only downloading it once and distributing it internally. Also, it allows you to test updates before mass deployment, if you want to. Plus, if you create a Schedule for each Auto Download package and point it at the corresponding (Old) Collection in Inventory's Collection Library, that will automatically update your computers for you.
Sure, I get that. Plenty of things we don't want auto-deploying right off the bat.
I think it would be helpful to have a choice however, instead of imposing practices on us that other customers (most, or most vocal?) practice.
It's also hard to accept that we're going to force close Adobe Reader on everyone's computer for example. What if someone's giving a presentation with a PDF file, or HR is reviewing an interviewee's resume while on a call. Most IT people don't consider the end-user experience and/or are not emphatic to their customers so I think some type of option for us would be nice. I don't see why "most customers", whoever those are (the vocal ones?) should impose their practices on other IT departments.
I'd get it if we're talking a huge feature request or something. But we're talking about the ability to not crash Adobe on someone and disable updates while also being able to deploy the application update we're paying a subscription for.
John,
I do not work for PDQ, I'm just a customer with a different perspective.
You do have a choice already. Your choice is to deploy the package as-is or convert it to standard package if you want different settings. No one is imposing their practices on you. I understand it can be frustrating when a solution is 99% of the way there to being what you need but you have to fill in the gaps yourself, but it's not the software's fault that your use case is not indicative of everyone.
If you don't want to force-close the software you can just modify the package to prevent that, or to add a "user is not signed in" condition.
Again, you already have "the ability to not crash Adobe" by doing Colby's suggestion of modifying the package.
From my perspective, the fact that we would have to manually check each package to change options for a new version is not an issue-- we try to test our deployments on a small test group before large rollouts anyway, so we look at the packages before deploying regardless. The fact that force-quitting Adobe every once in a while is unacceptable to you from a customer service perspective but pushing out completely untested software updates is no big deal is a bit of a head-scratcher for me. Surely having your Adobe close on you unexpectedly once in a while is better than potentially having hundreds of computers get a broken software update because you didn't test it first?
Hi Luke Nichols,
Appreciate the input. Unfortunately, you can't prove that 99% of everyone who wants to deploy Adobe Reader updates in their environment would like to force close it on everyone abruptly.
Yes, Colby's suggestion of modifying the package, which is what I put in the original post myself as I was already aware of it, is an option.
I'm talking about options within the existing package however.
Why am I locked out of disabling tasks that are irrelevant to updating the application. That's what I'm talking about.
I don't need you to lecture me about what's an issue or not, or whether my having to "fill in the gaps" is not a fault of the software.
I'm not that old, but I've been around long enough to realize that software evolves, and things can change based on customer feedback.
If I had the option to easily modify the package, such as being able to delete the "disable update" step, that would have no effect on you what so ever. Let that one sink in.
Oh, and I didn't realize I couldn't test Adobe Reader deployments if I could modify steps in the package.
Nice thinking there.