Adobe Installation and Licensing

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:

Posted by Eric Wilde at 11:23 PM | Permalink | Comments (0)

There is new CS4 deployment documentation posted on the Creative Suite ADC site. This represents a significant upgrade to the old documentation available at launch.

http://www.adobe.com/go/creativesuite_devcenter

There are 4 documents and three planning sheets. The CS4 Toolkit guide was completely redone. The deployment guide takes you one level deeper with more background around planning for deployments and some best practices. The planning sheets go with the deployment guide.

Happy Reading!

Chris Hohman
chohman@adobe.com

Posted by Chris Hohman at 4:20 PM | Permalink | Comments (1)

Sanjeev Biswas and Kanika Dalmia are two core engineers in the licensing domain at Adobe. They write below about one of the common customer service calls and what we're doing to fix it longer term. -- Eric

The handling of license expiry in Adobe CS4 has been one of the highest customer calls generator for Adobe, with anxious customers calling in to find the way out of this dead-end.

This 'License Expiry' screen is all too familiar to many of us

In CS4, "License Expired. Licensing for this product has expired" was displayed to the user if either the software build had expired or if the serial number used to license the application had exhausted its validity and had expired. This was a hard-stop and it prevented the user from running the application again. In particular, the user of expiring serial numbers had no direct way to resolve the license expired state and renew his license with another serial number. This situation becomes more complicated when other Adobe applications / suites are installed and licensed on the machine. The user was blocked on this and ended up ringing customer support.

There has been a workaround to the License Expiry issue, wherein the user had to manually roll back the system clock by a few days to re-launch the application, and then deactivate the license with the "Help-> Deactivate" option with erase serial number preference set. This would remove the expired license and the corresponding serial number from the user system. So when the user resets the system date back, on subsequent application launch the user is presented the user interface to enter a new serial number.

In CS4 handling of license expiry, the user wasn't reminded that the product's license is about to be expired and also, the user was not given an opportunity to renew his license with a new serial number. The user was bound to use the workaround, to be able to run the application.

In our next version, the design of the license expiry workflow has been altered to effectively tackle all the issues in CS4 handling of license expiry.

In our next version, when the product is launched the check for license expiry is performed. If the serial number associated with the license has expired, the user would not be displayed a hard-stop alert as was done in CS4. Instead, the module responsible for licensing of the product would bring up a user interface. This license expiry user interface screen would

• Inform the user that the license in use has expired with an error message.
• Additionally, it would provide an option to the user to enter a new serial number to renew his expired license.

This is like a 'bonus launch' of the product as the product is giving a bonus opportunity to the user to renew his expired license by entering a new serial number. This eliminates the need for previously used workarounds, to bring up the user interface (serialization screen) for entering an alternative serial number in case of license expiry.

If the user does not use the 'bonus launch' of the product to renew his license, then on every subsequent launch of the product, the license expiry user interface would be displayed, prompting the user to enter a new serial number.

With this design, the user would no longer be blocked on license expiry. Just a new serial number is to be procured and provided in the user interface, to continue to run the application seamlessly.

Improving the user experience for all adobe products is one of the principal design consideration for the next version of our licensing solution and, through this approach, we aim to do just that and thereby also reduce the volume of technical support calls.

Posted by Eric Wilde at 4:23 PM | Permalink | Comments (37)

We recently noticed that our spam filters have been overzealous for the last four weeks. Many comments have been delayed between 2 days and 4 weeks before being posted because of this effort. The spam filters are all cleared out at this point and I'll go try to fix them now. Sorry for the delay in getting your recent comments posted.

Now to get those filters fixed and start reading all the comments that were blocked...

Posted by Eric Wilde at 2:03 PM | Permalink | Comments (7)

Hello all. Its been a while and we've been busily working on various features for deployment and provisioning. One area that has seen a fair bit of attention lately is the workflow for updating Creative Suite products. Ravi Prakash Singh is the lead development engineer on the new updater team. Below he talks about some of the design goals and solutions used for the next version of the updater workflow. - Eric

Adobe's updater technology through CS4 is known as the Adobe Update Manager (AUM.) AUM has a long history of various problems. Our user community has been vocal about the number and types of problems experienced through AUM. In the next instance of the Creative Suite, we intend to provide a different update experience that should address a number of the most egregious problems discussed thus far. In particular:

* Failure of an update to successfully apply to a user's system
* Failure to adequately roll back a partial or failed update, thus leaving the user's system in an unusable state
* The update process interferes with users trying to get their own work done

When we started out the design for the new Adobe Updater we set a few simple goals:

