AAMEE and the Suites

AAMEE and the Suites, phonetically this could sound a bit like “Amy and the Sweets” which would of made a great female pop group name in the early 1960s. Adobe Application Manager Enterprise Edition, aka AAMEE is frequently pronounced like the name Amy. I personally use the äm pronunciation (like Guam) so as not confuse our product name or team with a person. “Bundling CS updates, AAMEE can do that.” which invariably leads to: “Amy who? Why isn’t she at this meeting?”

That was quite the digression. Actually I hadn’t really even started had I? Thankfully everyone only skims my posts, right? Let’s start over:

Adobe loves suites! It’s true. There is the Creative Suite of course, and now there is the Acrobat X Suite, Adobe Digital Publishing Suite, LiveCycle Enterprise Suite, eLearning Suite, Technical Communication Suite and since I started typing this there is now the Online Marketing Suite. Really, we love suites. And it makes sense, we are a solutions company, and as awesome as our stand-alone products and services are, you really get your value when they are bundled with other products and services.

A lot of the new suites with desktop applications are actually using the same installer technology that was developed for the Creative Suite, which is what AAMEE was built to parse, configure and output into a pkg or msi. Knowing this, you might assume that you could use AAMEE with something like the Acrobat X Suite or the new Technical Communication Suite. Sadly, this is not the case. AAMEE 1.2 currently ONLY works with Creative Suite 5.0 media and CS updates. It is a technical and classic “not enough hours in the day” issue. And for you, Joe IT Admin (hey Joe!) you might want to say “But I want one Adobe configuration and packaging tool to rule them all.” And I, appreciating your Tolkien reference and the pure logic you are invoking, will make sure it is something to focus on in 2011. However, I must be honest, it isn’t going to happen right away and I recommend figuring out clever ways to deploy these other suites without the use of AAMEE and would love to hear about how you did so.

Feel free to leave use the comments to let us know how this impacts your deployment projects, time, etc. Don’t worry, I have thick skin; I use to be a Mac IT admin in a Windows-shop mind you. And Eric Wilde, let’s just say he has read ALL of the Growl-related comments.

Jody Rodgers | Product Manager| Enterprise & Volume | Creative Suite

