MSI, PKG’s and Adobe Installer Needs

Tonight’s post is written by the Sr. Engineering Manager leading the development team for the deployment (installer/updater) and provisioning (licensing) technology, Nagendra Bangalore. Nagendra is a long-time installer guru at Adobe who became responsible for the installer technology for Creative Suite 4. Having successfully addressed many of the goals for Creative Suite 4 installers, namely fixing most of the retail customer workflows, Nagendra now has responsibility for the update technology as well as the provisioning technology for future versions of the Creative Suite. –Eric Wilde
A slight bit of history and maybe a bit of overlap to what Eric wrote in his previous blog; so please bear with me on this one. Note that this article focuses on retail installers. Enterprise deployment considerations are significantly different and will be handled in future posts.
A long time ago when Adobe was not releasing the Creative Suites, life in installer land was very pretty and relatively straightforward. Each team that released a product had a Windows & Mac engineer releasing native installers. The installers were industry standard and worked well and then the Creative Suite came along and changed everything.
Lets take a look at how the first Creative Suite was accomplished.
In the first Creative Suite, all individual products were using InstallShield or MindVision to create non-MSI installers on Windows and Vise Packages on Mac. A team was put together and wrote installers for the Creative Suite that assembled and installed the individual installers in silent mode. At that time there were many engineers each working on individual applications. These engineers working on the individual product installers and the Creative Suite installers ensured six products (Win & Mac) were assembled into a single Creative Suite installer (Win & Mac). The efficiency in original Creative Suite installer development was two engineers per individual product.
It worked great for the Creative Suite as it was custom assembled; but, for every change required by the Creative Suite each product’s installer engineers had to change their code to accommodate the requirements of the Creative Suite. This became a coordination nightmare. We had a staggering number of install order incompatibilities, and we routinely had individual product installers stomping on each other. There was a lot of testing that went into Creative Suite installers that didn’t go into general co-existence issues, and in fact a lot of the fixes in suite installers depended on the particular order of installation of the products in the suite. It was, however, still manageable even though the teams working on the individual product installers were in three different geographies (San Jose, Seattle, and Hamburg). One thing was clear going in to Creative Suite 2, we had solve the issue of file sets that were common across many individual products in the Creative Suite.
A look at how the Creative Suite 2 was done.
As the team started on Creative Suite 2, it was decided to standardize on MSI (InstallShield) and Apple Packages for Mac. Standard templates were created, all of the Creative Suite requirements for the installer functionality were moved to scripts and DLLs, (written once but used by everyone) and the Creative Suite Installer team worked on another custom installer to bring them all together.
Since we had a very obvious issue of files being stomped all over the place in the first Creative Suite, we solved the issue by introducing the common files installer (aka shared component installers.) See the note below on MSI and shared compoqnents. Another problem became the co-ordination among installer engineering to pick-up the right version of the common code implemented in DLLs and scripts. Any mismatch meant some Creative Suite functionality was broken. The overwhelming complexity brought in by Creative Suite 2 was a major indicator that for Creative Suite 3 installers would have to use a different technology.
A look at how the Creative Suite 3 was done.
As the team formed in Creative Suite 3 to look at this problem, they had a bigger problem at hand. The acquisition of Macromedia brought many very different products into the Creative Suite. These products plus the integration of the video and audio products in CS3 resulted in much more complexity from the sheer size of the Creative Suite. No longer could we enjoy the luxury of having 1 installer per product. They had to solve this by coming up with a solution that created installers that shared code, could be used across six different Creative Suite offerings, create installers that could simply plug into the Creative Suite architecture, solve package management problems, implement new functionality and requirements, all while keeping the overall installers easy to create.
Phew, there’s a bit of history on how the Creative Suites were accomplished. Now lets talk a bit about the technology itself,
Folks always asked me, “Why do you have to make it so complex!! Microsoft Office is a suite of applications and they have MSI-based installers. Why can’t Adobe do this?”
Okay, Let’s investigate MSI a bit.
MSI is valuable installation technology for delivering individual products and it does a great job handling all of the installation needs (performance can be a bit more desirable, but hey, if it is reliable then performance can take a back seat for now). But where it breaks down is handling a suite of applications as well as shared components that are independently updatable.
Before we go any further, let me take a brief moment to define what I mean by “shared component” or, in Adobe nomenclature, “Shared Technology Installer”. Many of the Adobe products use certain functionality that is shared between more than one product. These functionalities are called shared components. Shared components should have their own installers and should be managed in such a way that install/uninstall of a particular software that uses the shared component does not break any other software using that shared component. This involves reference counting of that shared component on the end-user’s machine in some way. Examples of shared components are Adobe Camera Raw, Adobe Extension Manager, Adobe Bridge, Dynamic Link, CMaps, TypeSupport and the list goes on. Organizationally, these components are owned by different teams who deliver the shared component to each product team. Shared components are delivered as standalone installers for integration purposes.
By now an MSI expert is thinking “Why installers? Why doesn’t Adobe release MSM for the teams to integrate?” Good Question.
Here is why we could not release MSM for shared components:
a) Integration of MSM into an MSI installer means literal addition of these files into the product’s MSI and Cab file. If two such products are in a Creative Suite that effectively means you just doubled the space of the media and also means you increased the size of the electronic software download. Now imagine what the Master Collection would look like with all of those duplicates, many of which are in four or more products.
b) Once the MSM’s become part of the MSI then those files are not part of the main installers. Once this happen, creating a patch/release/upgrade of the shared component would be a nightmare and in some cases impossible due to the constraints imposed by MSI on upgrades and patches.
c) Now imagine you are on the verge of shipping the Creative Suite. There is a bug in the shared component and a fix is released. If the fix is in an MSM file then every product that included the MSM must rebuild and recertify. This can very readily lead to a slip of the shipment date.
I am not saying that releasing the shared components as installers is the only answer to this; but, it did solve some of our major requirements:
a) Since we released shared components as installers, these installers could now be plugged in to the product installer. The integration became easy. When a Creative Suite was created we needed to carry one copy of the shared component installer.
b) Creation of patches for these shared components is not a problem because they are treated as a product itself.
Once we decided to go with installers it introduced a host of other issues that we had to solve:
a) Reference counting (one more reason why MSI’s can’t be used for the Creative Suites or individual products in the case of Adobe products) – Since MSI only does component ref-count we had to now keep track of the installer ref-count. No one does this currently. We had to come up with a way to handle this.
b) Versioning issues – We now had to make sure that the installers didn’t install the wrong or older version of a shared component.
Apple Packages and Creative Suite Installers
When we first started investigating what installer technology to use for Mac Installers, it was obvious that we should be using Apple PKG and MPKG formats.
In Creative Suite 2, all the individual product installers did use PKG and MPKG formats. As we dug in to Apple PackageMaker we encountered the following issues that made us look at other options.
a) No script can be executed before the UI starts (so that we can check for OS, conflicting process, incompatible versions of application installation, check for pre-release versions, etc).
b) We could not show a serial number dialog as part of the installer workflow.
c) Decision from a script directly affects the selection of items in the UI.
d) Add custom UI and custom messages and insert them into the different workflows, (install, re-install and uninstall workflows)
e) Selection/De-Selection of one package in the options screen must affect other items and prevent users from making an incompatible selection.
f) Prompt for disk-swap when an installer switches from one media to another.
g) Ease of installer creation when it comes to shared technologies, individual products and their integration into Creative Suites.
Here is a simple table that illustrates where MSI and Apple PKG format do or do not meet our needs.
<html xmlns:v="urn:schemas-microsoft-com:vml"

