Automate Creative Cloud Packager - Auto import to JSS

@kagibson wrote:

The requirement might not be as big now that the packages are all multi -language and that we have the pre-created packages on the enterprise dashboard but perhaps it is still valuable which is what I want to validate.

"...pre-created packages on the enterprise dashboard..." <-- details? :):):)

Automatic packaging sounds great, and XML for options even more so. Curious how auto importing into JSS would work. How would the package get into the Master DP? How would the package replicate to the Replica DPs? Does this require JDS?

@kagibson Since you asked...

How about instead of using the proprietary Adobe installer, how about using standard MacOS X Installer packages? We have had nothing but trouble with every Adobe product installer/updater. Things have only gotten worse since the advent of the Creative Cloud. Mysterious error codes with no definitive fixes. Updates that fail to download for no reason. Support files scattered all over the filesystem that make troubleshooting impossible. There used to be a day when Adobe software was loved by all. Now it's turned into Quark or Microsoft in the way of bloat and anti-piracy measures that get in the way of actually USING the products. Things have gotten so complicated just managing the licensing and deployment that some companies have to hire someone specifically to be the Adobe handler which makes your software extremely expensive to keep. Don't get me started on your outsourced tech support script-readers.

OK.... deep breath... I'm done.

I also think that automating the CCP package creation would be fantastic.

Automating CC packaging would be great. Integration and support for AutoPkg and JAMF's upcoming patching feature would be excellent.

I agree native OS X packages would be a big improvement as well.

@donmontalvo The Pre-created package functionality has been live for around 7 months or so :-) i can give you the details separately but it is also on the blog. Regarding the other questions this is where I was hoping this community could help with the grander implementation into workflows outside of my visibility.

@AVmcclint Deep breaths indeed. I understand the frustration. The first point is that I am here to help and this functionality is something admins have been requesting so I am hoping to fulfil this request which is why i have requested guidance to ensure that whatever we release is what admins want. This is similar to what we done around pre-created packages which aims to at least remove the packaging step from being a burden placed on IT. We have other initiatives under way to help with this which is what I alluded to earlier.

To the second point around Native installers. Yes that would be the desired behaviour and I have tried to address this honestly and openly in the past at various events and through social media. The previous installer tech Adobe used and is still presently using is indeed poor and offered no benefits to customers. The new installer tech though again proprietary will result in benefits to customers. From an IT admin perspective I am keen to address as many of the problems as possible and also offer the enhancements that IT would like to see. My intention is to consult admins throughout the process and ensure their voice is heard. However this is only achievable if we have an open and honest (which is what you have done) dialogue.

@Josh.Smith We have been engaging with the JAMF's for quite some time around the patch feature so hopefully that will come to fruition.

Cheers
Karl

@kagibson I don't remember if I stated this in any of my comments on the Adobe OOBE blogs but while I do know that CCP creates "standard" OS X installer packages it really must create flat packages to be more compatible with Casper's workflow, especially now that JAMF offers many options for non-AFP distribution points that can't handle non-flat installer packages (SMB, Cloud Distribution, JDS).

I think it is very doable for CCP to create flat packages even with the current internal Adobe RIBS installer technology. Instead of putting your entire payload inside of the installer package's Resource folder create a compressed payload, like most modern package installers do. You could design it so this payload gets uncompressed and dumped into /tmp/CCInstallerName/, or something like that, and then have a PostInstall script execute the internal Adobe RIBS installers. I do something similar with the Creative Cloud serializer that dumps your command-line tool and the XML file to /tmp and then I run a simple one line PostInstall script to execute them.

Casper Admin does automatically compress non-flat packages when uploading to make them compatible with all types of distribution points so if you can't create flat packages for some reason then CCP will need to zip up the package especially if you are going to attempt to automate this process (which I would assume means not needing to upload via Casper Admin).