* Make the Adobe Updater install the updates successfully and if the updater fails, ensure whatever was installed as part of updater is rolled back and the machine is back to its orginal state.
* Make the Adobe Updater non-intrusive. The Adobe Updater should not interfere with the user's tasks by poping dialogs in middle of your extremely critical workflows. It will not be an in your face application.
* Make sure the Adobe Updater when running does not hog your CPU cycles.
* Using the Adobe Updater should be a pleasant experience.
* Checking for updates is silent and the notification for available updates is clean and unobtrusive.
* Provide ways for system administrators to turn-off updates completly. Secondarily, we also want to enable easier management of updates by system administrators.

In order to achieve the desired reliability, sensitivity to system CPU cycles and roll back ability, the updates themselves will use the exact same deployment engine as the original installer. In past versions, the updater was managed by one team while the patches and installation were managed by another team. We've brought these teams together into a single organization for better cooperation between them. The technology that lays the bits down on the users' systems at install time will now be the same technology that updates the products post-install. This solution simplifies the implementation and makes it more robust by having consistent use of installed component databases and deployment strategy.

In order to ensure the updater is non-intrusive, we intend to have the client machine know about each update within 24 hours of that update being advertised by Adobe servers; however, users are notified either when they quit their app (not at app launch or in the middle of application use) or by an unobtrusive notification elsewhere on the system (e.g. a badge on the right side of the menu bar on a Mac.) There are two main parts to this approach:

1) Let the client machine know about updates as soon as it is hosted and made available by Adobe. To achieve this goal the updater will not be linked to Adobe product launch. Instead it will run as a scheduled activity independent of any product. During installation of an Adobe product, the Adobe Updater will be added as a task to the Task scheduler on Windows and as a Launch Demon on Macintosh. This step will help the updater perform a scheduled check for updates in silent mode. Such silent checks should occur at 2:00 am.

Minimal resources are used to check for updates. If you are not online at 2:00 am no connection will be initiated. The updater will wait until the following day at 2am to check again.

2) Once the update is discovered and downloaded, notification for the update is non-intrusive. In particular, there is no popup dialog that tells you an update is available and requires your attention. The notification itself will depend on the platform; but, will be somewhat similar to other status notifications on that platform. For example, on Mac the notification will likely be a badge on the right side of the menu bar indicating the status of an update. This is much like the status of other Mac services such as Time Machine or instant messaging clients.

If the user takes action on the notification then a dialog will appear that lists what applications have updates available and provide easy access to user preferences. As in CS4, all updates are cumulative. This means you should not see one update after another in serial for any given product.

There are a few more items to touch upon here:

Updates UI - When launching the updater, it will be possible to explore each product with an update to see which updates are pending, a description of the update and what other products are affected by those updates.
Notification UI - When you express interest in an update notification, a dialog will display showing which Creative Suite products have pending updates. It will be possible to explore each product with an update to see which updates are pending, a description of the update and what other products are affected by those updates. It is also possible to access user preferences from this dialog.

Preferences - To let users control Updater behavior, there will be preferences options for
a) Turn on / off menu notification
b) Disable/enable Auto updates for CSXS Services.
c) Auto download/install updates.

Enterprise Support - Support for volume deployments include the ability to turn off the entire update system at install time as well as the above mentioned user preferences. In addition, we have tentative plans for post-ship delivery of instructions on how to host Adobe's patches directly on your own servers. This enables end users to use our Adobe Updater but recognize, download and apply patches directly from volume customers' own servers.

Scheduled Check for Updates - Update checks would run as a scheduled activity; on Windows as a task (in the Task scheduler) and on Mac as a Launch Agent (via plist in ~/Library/LaunchAgents). This check would be performed on daily basis at 2:00 am. If the system is asleep at 2:00 am, then the next check for an update would occur when the system awakens. If system was shutdown at 2:00 am then update check would be performed at restart/user logon (via Run key on Windows and plist in /Library/LaunchAgents on Mac). If still there is a missed update check in past 24 hours, product launch would ensure that an update check is scheduled to occur after 2 hours.

Non-Admin Users - User's without an admin account can now install the update from normal user account with the typical admin password prompt. This will be possible for all platforms except Win Vista where UAC has been disabled.

Hope the insight in to the new Adobe Updater is useful and provides some information on what we are planning for the next revision. Your comments and feedback are most welcome and we look forward to an healthy discussion and do any course correction if needed.

Updated: Based on the comments below, there have been three updates above. Two sections were added to clarify behavior (Scheduled Check for Updates and Non-Admin Users.) Further detail has been added to the preferences section as well. --Eric

Posted by Eric Wilde at 2:44 PM | Permalink | Comments (69)