Adobe Installation and Licensing

You are invited to participate in a live interactive walk through of our upcoming Enterprise Deployment experience. This session is targeted to those who deploy in large enterprise sized environments and will be conducted via an Adobe Connect session and hosted by Sharma Hendel, our Lead Sr. Experience Researcher. There is limited space available, so please sign up early.

The session will take place at Friday 2/12/10 at 10 a.m. to 12 p.m. PST. Please contact Victoria Selwyn (vselwyn@adobe.com) to reserve your spot today.

Thanks and regards,
Victoria Selwyn

Update: Thank you all for the responses. We're full now and not taking any more requests for inclusion on this interactive walk through. --Eric

Currently, activating Adobe software has a limit on the number of deactivations that can occur. For all Adobe activating software (including Acrobat-based products), that deactivation limit is 20. Starting January 15th, the deactivation limit will no longer be enforced.

Deactivations are useful when installing the software on a new system. Adobe's license agreements stipulate that the software can be installed on two different systems at any one time. Activation is intended to enforce this license agreement. When installing on a new system it is often necessary to remove the software from older systems. That removal is tracked by deactivating the software on the old system prior to removing it.

The deactivation limit has caused numerous problems and I'm very happy to see it go. As stated above, we should go live on the a new activation server implementation on January 15th that completely removes the deactivation limit. Although deactivation is still necessary (which causes some other problems), there should no longer be any limit to the number of deactivations.

In email discussions with a couple of readers I mentioned that this implementation may go live as late as March. I'm happy to say that we were able to certify and post it earlier.

Note that this affects software as far back as Adobe Creative Suite 3 and Acrobat 8.

Customers have stated very clearly that they do not want to close other applications while installing Adobe software. For some applications, we really do have to quit those processes in order to successfully install due to locks on system resources, etc. This may be acceptable with respect to closing other Adobe software; but, it isn't acceptable when users have to close critical tools such as browsers.

We had really hoped to improve this aspect of our installers in the coming CS releases. We have made some inroads on our upcoming installers; but, there still are some limitations. Most importantly, there are two cases where we still need browsers to close before we can successfully finish installation:

(1) When installing plugins for various browsers we need those browsers to quit. This usually happens when installing a product that also installs the Flash Player. Such products include Flash Pro and any Creative Suite that includes Flash Pro in its distribution. Fireworks also deploys some browser plugins and needs browsers to quit.

(2) When installing some color settings files we need Firefox 3.0 to quit. Firefox 3.0 holds a lock on system color files while executing. We deploy versions of these same color files and cannot do so when Firefox has a lock on them. This was fixed with Firefox 3.5; however, there are still 14.5% of our user base using a version of Firefox prior to Firefox 3.5. Complicating this fact is that the process name for Firefox has no indication of version number. So we will still require Firefox to quit before installing upcoming Adobe product releases. Once more users have shifted to Firefox 3.5+ we will be able to remove this obstacle.

We have at least addressed one of the worst consequences of needing to close browsers while deploying by limiting the amount of time the browser needs to be down. With upcoming CS releases non-Adobe conflicting processes can remain open throughout most of the installation process. We cache any locked files until the very end of the install process. At that point a warning dialog is provided to the user to close conflicting processes such as browsers for the last minute or so of installing these few remaining, cached files. This will allow users to keep open their browsers for the vast majority of time consumed in deploying. Silent deployments will, of course, not have such a warning dialog and so will need the browsers to be down during the entirety of the deployment.

This all applies to future Adobe Creative Suite retail releases. CS3 and CS4 installation will not receive the changes mentioned above and will still need browsers to quit.

To set a baseline as well as gather data from a broad array of system administrators, we put together a survey to understand where are the costs customers incur when deploying Adobe Creative Suite software. We'll use this data to more finely tune the set of features delivered in the Enterprise Deployment Toolkit for future Adobe Creative Suite releases. We've heard a lot of feedback from customers both here on the blog and elsewhere. We'd love to hear more input from you all so that we can deliver on the most important features for volume deployments going forward.

Please provide feedback here.