Eric Wilde
Normal.dotm
Eric Wilde
2
46
2009-02-25T08:07:00Z
2009-02-25T08:07:00Z
1
233
1329
Adobe Systems, Inc
11
2
1632
12.0

Clean
Clean
false

18 pt
18 pt
0
0

false
false
false

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:”Times New Roman”;
mso-ascii-font-family:Cambria;
mso-hansi-font-family:Cambria;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
border:solid black 1.0pt;
mso-border-alt:solid black .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid black;
mso-border-insidev:.5pt solid black;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:”Times New Roman”;
mso-ascii-font-family:Cambria;
mso-hansi-font-family:Cambria;}

 

Topic
and Issues Critical to Adobe

MSI

Apple
Pkgs

Ref-count b/w
Shared Technology Installers

No

No

Ability
to Patch/Upgrade/Update smaller portion of the technology in a
Creative Suite

No

No

Can be used to create Creative Suite installers

No

Yes

Media
Management (Disk swapping)

Yes

No

UI/Project
Customization

Yes

Not
to the extent we require.

Resource
Usage for Installer Creation

Very
High

Low;
but, not less than what we have currently.

Package
management

 

Package
management is the ability of a software deployment system to identify and
resolve the needs of a software product on end-user’s machine. It includes
various aspects of software deployment such as conflicts, dependencies, 3rd
party dependencies, updates, patching, etc.  It is a very complex area. The complexity increases
further when the Creative Suites are introduced, where many products share
Shared Technology Installers.  Due
to complex product matrics in different  Creative Suites, the
conflict/dependency scenario becomes cumbersome.

