Adobe Remote Update Manage (RUM) New Feature Feedback

Our current system applies updates "out of hours". Basically we wake up our macs at 2am, apply updates and turn them off again.

What i'd like is something like what we have with our margarita/reposado combination for Apple Updates. A nice easy to use web page, attachable to AD for managed authentication where updates can be enabled and disabled at will.

It would be nice to have RUM report back available updates for 2 scenarios in my case:

1 - To use the reported information in an extension attribute so that we can see which machines need which Adobe updates

2 - When running RUM via Apple Remote Desktop it would be nice to first see that there are X number of updates on a machine and what those updates are before going ahead and running them.

An equivalent of softwareupdate -l for showing Adobe updates and then softwareupdate -i for selecting which updates to run (or softwareupdate -a to install all) would be most welcome.

Taking the example of Apple's softwareupdate tool, it's useful to be able to simply see what updates are available, and to be able to apply them selectively.

For example, we currently manage updates for about 8 different CS suite combinations. In certain cases we are very selective about updates for major applications due to issues with our specific hardware, or workflow-breaking bugs in the software (Premiere Pro CS6, for example). We might want to apply 80% of the other updates and hold back one or two for a while.

A simple use case might be the following: I find out there's a new version of Premiere. I want to select a few test machines and run a command via ARD, Casper, SSH, (insert software management system here) and just have them update their version of Premiere without touching any other applications or components.

Later, I might want to select the rest of the machines and run the same command to update them once I have been able to verify that the update is working for my environment.

Again, allow listing of updates so that one can see the updates that are applicable without actually installing them. An admin doesn't always want to just run one command and irreversibly update all installed Adobe CS apps. He/she doesn't want to run the command, have a second terminal session ready to "tail -f" a log file (in a weird place), wait to see the list of applicable updates, then Ctrl-C the first process before it starts installing.

Essentially, we would expect to be able to do the same with Adobe updates as they have been able to do with Apple updates for ages. In the same way we can take a catalog of updates from Apple and filter out updates we don't want to apply on the server end, RUM can facilitate this at the CLI by just allowing selective installs. AAM can already do this via a GUI, so it seems illogical that the CLI tool can't.

Please don't make me look up an obscure PDF, from a forum link or website that's difficult to find (or redirects poorly from a non-US country) for "Channel IDs", for which I need to build a list to know what's applicable to one of the 8 versions of the Creative Suite for a single machine configuration. Please. Just give me a list of updates for this machine (which only RUM/AAM can really determine), and let me install them.

Updates should work at the loginwindow, and not assume a user is logged in. If an application can't be installed at the loginwindow because it relies on AIR or something similar, then don't offer it in RUM, or at least not when there is no GUI login session. This is trivial to determine using Apple's APIs.

If RUM runs and updates Premiere Pro while it the application is in use, what happens? What should happen? I'd propose that RUM not run that update unless perhaps an option like "--force" is given.

Please make the tool log in a sensible location like /Library/Logs/Adobe, and not the user's (root's) home.

Allow the tool to output its results in a structured format like a plist, so that it's possible to wrap the tool with a helper script that can parse it more easily (rather than grepping/awking stdout). Many of Apple's existing command-line tools allow this, for example diskutil, dscl, system_profiler.

These features are all client-side for the RUM tool only. They don't require a special configuration of AUSST, or another webapp and authentication system to manage. I'm merely proposing a more robust, usable tool and I hope I've provided a clear enough use case of how one would use it in the context of managing large numbers of Macs with a wide number of possible Adobe CS install configurations.

Totally agree with what @timsutton says +;

• Ability to cache updates
• Ability to install cached updates
• Host CC & Acrobat updates as well as CS

We cached apple + 3rd party updates, prompt the user that they have updates pending.. & then install them @ logout.

Agree 100% with timsutton.

I want to be able to:
List available/applicable updates.
Selectively download one or more of the available/applicable updates.
Selectively install one or more of the available/applicable updates.

All updates must be able to be installed when there is no user logged in.
It's not acceptable to have updates that don't work when there is no user logged in and that will also fail if a user is logged in and using applications.

@bentoms

In other words, you'd just like to do what you're already able to do with 95% of vendor installers, but that nobody is able to easily do with Adobe CS/CC software, and therefore requires more "enterprise admin tools" to be written from scratch?

@timsutton Yes.. now i know it's a novel idea & all…

Guys, thank you very much for all the feedback and scenarios. It will certainly help as we craft the tool further.

While we're at it.. Who do we have to stab around here to get Acrobat included within RUM?

A few of us sat with @kagibson][/url at JNUC2013 and discussed this need. Echoing the above requests, mainly wanting/needing feature parity with Apple SUS command line.

Kudos to @kagibson][/url for picking up the ball and running with it:

http://blogs.adobe.com/oobe/2011/05/aamee-2-0-and-ausst-2-0-live.html

What does AUSST 2.0 not do? Well the biggie that is not yet implemented is the ability to send out command line requests to the AUSST server to push out updates to end users. We are looking into this and other feature requests for a future version of AUSST.