We'll be collecting the data and closing down the survey at the end of January. After the next release of the Enterprise Deployment Toolkit we'll perform this survey once more to see how effective the release has been and prioritize follow on features.

Thanks,
--Eric

Updated: It seems the word 'cost' is causing some confusion. By cost I mean anything that might take up time or resources in order to succeed at the deployment, not just the $ amount for support software or hardware. These are generally areas that cause pain and grief for those who do the deployment. --e

Akash Jain and Ravi Prakash Singh are developers on the core engineering team who focus on the installation technology.  Here they describe the usage of tags to help manage software deployments across enterprises. -- Eric

Software tagging is the process of maintaining a set of tag files (.swtag) on a client machine to determine the install and license state of various software products. This tagging process can be used to assist in Software Asset Management (SAM) tasks and there is an ISO industry standard for this which is denoted by ISO/IEC 19770. For asset management purposes an administrator can run any SAM tool that will scan the .swtag files on the client machine and parse them for analysis and reporting purposes.

Software entitlement tags (.swtag) are files that provide authoritative identifying information about software licensing rights. These entitlement tags taken together with 19770-2 software identification tags, which accurately identify installed software programs, facilitate conducting software audits, reconciliation, and license compliance management with ease.

Prior to ISO/IEC 19770-2 electronic discovery of software licensing rights was non-existent. Entitlements data was commonly found in printed documents like purchase orders, invoices, and purchase receipts which were hard to organize and track. Standardization of entitlement data tags provides uniform, discoverable data for the license compliance processes of Software Asset Management (SAM), making it possible to optimize software license compliance.

Software Tagging in Existing Adobe Products A9 and CS4

Acrobat 9 was not only the first Adobe product but the first ever product to utilize ISO/IEC 19770-2 software identification tags. Adobe Creative Suite 4, which was shipped in 2H2008, was next to follow. Since the active development cycles for these products closed prior to the current ISO/IEC proposed Final Draft International Standard v1 19770-2 dated 2009-05-13, this implementation is based on an earlier proposed Final Committee Draft version released on 2008-08-04.

Adobe Creative Suite 4 products dynamically generate tag file during install time and product launch time. They also support a self‐healing capability.  The self-healing capability restores tag files to their correct state at product launch time in the event of a missing or corrupted tag file.  Licensing state changes or product configuration changes can also result in a change to the tag files.

Software Tagging in Future Adobe Software

While ISO Tagging in Adobe Acrobat 9 and Adobe Creative Suite 4 was based on the Final Committee Draft version released on 2008-08-04, future Adobe software will incorporate the changes proposed by ISO/IEC in the Final Draft International Standard v1 19770-2 dated 2009-05-13. As with Adobe Acrobat 9 and Adobe Creative Suite 4, future Adobe products will dynamically generate tag files during install time and product launch time and also support self-healing capability. To incorporate the changes of the new draft there are few changes in different areas of tagging process.

1.       Tag File Location in A9/CS4 and future Adobe software

2.       Tag File Naming convention in A9/CS4 and future Adobe software

3.       Important Tags and values

All mandatory identity elements are supported along with some optional information. Some tags have been deleted, added and renamed. Important tags with their possible values are shown in tag file examples.

a.       Example of Tag File in A9

  View image

b.       Example of Tag File in CS4

Since Adobe supports what is known as "Flexible Licensing" an application can be installed and serialized as a standalone app or as a part of a Suite. There are some differences in the tag files in both the cases.

                                                   i.      Software tag files for Standalone Application for e.g. Photoshop licensed by itself looks like:

View image

                                                    ii.      Software tag file for an Application licensed as a part of Suite  for e.g. Photoshop licensed as a part of Adobe Creative Suite Design Premium looks like:

View image 

4.       Process/Stages of Tag file Updation:

a.        Product install - On product install a tag file gets created for

                                                   i.      Non-Serialized Install: <entitlement_required> set as "false".

                                                  ii.      Serialized Install: <entitlement_required> set as "true".

b.       Product launch - On product launch existing tag file is updated if present otherwise a new one is created. Tag file is updated based on licensing state changes thusly: