Adobe kills Creative Suite – all future features online only

[Cem]

http://www.theregister.co.uk/2013/05/06/adobe_kills_creative_suite_for_cloud/

[donmontalvo]

Adobe has a Creative Cloud packaging tool, hopefully it'll mature quickly and smoothly. Let's hope Adobe irons out enterprise licensing too, including hosting an internal key server (as Dan Shoop would say, wooly thinking...maybe Sasafras?).

[ImAMacGuy]

I am curious how other companies will respond to this? If the user is buying the full product suite they can pick and choose what they download and install. It makes it hard for IT to get their arms around it. The users demand admin rights to utilize the Creative Cloud as they see fit.

Given Jamf's history with Adobe, it would great if the JSS could tie in somehow to help monitor/administor it with a near future patch :)

[nessts]

Thank Apple and the App Store.

[donmontalvo]

I'm not too worried about packaging/deployment since Karl's team is forging ahead with the Creative Cloud Packager (RIP AAMEE). I'm more worried about license management. It would be cool if we could get a command line tool (ala APTEE) to manage provisioning of licenses.

This is Sasafras' opportunity to post...hmm...I wonder if they're lurking? :)

Don

[donmontalvo]

@nessts wrote:

Thank Apple and the App Store.

Microsoft pushed Office 365 really hard at the recent MacIT meeting in Dallas. They're following the same SaaS route.

Don

[hkim]

It'll be ugly in the beginning but like anything, it'll mature over time and be routine. IF Adobe was smart, they'd have a way to tie local LDAP to authenticate against a set number of cloud licensees per organization and let them float (again sort of like Sassafras KeyServer). That's a big IF though, I'm not holding my breath. It'll probably be more likely tied to an Adobe ID and we've all seen how well Apple IDs play in the Enterprise =)

[donmontalvo]

Wow, that would be sweet...might send your idea to Karl/Jody, I wonder if it's something they can implement. :) Apple recommends using 2 separate Apple IDs (one for purchasing, one for redemption/deployment). Not sure what Adobe has planned for Creative Cloud, your idea would be great.

[hkim]

Jody on twitter quickly replied that SAML support is coming. So there's hope! But launch at day 1 will be what people are doing now more or less.

[donmontalvo]

I wondered what SAML stood for. LOL

When in doubt, Google it...

http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

[RobertHammen]

Yep, the Creative Cloud for Enterprise product will support SAML 2.0 integration (so you can put Cloud users into an AD or other LDAP group and authenticate against that, versus the Creative Cloud for Teams approach of having to, on the Cloud team site, create/manage users and email addresses for each license):

http://en.wikipedia.org/wiki/SAML_2.0

[ImAMacGuy]

That would make license tracking easier, but what about admin rights to install the apps?

[hkim]

Well wouldn't that be a case by case basis? Each place has different rules about what you can and can't install, and using JSS to either restrict software, using JSS to push out things, put it on Self Service, the choices are out there ...... unless I'm missing something that you're trying to get at.

Why is CC any different than CS6 in this regard?

[bentoms]

@jwojda.. I think you'd install Creative Cloud as per you do CS6 now.

Just the user would have to authenticate to activate it.

In this case SAML would be very handy to allow a near hands off setup.

[ImAMacGuy]

@hkim - well, it's a service thing - spend X amount and get any adobe product you want. so today they want CS6 master collection.. tomorrow Acrobat 32 comes out, so they want that, the day after they want CS7...

We have one group of 5-10 people that's been on CC for a month or two now (don't recall exactly) and they got admin rights so they could add/remove software at will. Now if our entire company shifts to this then it could potentially become a nightmare. Certification groups would be swamped - Packaging, deployment, testing, this person whats this selection, this person wants this selection...

in the current model of the cds they get what they bought, we certify the major bundles, and only offer to the users as bundles - you want PS, Acrobat, and whatever - fine, buy this bundle.

[RobertHammen]