Present
for Products and Non-existent for Creative Suites like Adobe

Very
Basic

Uninstall/Repair

Uninstall
functionality available. Reinstall on windows will not perform a full
re-install but will only repair key file marked items. Assets not marked as
key file are not reinstalled.

Uninstall/Drag
to trash functionality available.

Reinstall
functionality also available.

Scaling
of Productivity (i.e. Engineer handling installer for 4-5 products –
Platforms excluded)

No
very scalable

Scalable
but we still need to tackle issues like sharing of installer functionality
across projects.

 

In short, our determination was that the native platform installers would not allow us to get the reliability, flexibility and engineering efficiencies of shared component install, package management, and the UI flexibility we needed for our suite installers. We realize that the lack of native installers for our products has raised questions for all of our customers, and presents real problems for enterprise deployment situations. As to the questions: we hope this post has answered many of them, and we look forward to your follow-ups.
We also realize that these factors affect enterprise customers the most. We are working to make this much better. In future blog posts we will address this issue and talk to you all about the options we are thinking about to solve the pain felt by our enterprise customers and we sincerely look forward to your feedback.
Thanks,
Nagendra Bangalore
Sr, Engineering Manager
Nagendra@adobe.com

32 Responses to MSI, PKG’s and Adobe Installer Needs

  1. Eric Wilde says:

    The first two posts of this article were truncated due to the blog technology (MovableType) not correctly interpreting the HTML tags. Hopefully everyone can see this now.

  2. filipp says:

    I think most of the points under “Apple Packages and Creative Suite Installers” can be fixed by using Installer Plugins. These are not enterprise problems, imho (just as Intaller Plugins are not an enterprise-friendly solution).
    There’s nothing wrong with using 3rd party installation methods, if native are not enough, *as long as they work* and *are documented*. :)

  3. David Buxton says:

    Would you be able to update the post with a properly-formatted table please? It is difficult to read all the cells at the moment.
    Here’s the same table with all the Office-specific formatting stripped:
    Topic and Issues Critical to Adobe
    MSI
    Apple Pkgs
    Ref-count b/w Shared Technology Installers
    No
    No
    Ability to Patch/Upgrade/Update smaller portion of the technology
    in a Creative Suite
    No
    No
    Can be used to create Creative Suite installers
    No
    Yes
    Media Management (Disk swapping)
    Yes
    No
    UI/Project Customization
    Yes
    Not to the extent we require.
    Resource Usage for Installer Creation
    Very High
    Low; but, not less than what we have currently.
    Package management Package management is the ability of a software
    deployment system to identify and resolve the needs of a software
    product on end-user’s machine. It includes various aspects of software
    deployment such as conflicts, dependencies, 3rd party dependencies,
    updates, patching, etc. It is a very complex area. The complexity
    increases further when the Creative Suites are introduced, where many
    products share Shared Technology Installers. Due to complex product
    matrics in different Creative Suites, the conflict/dependency scenario
    becomes cumbersome.
    Present for Products and Non-existent for Creative Suites like
    Adobe
    Very Basic
    Uninstall/Repair
    Uninstall functionality available. Reinstall on windows will not
    perform a full re-install but will only repair key file marked items.
    Assets not marked as key file are not reinstalled.
    Uninstall/Drag to trash functionality available. Reinstall
    functionality also available.
    Scaling of Productivity (i.e. Engineer handling installer for 4-5
    products – Platforms excluded)
    No very scalable
    Scalable but we still need to tackle issues like sharing of
    installer functionality across projects.

  4. Guys, if Apple can span Final Cut Studio across 8 DVDs using PKG/MPKG, so should you folks. All it takes is to use the appropriate path reference inside your entries in the .dist file, eg:
    “x-disc://Adobe%20Creative%20Suite%204%20Design%Premium/Installer/deploy”
    vs.
    “file:./Some/Path”.
    And as previously mentioned, Installer plugins are frequently used by the likes of Apple and Microsoft to obtain licensing info during the installation process.
    Not trying to be obnoxious, but that list of can’t-do’s re: PackageMaker worried me a bit.

  5. Eric Wilde says:

    David,
    The table still seems to be appearing screwed up for some folks. It appears fine in my browser; but, I’ll try to tweak it today to make it more readable. I still thought this post should go out since so many people wanted the info.
    Thanks for the table you provided. I’m not sure yet how it will appear in the comments section for most people; but, on my browser it comes out on the blog as not even a table. So simple HTML formatting doesn’t seem to work.

  6. Cdot says:

    It seems like you’re requiring extra functionality from the installer technologies to justify not using them.
    I find it ironic that Microsoft can install Office on OSX with a minimum of hassle, but Adobe can’t do the same with Creative Suite.

  7. Eric Wilde says:

    Cdot writes: It seems like you’re requiring extra functionality from the installer technologies to justify not using them.
    Its true that we have requirements beyond what the native OS installer technologies can provide. That’s exactly the point of this post.
    Its also true that many requirements may be simplified if we can simplify what each of the applications in the Creative Suite requires of their installer. We’re definitely pushing in that direction; but, its not simple work when you have such a wide array of products from various historical sources. This point is particularly true when it comes to application settings. Application settings are a real pain point for many of our enterprise customers. Being able to set and deploy them in a consistent way requires a fair bit of work on many application code bases. Its an item we’re investigating; but, as you all so colorfully point out, we have bigger fish to fry first.

  8. Matt Rosenberg says:

    Instead of complaining that existing installer technology doesn’t meet your needs, have you considered that your “needs” may be unreasonable?
    Your post mentions the dead-on comparison that people make with Microsoft Office, but you never address it again. I’d like to see you try to answer the question. If Office can be installed with standard OS installer technologies on both Windows and OS X, why can’t Creative Suite? (A comparison with Apple Final Cut Studio would also be valid.)
    The answer must surely be in Adobe’s design decisions. Perhaps your basic model of “shared technology” is fundamentally flawed relative to the practical realities of today’s operating systems. The likely scenario is that your installers are a mess because, behind the scenes, your applications are a mess.
    To address the table of “needs” directly: it seems like many of your yes/no answers are simply wrong. (I’m a Mac expert only, so I can’t address MSI stuff.) Both Microsoft Office and Final Cut Studio install updates, to the applications and shared components, using standard packages. Final Cut Studio comes on like 7 DVDs and is installed from a package, so clearly that’s not a problem. Most of your “package management” needs shouldn’t even exist. Why would an application need to be “repaired”? In rare circumstances where that need exists, a proper application suite should be easily to delete and reinstall. And don’t get me started on “UI customization.” Installers shouldn’t be a marketing opportunity.

  9. Kevin O'Shea says:

    As expected, most of the reasons provided turn out to be more of a ‘this is why it’s inconvenient or harder’ to use the native installers, as opposed to a ‘this is why it’s impossible to use the native installers’.
    You are clearly making decisions to make your internal development easier, at the expense of the end user. The only reason you’ve been able to afford that approach is because you figure you’re Adobe, and people don’t have a choice since they can’t get CS from a competitor who’s willing to put the customers experience and needs above those of their internal development preferences.
    The reason the above post is unsatisfactory is the same reason you don’t have a better answer to the question, “If Microsoft/Apple can use their installer technologies work for their complicated suite products, why can’t Adobe?” The answer is they could, but they don’t particularly care. When the OS or Sutie teams at Microsoft or Apple want to do something the installer can’t manage, they have to work around it. Yes, in the long run they also have the added benefit of being able to improve their install architectures themselves, but those features are always delivered well after the needs arise.
    Adobe, on the other hand, doesn’t have a corporate requirement to use the native installers, and so when you want to do something not easily supported by the native installer, there’s not much resistance to throwing them out the window.
    The reason you all created this blog was (as far as I can tell) because you recognized that your overall install experience is relatively pathetic, given the size & price of your CS Suite. If your goal now is to truly change that, then you’ll do an about face, and do the install (and core engineering) work to make the process simpler (and IMHO use the native OS installers).
    If you’ve already decided that you’re not going to do that, and this exercise is just an attempt to sway everyone to your point of view, then I expect you’re wasting your time.

  10. beverins says:

    You need to scrap the installers and start over.
    “historical sources”? Please. I realize you all are Corporate folks and there is the everpresent Corporate Jungle, backstabbing, elitism, nepotism, “cubicle tribes”, and internal competition for promotion and proving your worth.
    But, honestly, I see motherboard driver disk packages from CHINA that work faster than your installers, do MORE INTENSIVE WORK (shared libraries? How about thinking core chipset drivers? I think that’s more complex) and they install MULTIPLE items spanning several different installers all using an MSI script and it is TRANSPARENT. Click. Watch Blue Bar. Done.
    Also, making your installer FLASH BASED & Javascript based is such a bad decision that I wonder what kinds of board meetings you people have? I suppose you guys live the DILBERT comics every single day?

  11. A big formatting request: Could you make the overall text column wider? It’s like two standard newspaper columns wide, which is still really narrow for a web site. I mean, even a netbook can handle something more than 720px wide for the entire visible site, (according to your stylesheet at least”.
    That, as much as anything is cramping up your space for tables, etc.
    I also have to agree with the folks raising the question about multiple media sources, since that’s a problem other applications have solved with Apple Installer Packages.
    One question: How do say, packages in Mac OS X 10.4 compare to Packages in Mac OS X 10.5?

  12. Eric Wilde says:

    Unfortunately, my personal bandwidth to respond to last night’s post is a little limited today. I’ll be slogging through these late tonight (Pacific Time) in order to respond. Until then I’ll continue to at least keep up on getting the comments through moderation.

  13. oh and dear GOD, could someone explain why CS4 licensing breaks every other week?

  14. Eric Wilde says:

    John, if this really is breaking every other week for you that’s (maybe surprisingly) great news for us. Assuming you’re talking about “Licensing has stopped working” errors, we’ve been trying to get a reproducible test case for a long time now. Let’s talk offline about it.

  15. Eric Wilde says:

    I’m going to try to address some of the philosophical or conceptual issues in these comments. Nagendra should be logging on shortly to address some of the technical issues brought up.
    Matt Rosenberg writes: Instead of complaining that existing installer technology doesn’t meet your needs, have you considered that your “needs” may be unreasonable?
    Absolutely! As has been mentioned here in past comment threads, there are a lot of applications historically coming from lots of different companies that are put into the suite. These widely varying applications have quite a few different requirements for their installers. Some of those requirements really are design issues with the applications themselves. As a corporation, Adobe has to apply its limited resources in ways that satisfy customer needs both for the application functionality and application management (installers, updaters, licensing, etc.) You can make a good argument that we’ve erred too much on addressing application functionality and are now suffering in the application management domain. With the changing teams and responsibilities we are indeed now starting to apply more resources to the application management domain in order to address such difficulties. This blog is one result of applying more resources. Our sincere desire is that there will be other, more concrete results from applying more resources to application management in the near future.
    Matt Rosenberg also writes: The likely scenario is that your installers are a mess because, behind the scenes, your applications are a mess.
    I can’t argue with you there. Coming from some application teams myself, I know its all too easy for an application engineer to not care about the installer. We’re now paying the price and trying to correct the situation.
    Kevin O’Shea writes: You are clearly making decisions to make your internal development easier, at the expense of the end user.
    This is a common perception from our customers. In point of fact, we do have to consider the amount of resources we can apply to installation or licensing issues when trying to come to a solution. We don’t have unlimited numbers of engineers at our disposal. As Nagendra’s post tried to illustrate, we painted ourselves into a corner with the way our applications were designed and the business needs of the Creative Suite. Creating the installers for the Creative Suite was really inordinately expensive (in addition to some real technical problems that the post also tried to describe.) Something had to change. What we ended up doing has also put us into a bind because our installation technology has filled our customers with justifiable anger. We’re trying to address the problems with installation now while still remaining within the business realities of what resources can be applied.
    Speaking as a member of the installation and licensing teams, what we’re trying to do is definitely NOT easy and causes us lots of grief. We’re not so much trying to take the easy way out. I would instead characterize it as trying to solve real problems while staying within the confines of what is feasible for us.
    Again, we recognize that past decisions have put us in the situation where our installers are hurting us and hurting our users. So we’re increasing investment in our installers to make them better.
    Kevin O’Shea also writes: The reason you all created this blog was (as far as I can tell) because you recognized that your overall install experience is relatively pathetic, given the size & price of your CS Suite. If your goal now is to truly change that, then you’ll do an about face, and do the install (and core engineering) work to make the process simpler (and IMHO use the native OS installers).
    Very valid point. We do indeed recognize the pain our installers and licensing technologies have caused. That recognition led us to invest more in trying to fix the problems. This blog was created more as a way to communicate with our users so that we could let you know what we’re trying to do and why, as well as get input from you.
    I wouldn’t characterize what I’m trying to lead our teams to do as so much an about face. Rather, it seems to me that we’re evaluating the various options before us and doing what we think is best given our various competing requirements and constraints. Based on the engineering input and project realities, I’m still convinced that using native OS install technologies for our installers won’t get us to a better solution right now. If the data coming from this blog and from the engineering team points to a different conclusion – that using native OS install technologies can solve our problems better – then we’ll not hesitate to move.
    Believe me, I don’t want to have to create and support our own installer technology. Its not done out of some perverse desire. Its dictated by our requirements, constraints and the functionality provided by the OS install technology. Part of our effort includes trying to remove unreasonable requirements from the applications; but, there’s a long way yet to go.
    Kevin O’Shea also writes: If you’ve already decided that you’re not going to do that, and this exercise is just an attempt to sway everyone to your point of view, then I expect you’re wasting your time.
    Again, a very valid point of view. We both agree on this sentence. We’re not trying to convince you that our decision was the best decision we could have made. Instead, we’re trying to understand your problems enough to make a better decision taking into account the boundaries within which we must operate. If we can solve some real problems then I consider it time well spent.
    John C. Welch writes: A big formatting request: Could you make the overall text column wider? It’s like two standard newspaper columns wide, which is still really narrow for a web site. I mean, even a netbook can handle something more than 720px wide for the entire visible site, (according to your stylesheet at least”.
    I’ll be fiddling with the blog as much as I can tonight to get a better format. What you’ve seen up to now is all defaults for the blogging technology used. Hopefully I have enough access to the system to make it better tonight. Otherwise, I’ll have to work through our IT group and things may take a day or two to get better.

  16. Eric Wilde says:

    I messed around with the CSS a bit tonight; but, could never quite get a satisfactory layout within the time I had available. Will try again tomorrow when I’ve actually got some open space in my calendar. My apologies for those who still have troubles with the table format.

  17. Ian Curtinsmith says:

    Fella’s you really need to start using packages for the Mac. SOE deployment is moving very quickly away from a clone image restore as a result of local KDC’s and many other reasons to a pkg bases install.
    As for your comments re pkg and mpkg installers
    a) No script can be executed before the UI starts (so that we can check for OS, conflicting process, incompatible versions of application installation, check for pre-release versions, etc).
    * Yes you can, No idea what exactly you are trying to accomplish here but packages can have requirements for everything you have stated as well as creating your own pre-install actions that can do just about anything you want
    b) We could not show a serial number dialog as part of the installer workflow.
    * Yes you can, Microsoft + Final Cut to name a few
    c) Decision from a script directly affects the selection of items in the UI.
    d) Add custom UI and custom messages and insert them into the different workflows, (install, re-install and uninstall workflows)
    * ? What exactly do you wish to achieve here? You would I assume bundle up CS into multiple packages within packages. The package itself would have a requirement placed upon it and would be available to run or not depending on that requirement
    e) Selection/De-Selection of one package in the options screen must affect other items and prevent users from making an incompatible selection.
    * Yes you sure can
    f) Prompt for disk-swap when an installer switches from one media to another.
    * Yes you can, Final Cut Studio is a good example
    g) Ease of installer creation when it comes to shared technologies, individual products and their integration into Creative Suites.
    * Yes you can
    Seriously.. There is no reason in the world you can can’t use package technology to deploy. It would make everyones lives so much easier as updates and installers could be pushed out via ARD / remote or bundled up in net-install images.

  18. Nagendra Bangalore says:

    Thanks so much for the response. I really want point out few things, We are not providing excuses for anything here, Just merely saying what transpired and few reasons why we did things the way it turned out.
    Regarding few responses on the comments so far
    From Pepijn
    >>
    Our mistake totally, We screwed up here and should have figured this out. Our bad. Will keep this in mind.
    Regarding comments from Ian Curtinsmith:
    I am going to take a look at (a),(b),(c) back again and respond back to this post. If everything can be done, Then we screwed up again. If things could not be done like how we wanted, I will come back and let you know.
    (d) We had do things like, Check if pre-release version is installed and then don’t allow installation of that package, If not serialized (installing in trial) hide the package, if serialized then show that package, depending on serial we have to show and hide packages.
    For the most part,the packages in Creative Suites could be installed and uninstalled outside the Creative Suites, this posed the biggest problem.
    We had to find a way to manage the sub packages installation and uninstallation.
    Reference counting b/w packages became an issue.
    We could not find a easy way to resolve the issues below with PKG.
    A) If Photoshop installed package A and Package B then Illustrator comes along and installs the same set of packages, then on uninstallation of Illustrator, I should not be uninstalling Packages A and Packages B.
    B) If Illustrator installs Packages A and Package B, But Photoshop comes along with Packages A and Packages B that totally conflicts with what is installed then the end-user should be prevented from installing Photoshop.
    C) If Illustrator installs Packages A and Package B, and Photoshop comes in and installs the same packages but are of higher versions then the older packages must be uninstalled and then the newer packages must be installed.
    d) If Illustrator installs Packages A and Package B, and Photoshop comes in and installs the same packages but are of lower versions then the installed packages must be remain as is and Photoshop installer just ref-counts this so that on uninstallation of Illustrator those packages installed by Illustrator is not blown away.
    There are few more cases like this where had to solve the issues.
    Like how we overlooked the disc swapping, May be there is a better way to do this and it would be great if we can get feedback on this. It may be the case that we are worrying about some details that we should not be worrying and are spending energy in the wrong direction. Any course correction with a smack on the head is most welcome.
    Just wanted to add a note that, We are sincerely looking forward to resolving issues and are making an efforts to fix the issues. Like Eric mentioned this blog is way to reach out to you and hear back from you.
    Again, Thanks for spending your precious time and responding to this post.
    Thanks
    Nagendra

  19. Michael Curtis says:

    An interesting article, but I still can’t see why native installers won’t work. It seems to me we should feel sorry for the installer team due to the application teams given them a mess to work with.
    It seems it would be better to give them a kick, give them more resources, then use native installers which would take less time at the end of the process. You seem to be attacking this from the wrong end.
    This post was meant for retail copies and yet you still used the lack of serial number input as an excuse. I am sure no home user would mind typing in the serial number when they open the application for the first time. Who cares about entering it at install. You also fix one of the enterprise roll out issues as well. John C. Welch mentions this in his recent installer blog post.
    I tried to roll out CS4 with Casper to 4 machines. Two machines got the broken license error, like John. One on first launch. One the next morning after it had worked.
    Same package, 3 different results. Hardly reliable for a roll out and worse the result changes over time.
    I look forward to seeing progress via this blog, but from what I hear the wrong team(s) are trying to fix this problem. If you aren’t careful the result is going to be, we did our best, but the application teams let us down and we had to fudge the install.

  20. Eric Wilde says:

    beverins writes: “historical sources”? Please. I realize you all are Corporate folks and there is the everpresent Corporate Jungle, backstabbing, elitism, nepotism, “cubicle tribes”, and internal competition for promotion and proving your worth.
    Sorry, I missed responding particular point to this earlier.
    I don’t mean office politics and the like. What I mean is that there are new products coming into the Suite every release. These products often come from completely different companies, not originally Adobe products. As such, they could use install technologies like Installanywhere, etc. So we have products coming from a wide variety of install technologies that we have to find a way to work with.
    That doesn’t mean its impossible to get everyone into PKGs, just that its another hurdle.
    Hopefully that clarifies a bit what was meant.

  21. Wylie Horn says:

    Do you have a Beta program for testing new installers? I’m sure that many of the people who have already commented would be happy to help test your latest installers prior to release and provide you with valuable feedback on whether the changes you have made to your installers actually meet your customers’ requirements.

  22. Eric Wilde says:

    Wylie Horn writes: Do you have a Beta program for testing new installers?
    Absolutely. Please send me email at:
    ewilde@adobe.com
    Include your name, company name and your role within the company. If there’s a fit then we’ll include people in our prerelease program. If you’re more interested in a product prerelease program than in installers I’ll forward your request on to the appropriate product team.

  23. Wes says:

    Do you talk to the installer teams at Apple and Microsoft about these issues? It might help them see what is needed for future updates to each platform’s installer program.

  24. Eric Wilde says:

    Wes writes: Do you talk to the installer teams at Apple and Microsoft about these issues? It might help them see what is needed for future updates to each platform’s installer program.

    We haven’t been until now; but, just earlier today we assigned this task to one of our product managers. So its something that is just starting up.
    There are really a couple of items here:
    (1) What can be done in the near future to make sure the PKGs and MSIs can be created out of CS4 installers? Is there something that must be enhanced in either PKGs or MSIs? We know that we should be able to repackage CS4 installers as PKGs since some of our customers already did so. So we’re seeing what can be done in the immediate future in this area.
    (2) Long term, if we want to move entirely to PKGs and MSIs we may need enhancements from Apple and Microsoft. So we’re starting to engage them now to see what is possible.

  25. Like other people above, I’m confused about the claims of the limitations of Apple’s PackageMaker. Mac OS X minor point release upgrades are distributed in Software Update as PKG files, and if I’m not mistaken the OS installs themselves are also PKGs. If your system of shared components is more complicated than an operating system, I think you’re doing it wrong.

  26. Kevin O'Shea says:

    I still haven’t read anything that seems like a total dealbreaker for using the native installers. I think if Shantanu Narayen walked down to your offices tomorrow and said, “Your new directive is to move to the native installers. Make it happen.”, you’d find solutions to all your problems.

  27. Eric Wilde says:

    Thanks to you all for all the feedback and pointers on the PKG issue. It seems that it surely must be possible to deliver PKGs in some way. There are some roadblocks still to navigate; but, you’ve proven that it should be possible to create PKGs of our installers.
    We may loose some configurability with PKGs, so we’ll have to study it carefully before committing to actually delivering as PKGs. Another possibility is to deliver a tool that easily takes output from our Deployment Toolkit and creates PKGs from it. That way there would be the possibility to customize the installers prior to creating the PKG. We’ll be investigating for the next few weeks and have an update post when we’ve made progress.
    For MSI, there hasn’t been much response on this blog. So we’ll have to reach out to MSI users in some other way.
    Kevin O’Shea writes: I think if Shantanu Narayen walked down to your offices tomorrow and said, “Your new directive is to move to the native installers. Make it happen.”, you’d find solutions to all your problems.
    This is too good of a line to let it pass by without comment. :^)
    Kevin, you’re probably correct. But what we’d like to do is engage with our customers and figure out what’s best with our customers rather than having an order from on high come crashing down on us. That’s kinda where we are with PKGs at this point.

  28. Lucien says:

    how do I find the adobe reader multimedia package.msi and get it on my computer so I can complete the download of reader from 7 on up to ver 9.0 ???????

  29. Eric Wilde says:

    Lucien writes: how do I find the adobe reader multimedia package.msi and get it on my computer so I can complete the download of reader from 7 on up to ver 9.0 ???????
    Reader really isn’t my playground since it isn’t a part of the Creative Suite. We do, however, have plenty of contacts in that area and I’ll forward your question to the appropriate party. We’ll follow up with you in email.

  30. Nick Peelman says:

    I’m coming to this party late, but I want to say that a lot of this goes back to App design. If half a shred of common sense would be put into the fundamental design of the applications, the install process would be much simpler.
    Why does an installer (or a separate app altogether) have to handle licensing? Is having such a convoluted licensing system (that gets defeated by the crackers within a week of release anyway) really helping your bottom line when you figure in the support costs, the disgruntled users who finally get pissed off enough at Photoshop to give it up completely, and the cost of actually maintaining the damned thing in the first place?
    There is very little reason for there to be content spread to-hell-and-back like you guys did on CS3 (CS4 is better, but still kinda insane, Illustrator on the Windows side installs its primary .exe in the Support Files folder, WTF). Sane file names, and being a good OS citizen by using not-ridiculous file trees is a good start. As far as apps using conflicting versions of files and the worry about apps installing on top of one another…on Macs, each app gets its app bundle, a ~/Library/Caches/, and a directory in ~/Library/Application Support/Adobe/. That’s where it lives. Every other apps lives in its containers. You want to write common frameworks then they should be _Common_Freaking_Frameworks_ that every app uses and is built upon, and when they get updated, every app using them gets updated and unit tested to look for regressions. This isn’t rocket science, its computer science, and Adobe is not the only big software shop out there, but they seem to be the only ones who have problems at this scale.
    I understand most of these points are NOT a problem of the installer, and are generally not within the installer team’s power to fix (suggest perhaps, but it is not you guys who ultimately need to clean up their act/code). But the points that you raise on licensing should be problems the individual APPS deal with, NOT the installer. The incompatibilities should be addressed at the program level to by preventing this from ever being an issue. At the same turn, uninstalling shouldn’t require a ridiculously complicated process.
    It just seems like the programming team puts stuff where ever they feel like putting it, with little consideration given to file permissions, OS requirements, etc. If this problem was fixed many of the rest of the problems would solve themselves.
    Everybody is quick to point out Office and Final Cut as being installed by packages. I will point out that *OS X* is installed by packages. All of its updates are installed by packages. 95% of everything else I use is a drag and drop install. But I know that that would be a pipe dream, to request a version of CS that could be drag-and-dropped, at least for the App install.

  31. assuriffub says:

    Can anyone recommend the top performing Software Deployment software for a small IT service company like mine? Does anyone use Kaseya.com or GFI.com? How do they compare to these guys I found recently: N-able N-central malware detection
    ? What is your best take in cost vs performance among those three? I need a good advice please… Thanks in advance!

  32. thinking is flawed here, sorry but i dont agree

Leave a Reply

Your email address will not be published. Required fields are marked *


5 + = twelve

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>