Packaging enterprise software applications for deployment is something that can keep many administrators lying awake at night staring at the ceiling. Today’s enterprise applications are often large, complex, cloud-based things that are very different to install compared with, say, installing WinZip on Windows 95. One software suite that has caused frustration for some administrators is Adobe Creative Cloud, which provides users with the entire collection of Adobe desktop and mobile applications ranging from essentials like Photoshop CC to next-generation tools like Adobe XD CC. To walk us through the problem of how to automate the packaging of Adobe Creative Cloud for deployment with System Center Configuration Manager (SCCM), I asked Mark Van Noy to share some of his hard-earned expertise with our readers. Mark is a technical lead/architect at the University of Colorado Boulder in the Greater Denver Area, and as an Information Technology generalist he thrives on architecting new tools and services in ways that allow his customers to realize gains in efficiency, productivity, and cost savings while ensuring that IT remains a division that provides a competitive advantage. For more information on Mark, you can check him out on LinkedIn. Let’s put our ears to the wall right now and listen in as Mark explains how he and his team used Windows PowerShell to solve what seemed to be an almost insurmountable application packaging problem: How to fully automate the packaging of Adobe Creative Cloud together with device licenses for their planned deployment of the software.
Fully automating Adobe Creative Cloud packaging with device licenses
Adobe CC allows custom packaging of individual Creative Cloud applications as well as the entire suite using an enterprise’s device license key. While Adobe does have automation guidelines so that software administrators do not need to step through the GUI packaging tool, PDapp, the XML configuration file for automation needs to be manually updated for non-trivial packaging scenarios. The University of Colorado Boulder developed a PowerShell script to automate the generation of XML configuration files so that the Adobe CC packaging process is automated in a larger variety of scenarios.
What exactly is the problem that needs to be solved?
Adobe does a great job of providing documentation on how to automate packaging Creative Cloud applications. Adobe’s documentation is quite good and they make the process fairly straightforward if all an individual needs to do is provide a single large package of all Adobe Creative Cloud Products that are the latest release. If individual products, or subgroupings of products, need to be packaged, that can also be accomplished by setting up a more complex XML file. Adobe even includes the XSD schema of their XML format for those individuals that want to fully understand the XML grammar used by the Creative Cloud Packager.
What Adobe does not provide is an automated way to get the version numbers for applications when a subset of applications is being packaged despite the version having to be supplied. For example, if a company wanted to package Illustrator and Photoshop together, then both version numbers of the products need to be supplied in the XML. Those version numbers can currently be found on this separate Adobe website. Which leaves the problem of having to manually edit XML configuration files with version numbers after manually looking up the version numbers in order to automate the packaging process. The XML configuration files save the time of clicking through the GUI, but modifying the XML by hand is still wasted time with error-prone data entry.
Application packaging: Light appears at the end of the tunnel
Through a little experimentation, we found that individual CC applications can be packaged one at a time while functioning as though they were packaged together as long as they are using the same device license key. Not only does the ability to package each application individually without having to create unique packages make the problem to be solved more straightforward, it also substantially cuts down on the number of packages that may need to be created. If I remember my discrete math, and I probably do not, there are 17! combinations of packages that could be requested. By the way, that’s seventeen factorial (1x2x3x4x5x6x7x8x9x10x11x12x13x14x15x16x17) not 17 with an exclamation mark! But no more than 17 packages ever needing to be packaged is scriptable!
The PowerShell script we developed
The IT team at the University of Colorado Boulder set out to write a PowerShell script that automates the modification of a master XML configuration file. The modified XML file is then fed to the Creative Cloud Packager, PDapp.exe, by way of a CMD batch file. Since the batch file chains together the various combinations of applications that need to be packaged, all a package administrator needs to do is run the CMD file then they can do something else while the packages are created. You can download a zip archive containing the ps1, XML, and cmd files here: AdobeCC.zip.
The glue that holds the process together is the PowerShell script. The script first queries the Adobe website that lists product versions and their Sap code. The table of products is converted from HTML strings into PowerShell objects. By making the table values from the webpage PowerShell objects the product data for each application is kept together so that a given Sap code knows what version of the product it should be and what product name it has.
Next, PowerShell’s native XML processing is leveraged by reading in an XML configuration template. In this case, we made a master XML file that contained all of the product codes and versions from the Adobe website. When a single product is specified the script makes sure that the version number for the product that was previously parsed from the Adobe website is written to the XML. Then all the other products have their XML nodes removed. The exception is when the entire suite of products is specified in which case all product nodes are removed as the entire suite is a special case with a specific XML node. Once the XML modification is done the changes are written out to a new XML file that can be fed to PDapp.exe.
The script we came up with has some additional features such as the ability to override the XML template’s device pool name so that an individual application can be packaged using a custom device pool. Those features are documented by the script itself as well as a couple of usage examples. Standard PowerShell help, Get-Help .\Automate-AdobeCCPacakging.ps1 -full, will bring up the scripts built-in documentation.
Featured image: Shutterstock