Use CCP to build packages (and dmg's, *sigh*) and deploy via Casper policy or Self Service. No admin user needed...

[donmontalvo]

I'm hoping CCP generated PKG installers work properly, so users aren't prompted for admin credentials when the applications are launched. I remember in the earliest AAMEE releases there were issues like this.

@RobertHammen since you've got access to the tools and are actively packaging/deploying, just wanted to confirm that all apps launch without requiring admin rights? :D

Don

[mscottblake]

I don't suppose CCP is generating native installers?

[donmontalvo]

http://helpx.adobe.com/creative-cloud/packager.html

Essentially, you log in as an administrator to the Creative Cloud portal and download Creative Cloud Packager. Using Creative Cloud Packager, you create Windows and/or Mac OS packages (MSI or PKG files) and then using any third-party deployment tool that supports the deployment of native installers (for instance Microsoft SCCM, Apple ARD, or JAMF Casper Suite) deploy them to client machines.

I have my doubts whether they are following Apple software distribution guidelines. Their AAMEE generated PKG installers can't survive SMB. $#!+ happens when you wrap aliases in a big hunk o' duct tape.

(In fairness to our heroes Jody/Karl, they have limited options when Adobe decides to use "One code set across platforms"...which, loosely translated, means "Let those pesky Mac people do the heavy lifting while we make some bank.")

Don "Adobe Loather" Montalvo

[RobertHammen]

Don, I haven't tried having a non-admin user install the package via Self Service - as it's been a step to the setup process so far, it's been done by an admin. I'll let you know what I find out.

Creative Cloud Packager can be considered a later version of AAMEE. It has the same restrictions re: SMB shares that Don mentioned, and having to do the "copy to DMG/use JAMF-supplied script to install", even if the package is being deployed via http...

[mscottblake]

That's a bummer. As someone who has SMB shares, I wish they would figure that one out.

[timsutton]

The solution would be for them to build flat packages instead of bundle-style packages, because that's a single portable archive file, similar to dmg.

Of course, then people will try to install the pkg file off network mounts and a different set of support issues will come up.

I think bundle-style packages will continue to work for the foreseeable future, and since Adobe doesn't use AAMEE, are they even aware this is an issue? I'm betting they aren't.

[donmontalvo]

@timsutton wrote:

The solution would be for them to build flat packages instead of bundle-style packages,

Eric Wilde explains why Adobe chose their installer development path in this blog:

http://blogs.adobe.com/oobe/2009/02/msi_pkgs_and_adobe_installer_n.html

[timsutton]

@donmontalvo

Pretty interesting, detailed post by Eric.

Still, I don't accept that they couldn't have achieved most if not all of what they wanted to do using native installer technologies, by examining available documentation and engineer contacts at Apple and Microsoft.

It looks like their evaluation of the Installer framework is based purely on an evaluation of PackageMaker, mistaking it for the core technologies available outside of just the PackageMaker interface. For example:

"b) We could not show a serial number dialog as part of the installer workflow."

Apple's official Installer documentation includes a sample project, whose entire purpose is to prompt a serial number dialog. This documentation is a bit hard to find now that it's legacy, but it wouldn't have been in 2008/2009.

https://developer.apple.com/library/mac/#/legacy/library/samplecode/InstallerPluginSample/Introduction/Intro.html

Much of the other gripes about Apple packages might have been possible using custom JavaScript in the distribution, the same way Apple's been doing for years with Pro Apps and softwareupdate logic.

This same pattern of a vendor looking at PackageMaker, finding it (understandably!) difficult to use and operate and with buggy behavior, and instead going around it with naive workarounds and scripts full of "# we need to chmod -R because PackageMaker doesn't save our permissions" is something we see over and over again. Apple's at fault for not better supporting the technology with public documentation, but Adobe's at fault for not trying harder and looking into what's already out there.

At some point, sure, keep using your own byzantine licensing subsystem with timebomb license lockout issues, if you want. But at least ship these bits using OS-supported technologies and/or custom extensions and stop re-inventing the wheel.

[mm2270]

The comments on that blog post from Eric Wilde were more interesting than the blog itself (and yes I did read the post) He basically got ripped a new one by nearly everyone commenting. I especially like the comparisons against Office and Final Cut that several brought up. Its possible to make this work, and so no-one is falling for the BS from Adobe anymore on why their installers are a rip roaring mess. They've had many years to work this out and we continue to see the same glacial pace of evolution from their installers.

[mscottblake]

The funniest part of all that is taht the post is from 2009. They've now had 4 years to deal with it, but instead they created AAMEE (which is a great improvement, btw). They know it's possible to use native installers, but it seems at this point they they aren't simply because they don't want to dump years of work down the drain.

I think it's hilarious that they had to create a wrapper installation for their own installations, and that I then have to wrap up and install with a shell script.

[donmontalvo]

Adobe could care less, after all, they've got us to subsidize their incredibly inept installer development team.