However, having a flat package in the first place will make Adobe installers more compatible with different distribution methods. Not to mention it would have helped avoid bugs like defect D-007918 (https://jamfnation.jamfsoftware.com/discussion.html?id=12481) that took about 9 months to get fixed.

@spalmer I will check with the team on this. I know we investigated previously and it was not a viable option but I will reconfirm.

Cheers
Karl

@spalmer Again thank you for your feedback. As promised I had this discussion with the team. What we are keen to understand is if there are any benefits outside of just this Casper workflow were non AFP shares are used ? For now there is a documented workaround for this issue (use DMG).

While changing architecture on the CCP and Ent Dashboard side of things is theoretically possible it would have ramifications on other workflows admins use and would introduce other caveats like longer build time, longer install time etc... So while we are not against considering this direction we need to fully understand all of the potential benefits of Flat packages. Of course this is the great thing about this community so hopefully others can also weigh in and provide potential other upsides or downsides.

Cheers
Karl Gibson | Senior Product Manager | Creative Cloud Enterprise

@kagibson It sounds like you're more worried about how things affect Adobe and not how they affect your customers. "Wasn't a viable option"- for whom? "new installer tech though again proprietary will result in benefits to customers" - Like what? What is wrong with the standard Installer.app pkg files that many many many other developers use to distribute their software? 99% of the Mac software out in the world is either of the drag-n-drop-install variety (MacAppStore counts as this) or Installer.app packages. Listen to us when we tell you that we want STANDARD installers from Adobe. We don't want installers that are proprietary in any way. The whole point of installers is simply to copy files to hard drives. Installers should require minimal thought because the entirety of our interaction with it should only be the time it takes to double click it, next, next, Done (or just copy into JSS for deployment). We would like the majority of our time to be spent using the actual product, not futzing with the delivery mechanism. Why do you feel the need to reinvent the wheel? We don't want updaters that fail 90% of the time with no useful error messages. We want downloadable FULL installers/updaters... we don't want to download something that only downloads something else (although you have addressed this with the Flash distribution. thank you, the Creative Cloud installer does not). We want version numbers that make sense and are easy to parse. We want the ability to treat Adobe apps just like every other program users need. You say "while we are not against considering this direction we need to fully understand all of the potential benefits" I think this needs to be turned around. Instead of us telling you why you should do something that everyone else uses without fail, you should explain to us why not.

@kagibson you asked us what we want. This is what we want. You can either listen to what we are telling you or you can choose to ignore us and continue on your path in the most user unfriendly way possible. Some people would say that calling Adobe "user unfriendly" would be inaccurate. Some would say the correct term would be "user belligerent". The only reason you still have customers at all is because the end product - after we crawl through miles of barbwire and mud of setting it up - is the best thing around. I don't think anyone would argue that InDesign rightly won the DTP war over QuarkXPress. Very few would argue that Photoshop and Illustrator aren't the best tools around for expressing creativity. Do you really feel the need to make us prove our loyalty by putting up with the horrible nightmare that precedes the actual use of the products? This isn't just for Enterprise customers, this applies to home users, small businesses, and large companies with IT staff numbering in the hundreds.

@kagibson XML automated CCP is not to terribly useful from my point of view. I create packages with CCP, which is an annoying step given that so many other applications already come as pkgs. (And the number of times CCP fails to download is annoying). But once built, that's about it.

It might be useful if I posted updates to my JSS, but instead I automate RUM pointing to an internal update server using AdobeUpdateServerSetupTool. I actually have three different instances of AUSST repo so that I can have a DEV, TEST, then escalate the patches to Production. A more robust AUSST solution so that I can test & deploy patches internally without having three copies of the repository would be better.

RUM 1.9.2.56 with the action command has been very helpful for me to help identify users needing updates, notify & prompt them to apply the updates instead of a very long and ugly script I wrote to identify updates available. I would still like AUSST to list updates pending and see some type of release notes or something. Right now, knowing what updates were released has proven to be a challenge.

@kagibson As far as the ramifications are concerned I think that every product (Casper, Apple Remote Desktop, FileWave, DeployStudio, etc.) that can natively distribute non-flat packages can distribute flat packages as well. I also have a hard time understanding how building flat packages would have an impact on build time. The build time increases for most admins because you are not creating flat packages in the first place. Admins need to take the non-flat packages created by CCP and either compress them to a ZIP file manually (which Casper Admin automates for you but it still takes time) or they need to manually build a DMG file.

As far as worrying about breaking existing workflows why not just add in an extra preference in CCP and the Enterprise Dashboard that allows you to change what type of package to output. You could even add in the ability to automatically create ZIP or DMG files to help admins out. I could imagine adding in build output options as follows:

Package Format (radial) Legacy Non-Flat Package [checkbox] Standard [checkbox] Compressed ZIP [checkbox] Disk Image DMG (radial) Flat Package

The sub-options could be radial allowing only one choice but I made them checkboxes because some admins may want to have one or more of these types built. These additional options would allow admins to continue with their existing workflows if needed or move to a Flat Package workflow when they are sure that it will work with their setup.

The issue I see is that you are relying on admins to use what you mentioned yourself is a workaround originally created due to the fact that pushing non-flat packages created by AAMEE and CCP "as-is" has a higher tendency to fail. Using a DMG file and pushing it out is a non-native installation workflow for Casper and Apple Remote Desktop (I am not sure about other management products like FileWave or Deploy Studio). Also using this method a script needs to be written to mount that DMG and run the installer. While this is simple for experienced admins it may not be simple for first time admins or admins in smaller businesses or schools that aren't really even in IT (which happens a lot more than you think).

The fact that JAMF added the ability for the Casper server and Casper Admin application to compress non-flat packages was a workaround to make it easier for their users to work with non-AFP file shares. There are a few non-Adobe examples of companies that still use non-flat packages, but the primary culprit that many IT admins deal with is Adobe Creative Cloud. Many companies have switched to flat packages over the last four or five years: Apple, Microsoft (even Office 2011), FileMaker, Cisco, Adobe (Shockwave and Flash), Oracle (Java). Any non-flat packages I might still come across usually come from printer or scanner companies that have less experience creating Mac installer packages, but even that is rare these days. We have 621 installer packages on our distribution point. 239 of those are non-flat packages, and 162 of the non-flat packages are for Adobe Creative Suite or Creative Cloud. The remaining 77 non-flat packages are mostly for old software or internally created payload free packages that will likely be phased out very soon. Long story short, the point is that you need to be moving towards flat packages.

Some other points to consider:
1. You may also want to consider talking with JAMF to get a sense of what people are using for distribution points. I remember at a JNUC a few years ago it was mentioned in one of the sessions I attended that about 50% of their customers run the Casper Server and distribution points on non-Apple operating systems including Windows. It is likely higher today especially for larger companies that want to utilize their virtualized server environment.
2. JAMF has a cloud offering for the Casper server and Casper has the ability to use cloud distribution points. JAMF's cloud offerings are becoming more popular and going fully to the cloud means using non-AFP distribution points.
3. The writing is on the wall where Apple is concerned since it is moving away from AFP for its default file sharing protocol to SMB so even those small Casper server setups that are completely on Apple hardware will eventually be running SMB file shares by default which is another reason you need to support non-AFP file shares.
4. If I remember correctly I believe the reason Apple created the flat package format (all the way back in OS X 10.5?) is because they saw the need to be able to make package installers that can be easily portable and reside on non-AFP file shares with out getting corrupted. I am speculating a bit, and someone with more experience with Apple's packaging tools can jump in, but since the flat package has been the preferred format for quite a while now I would think that non-flat packages will eventually be deprecated (if they haven't been already).

I have been to your (and your predecessor's) talks every year at JNUC and I understand what you have to deal with trying to make all of the product teams in Adobe understand that they need to make their products friendly to enterprise IT distribution methods. I really appreciate what your team has done for IT admins so please take this as constructive criticism.

@kagibson I'd agree with a previous comment that automating CCP, although nice, wouldn't be as useful as having native Apple installers for enterprise deployment.

Regarding auto-import into the JSS, Other than Mac App Store & VPP, this isn't currently something other vendors do. It can be achieved now with the APIs. Outside of that I'd probably leave it to JAMF to handle.

Please, please, please let this be something we can use.