14 Responses to AAMEE and the Suites

  1. Kai Howells says:

    You’ve nailed it – as an IT Admin, it would be great to have one installer to be able to deploy the whole suite + updates, not just everything except Acrobat and Acrobat’s updates.

    At present, as CS5 is still shipping with Acrobat 9, it’s a real pain to manage the installation and updates of Acrobat 9, the easiest way to update it is through the auto updater, but this doesn’t make sense in an enterprise environment.

    I’m currently testing the latest release of AAMEE with an InstaDMG workflow – I know earlier versions of the packages didn’t work with this method and I’m hoping that having built a mondo CS5 Master Collection with all the updates and without AIR that it might work – I guess I’ll know in an hour or so.

    There have been changes to DeployStudio recently so that should building CS5 into the InstaDMG build train not work then CS5 can be deployed (minus Air) from the DeployStudio deployment process.

    It would be great to have Acrobat X work in with this process too – my initial tests show that even though Acrobat X seems to be a proper Mac OS X installer package, it didn’t install properly with InstaDMG.

    • Joseph Chilcote says:

      Hi Kai.

      For Acrobat 9, I would encourage you to look closely at what Greg Neagle has done over at http://managingosx.wordpress.com/2010/01/06/silent-installs-for-acrobat-pro-9-updates/. AAMEE will not work with InstaDMG–It’s just not meant to be installed on a non-booted filesystem. And sadly, Acrobat X, even though it’s a pkg installer, will not work on a non-booted filesystem either.

      An enterprising admin could probably poke around in the pre/post install scripts and Info.plist and hack together something that will work with InstaDMG; however, for my money it’s worth it to spend your energy mastering the art of repackaging. It is possible to repackage Acrobat X, and even CS5 Master Collection, to work seamlessly with InstaDMG. (I have not tried to install CS5 or Acrobat X via DeployStudio so I cannot speak to that).

      Best regards,

      –joe

      • Jody Rodgers says:

        (hey Joe!)

      • Greg Neagle says:

        Joe writes:
        ” for my money it’s worth it to spend your energy mastering the art of repackaging”

        I think a better approach is post-restore installs: that is, given how many packages are out there that do not work with InstaDMG, a wise Mac sysadmin must have a way to install software post-imaging. AAMEE-generated packages work just fine with tools like Casper, Absolute Manage and munki. Repackaging is something an admin should do only if there is no other choice… IMHO.

        • Don Montalvo says:

          Casper lets you add AAMEE generated packages to the imaging process, it’ll cache the installers and kick them in at first reboot. So the boot volume dependency is met, while the goal of distributing during imaging is met as well.

        • Joseph Chilcote says:

          I agree with Greg on this, with three notes:

          1. I was addressing the questioner specifically regarding shoehorning an AAMEE pkg into InstaDMG.

          2. I stand by the notion that fully understanding repackaging is a fundamental tool in a sysadmin’s kit. Even the best vendor-provided pkg installers may require some tweaking, whether post-deployment or not. Understanding payloads, postflights, and permissions can go a long way to make life easier.

          3. Repackaging can allow one to manage ad-hoc versioning in a highly controlled environment.

          –joe

  2. Gil Burns says:

    The Acrobat team was smart enough to use standard install formats (pkg and msi), which makes AAMEE unnecessary to deploy Acrobat. If the rest of the apps and suites would just switch to standard formats, AAMEE could be discontinued all together. Why should system administrators spend hours rebuilding and debugging your installers with AAMEE for enterprise deployment?

    • Jody Rodgers says:

      Thanks for your feedback Gil. Comments below:

      re: If the rest of the apps and suites would just switch to standard formats, AAMEE could be discontinued all together.
      That would be awesome! No really. The ideal would be proper native package support for both platforms. Although, instead of AAMEE being discontinued I think it would have value the way Acrobat’s Adobe Customization Wizard for Acrobat and Reader X has value. Being able to prep the Creative Suite (other Suites) for your enterprise environment is a major goal for us and even if we had a magic switch that turned our installers native you’d still want to do things like control the EULA, Adobe ID nags, disabling updates, etc.

      re: Why should system administrators spend hours rebuilding and debugging your installers with AAMEE for enterprise deployment?
      AAMEE outputs configured packages in just a few minutes, if it were hours something is wrong, very wrong. And I’d be curious about what debugging you had to do. We want to improve the experience packaging and deploying CS and value your feedback.

      Thanks again Gil.

      Jody Rodgers | Product Manager | Enterprise & Volume | Creative Suite

      • Gil Burns says:

        Jody-

        The hours of packaging and debugging your tools come in when you attempt to deploy more than one package created with AAMEE to the same machine.

        I.E. you create a WebPremium package and an AfterEffects package. Both packages work great on a test machine when installed individually, but in the real world, machines in the field may get both packages. Then all bets are off. One package will walk on top of files that the other package installed, and then apps stop working. Adding Acrobat 9 on top of this, and the whole thing is just a nightmare to deal with.

        Did anyone on the AAMEE team test the package creation in this scenario? It is not pretty.

  3. Jody Rodgers says:

    Speaking about Acrobat X, I just want to put a plug out for their new serial number provisioning tool for the Mac called the Acrobat Provisioning Tool. Their website states the name Adobe Provisioning Tool, but if you download it the name is the Acrobat Provisioning Tool. Here is the FTP link:

    ftp://ftp.adobe.com/pub/adobe/acrobat/mac/10.x/10.0.0/misc/

    This tool is not to be confused with the Creative Suite tool, Adobe Provisioning Toolkit Enterprise Edition (APTEE) that comes as part of the AAMEE 1.2 download and available as a separate download. Very similar tool of course. But ours has FIVE names.

    Jody Rodgers | Product Manager | Enterprise & Volume | Creative Suite

  4. Thanks Jody, very amusing post. its great to have a very valuable contact inside a very large company that is just not your usual PR robot! All cred to you, Jody.

    Onto serious stuff….

    An AAMEE produced package works well as a post deploy package, postponed till first boot, in a DeployStudio workflow, using an InstaDMG created base master. Say that twice, fast!

    I’ve just done 70 machines this way just this week. The only problem is that 10GB of package needs to be copied to the machine during the DeployStudio process, then it takes about 45minutes to install on first boot.

    The way AAMEE creates the ‘payload-less’ pkg that does all its work in postflight, means the progress of such an install is very hard to track. The progress percentage jumps to 97% very quickly (in about 5mins) then sits at 97% incrementing by some very small fraction for the remaining 40 minutes.

    So these two new tools, the Adobe Provisioning Tool (yes it is now called the ADOBE, rather than ACROBAT Provisioning Tool), and the Adobe Provisioning Toolkit Enterprise edition, work, in practice, in very different ways. Why when these were both made and released in the last few months do they perform the same task in very different ways.

    Really Adobe should sort out these names, if even Jody gets it muddled up here!

    adobe_provisioning_tool.app (from the AcroProv1000_en_US.dmg, Acrobat Provisioning Toolkit)
    adobe_prtk (from adobe_prtk_15029.dmg, Adobe Provisioning Toolkit Enterprise edition)

    I prefer the AAPTEE way of doing things, I can’t really understand why the Adobe Provisioning Tool (the Acrobat one) is wrapped inside a .app, when it still needs to be accessed via the command line.

    There’s not much documentation on this specific tool. Perhaps we are supposed to put an .xml file inside the .app bundle and then you just double click it to provision a particular install? Can anyone show me info on its usage in this way?

    I have used calling the binary that is buried inside the .app to good success for Acrobat, and using the adobe_prtk for CS5….

    but shouldn’t these be part of the one same tool, doing things the same way?

    This work to make it seem-less for the end-user, (Joe IT) should be done at Adobe’s End.

    Otherwise much work is done to work out, repackaging, scripting these tools in many different ways, battling with application override xml and plists and other text and binary preference files. And done by many IT admins, many times over. What a waste of human work. This should be done by the mother ship, as it were, once for all!

    Cheers,

    Charlie (eWhizz dot net)

    • Jody Rodgers says:

      Hey Charlie! I am going to pass your feedback about the Acrobat Provisioning Toolkit over to the Acrobat folks for you. And regarding the problem with tracking the AAMEE installation progress, and it getting stuck at 97%, have you ever tried creating a package with the AIR components disabled? I am wondering if it is the AIR components in the end taking so long. If you disabled them you could deploy them as a separate process later (documented in the Deployment Guide.) Please let me know if you try this out.

      Speaking of PR robots, I have been working on one in my spare time. Doing these posts are hard work. I hope my wife doesn’t notice the iRoomba and the MacMini that was connected to the TV are missing. ;-)

      Jody Rodgers | Product Manager| Enterprise & Volume | Creative Suite

  5. Tim Kimpton says:

    Hi Jody

    Thanks for this post and comments its really hard trying to speak to Adobe technical support when you try and explain to them you have been packaging for over a decade and they still talk to you like an end user.

    I have had to package CS5ME 11 times CS5 standard 10 times CS5 Production Premium 3 times. Don’t get me wrong the tools created for packaging the suites but there are some flaws. The major one being Acrobat 9 Professional and needs to go back in the suite.

    Unfortunately Adobe won’t give us a free upgrade to Acrobat X even though we spend thousand on upgrades for all our sites.

    I have found I have had to do the following
    1. Create Adobe pkg for the suite disabling air eula etc
    2. Can’t include updates because I don’t know which are required yet
    3. Insert Acrobat 9 disc and copy Acrobat updates to the desktop
    4. Because the pkg created with AAMEE does work with ARD be it user or no user logged in, I use Jamfsoftware Composer to take a snapshot.
    5. Install, serialise and update Acrobat
    6. Install the CS5 suite and update (pointing to internal update server)
    7.Install Air and Help files manually
    8. Ammend Acrobat and Distiller files so they don’t self heal and ask for admin detail
    9. Include Acrobat app support and preference files for Acrobat, help etc in User Template
    10. Incude Acrobat app support and preferences to hidden location
    11. Create a script and LaunchAgent to copy the Acrobat files to the user directory otherwise the user will be bothered with serial prompts
    12. Run a script to delete the Acrobat updater plugin and updater
    13.Take another snapshot with and package with Composer and rip out crap like AV logs etc
    14. Create a script to delete user cs3 preferences
    15. Rebuild machine and test

    As you can see its a lot to do when the CEO is breathing down your neck every 5 minutes wanting to know when its ready.

    • Jody Rodgers says:

      Tim,

      I have to say this is one of my favorite comments I have seen on here. It truly captures the complexity of an Adobe CS5 deployment. Too complex if you ask me. I am going to use this comments internally as an example of how we have made it a laborious process to deploy our software. It needs to be easier, clearer, and faster.

      BTW, I am not sure I understand #4, why the reasoning to use Composer?

      Thanks again for this honest feedback.

      Jody Rodgers | Senior Product Manager| Enterprise & Volume | Creative Suite

Leave a Reply

Your email address will not be published. Required fields are marked *


nine − 8 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>