What took getting used to was the direction set by the company that the most common package technique, capture msis, the methodology that spawned an industry and made Wise Adminstudio, Install Shield Admin Studio, and other freeware tools, was NEVER to be used.  Every “capture msi” in their portfolio was to be replaced with an install package that used the vendor installer!   Of course, the usual and customary package requirements, e.g. ”hands off installation”, “no desktop shortcuts”, “no startup prompts”,  “no license registration”, etc. had to be met.

Once I got over my initial shock (how can you package without a snapshot capture tool as a mainstay?) I was surprised at the ease with which SCCM ready packages could be created, without surprises, without snapshot captures.  I began to think about all the effort spent by packagers creating “snapshot capture msis”.

 Why had “snapshot captures” gained such widespread popularity?   I suspect they were manadated by Corporate IT.   There are certain advantages in the msi database technology:  consistent installer design and command line interface, support for install uninstall and repair,  common interfaces with Add-Remove-Programs and Shortcuts, etc.   The idea incompatible installers from different vendors could almost be  automatically reengineered and integrated with the corporate software deployment system was irresistable.   Too, the snapshot tools became mature and very reliable: they would find all the “before” and “after” changes to the file system and the registry and create an image.  The snapshot image could be edited and a well engineered msi could be generated, tested, and setup in the deployment system.  It seemed simple.  And it worked well for simple legacy applications that did not need to be changed.  But the approach was a failure with large and complex non-msi installations: such as ones with multiple spawned installers, file updates that required reboots,  or service starts.  Most packagers soon learned “when not to repackage”.

There were, of course, always ”hidden costs”.   First, a snapshot capture tool is never intelligent enough.   It will reliably find all the changes to files and registry, but it can not determine where the change came from.  Some are the packaged application (must include), some belong to the install process (can be ignored), and some belong to background machine processes unrelated to the application (must exclude – else they could break the machine upon uninstall!)   So in the end, the company is dependent on the packager’s “judgement and experience” to decide “what to include / what to exclude”  when creating the msi installer.   Obviously, the burden on the packager (and risk of error) increases with large applications having thousands of files and registry keys!   It should not be surprising that several days may be required to create and test a repackaged msi.   The assertion that some applications can not be repackaged as msis applies in these cases.

The greatest hidden cost is “increased complexity in troubleshooting”. A repackaged msi can not be supported by the application vendor.  A packager is in a lonely position when an application problem can not be reproduced with original vendor media.  A not-uncommon nightmare scenario occurs when two snaphot capture msi conflict with each other and the snapshots were done by different contract packagers during the previous OS migration project.  Perhaps it is this nightmare scenario that led to the use (plus overhead) of a ”conflict checking database” to isolate conflicts between poorly engineered vendor msis, and defective snapshot capture msis built in house.

As I continued working through the backlog, I realized neither I nor the company would ever need to confront these issues.  The package was what it was.  It would always check for and uninstall any previous or current version before the install.  If it could not be installed silently with setup.iss, I would use a scripted dialog.   It would apply the registry changes after the install.  The install result would be exactly what the vendor installer and my changes do, no more, no less and transparent to all.  An issue could be isolated to my code (which I fix) or the vendor installer (which I would document and workaround or forward to a vendor for ultimate resolution).

When I was all done, I had spent zero hours doing snapshot captures.  No effort editing snapshots, generating capture msis, exercising them, doing comparisons with vendor installers and troubleshooting.   No disk space is required to store snapshot images.  Most importantly, my reputation can not be tarnished by future issues with my snapshot capture msi installers.  

No more snapshot capture msis!  Not when we are witnessing the birth of a entirely new snapshot technology:  Microsoft App-V sequencing and virtual desktop images.  It may be the dawning of a new era but it seems like deja-vu to me.

1) msi. This approach can be used with snapshot capture msis or by creating a transform for a vendor based msi.  Either way, you create one  component and keypath for all custom HKCU registy settings.  After the installation, the first user launch (via a shortcut) detects the missing keypath and initiates a “repair” to populate the registry entries.

The limitations are: it is only applicable to msi installers, it only works if there is an exposed user interface such as a shortcut, and it can be time consuming to design / test / debug a “snapshot capture msi” or “vendor msi transform” to accompish this.

2) run once.   Build a *.reg file containing all the required HKCU entries and to copy the reg file to a known location on the machine.  Then populate the HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce key with a “regedit /s  c:\temp\hkcu.reg” command.   The install stages the setup.   The command runs with the next logon.  The approach is simple, powerful and easy to use.

The major limitation is it is only applicable for the next logon user, limiting the flexibility of the package.  For example, it will fail when used in imaging situation that contains an embedded restart and logon and it will fail when subsquent users log on to the machine.

3) populate user profiles externally.  I have seen custom “profile population routines” in several companies I worked for.  Essentially, the routine will populate the “Default User” profile and “every other profile on the machine” externally.

While the approach is powerful and flexible, a lot of code needs to be written to perform these functions that is very difficult to maintain and understand.  Also, the code incurs a great deal of overhead so that it’s repetitive use in many applications would probably increase the length of the setup process, much of it non productive.   Consider what would happen when adding a new application to a “shared machine” or a “training machine”, for example.   Ultimately, I don’t like this approach because it really attempts to use code to “engineer around” a fundamental attribute of the windows architecture, namely a separate database for each logon user.

4) active setup approach.   Create a component in HKLM\Microsoft\Active Setup\InstalledComponents\yourcomponent and a “StubPath” with the command as you would put in “Run Once”!.

At logon time, windows compares the HKCU and HKLM active setup components and, if it is missing from HKCU, will and the component an then run the stub!

This solution seems to me to be ideal: it is simple and works the same for both imaging and enduser logon.   So why is it so underused?

I suspect the difficulty is the method has it’s roots in Windows development and not system adminstration.  Active Setup?  Guids?  Stubs?  What the heck is that.  If only Microsoft called it “User Staging” (instead of Active Setup),  used application names (instead of Guids) to define components and called it “runuser” (instead of stub), all packagers would be using this method.

So now you know.

A software library must be organized and the organizational structure must be consistent across all different software applications.   This means the same organization structure must apply to all: Microsoft Office 2007 at one extreme and an obscure Excel plug in at at the other.

A software library must contain all the “code changes” needed to produce the install package as well as the directions for producing them.  This way, a knowledgable packager can reproduce what the previous one, step by step, if needed to isolate an issue or to produce the “next release”.

Finally, a software library should be ”self maintaining”.   NO CATALOGS to fall out of date.  NO ZIPFILES.   NO COMPRESSION.  No productivity drains in the process.

For my previous employer, the company software library was hosted in a secure server at a share named “Software Library”.     

a.  Below the Software Library folder were a series of application folders.   Each folder was named vendor – application

\Adobe – Acrobat Reader

\MS – Office 2007   

b.  The next level folder handled releases.   For example the subfolders for Adobe Reader included:

\7.0.9

\8.1.2

\9.2

c.   The critical folders are below the “version” folders

\notes – contains vendor install documentation plus high level and detailed instructions for creating the package.  My rule is include anything you “wish you had known” or “need to remember”.   You will be the best judge of the quality of  your instructions when you package the next release.

\source – contains an unchanged copy of the installer as it is provided by the vendor, either from a cd or downloaded.

\extract – contains an “unwrapped” version of the installer.   Usually, this meant extracting files from a zipfile or copying an embedded msi installer contained inside a “setup.exe”.

\snapshot – (when necessary) contains the “before and after” snapshot objects produced by the msi snapshot capture tool being used, i.e  Wise, Install Shield or other snapshot tool.

\package – contains all objects and only the objects required to produce a “complete install and setup” from a user with administrator access to the machine.  Must contain a script (*.bat, *.vbs or *.ps1)  able to produce an install without a dialog box and any required reboot suppressed.

The \notes \source \package folders were populated for every application I worked on.   

\extract was populated for 75% of applications I worked on.

\snapshot was populated for most all “non-msi” installers but never populated for an msi installer.

I added other folders when needed.  For example, I added a \admin folder producing an ”admininstrative install” .  Another example,  I added a \pre-snapshot cleanup folder with a script when multiple changes needed to be made to a “pre” snapshot to create the required msi installer.

“Work experience in a high demand project with short time frame to design and build a new deployment system”. 

“Use of Task Sequencer for deploying OS & applications is mandatory.”

It was the ”mandatory” use of Task Sequencer that caught my interest.   I understood the “task sequencer” is the virtualization component in the October 20 MDOP release ”just in time” for Windows 7  October 22.   In short a new product….

I felt sad.  Here was the new version of the long waited Microsoft OS. I had the skills of a packager but the use of the skill was banned due to a new Microsoft product that would solve everything.  Use the task sequencer,  create images, or don’t come to work for us!  Wow.  

To console myself, I began reading product documentation.  In this case, Microsoft’s “Application Virtualization 4.5 Sequencing Guide”.   I’d like to pass along some direct quotes from the documentation, things Microsoft explains about ”sequencing”,  i.e. Microsoft application virtualization imaging. 

5.  Sequencing Limitations.    Microsoft listed ”showstoppers”

a. applications exceed 4 GB in size

b. applications that start services at boot time

c. applications that require device drivers

d. applications shared by more than one application

e. applications that are part of the OS

f. applications that use COM+

g.”COM.DLL surrogate applications”.  

It appears to me that ”image builders” will encounter some of the same issues packagers encountered in building repackaged msis!

6. Sequencing Phases.   “There are four phases to sequencing a package; Installation, Launch, Customization, and Save. In this section I’ll give a high level overview of each phase”….  

It appears to me ”image builders” will be learning Microsoft’s way to separate the “snapshot captures” for the “install”, “reboot” and “configuration” steps that packagers do in producing silent installs. 

The successful creation of the four phases results these objects:  *.SPRJ, *.SFT, *.OSD, *.ICO, *.XML-Manifest, and *.MSI (to enable launch by Active Directory).  

11. Advanced OSD Scripting.  “One of the most common methods is making modifications to the OSD file to allow certain actions to be performed at a specified time during the execution of the application.”

It appears to me image creators will have a chance to be xml scripters (an *.OSD file is, an XML file that “starts the application using the objects generated by the sequencer”).  I expect seasoned  image creators will learn how to insert a *.vbs or *.ps1 inside an *.OSD file just like packagers learned how to put an *.vbs custom action inside an msi.

After reading, I felt better.  Packaging may done but a bright future lies ahead for those who “have experience creating images”.   I just updated my resume to include “Symantec Ghost”.

1.  How come?  Well, Adobe Reader is everywhere like a weed.  It can’t be killed.  It’s embedded in the installers of many desktop software products whose documentation is in the Adobe *.pdf format.

2.  In most companies, desktop applications are bought and installed at different times over the years, so they have different versions of Adobe Reader on the desktop.   When I started, we had Reader versions 5 through 7 on company desktop.  

3.  My manager had a vision: ”one version of Adobe Reader.   It was the Holy Grail.   At the time, the latest version was 7.0.9.    So I created an installer for 7.0.9 and made sure it could uninstall version 6 and earlier versions of 7 .  I wrote a script to uninstall 5.  I started pushing the rock up the mountain….

4.  At the time, the automated software deployment system was not ready so I just left the installer “as – is” until such time it would be ready.  It took longer than expected.

5.  By the time the deployment system was ready, the latest Adobe Reader became version 8.0.0.   I was initially pleased that Adobe provided a tool to “customize” the Reader install.  It was easy to use but I had misgivings because it created an msi transform.  There is a dark side to the msi transform that I feared….

A little bit of technical background….

An msi is a database.  A transform is a version specific database override.  At installation time the windows installer (msiexec.exe) applies both the database and the transform to produce the desktop “install result”.   So far so good.

Now there are two situations the msi installer needs to cover: the install (on a new machine)  and the upgrade (on an older version).  The problem is an msi + transform “works” on the new machine only.  It does not work on the upgrade: the only way to do it is uninstall the old version first!

4.  Normally, the transform isn’t a problem because the upgrade are not supposed to happen that all that often.  Adobe Reader is an exception.

5.  Hackers and Virus Writers discovered that Adobe Reader Versions above 7.x contained vulnerabilities that could be exploited.  By the beginning of 2009, Adobe Reader became the most vulnerable ”point of attack” on the desktop and security experts were warning against using Adobe Reader due to the risks it posed. 

6.  To their credit, Adobe did respond by patching Reader:  8.0.0 became 8.1.0 became 8.1.9 became 8.1.15 then 9.0 came.   I would  check for a new version msi, download it, build a transform, set it up in the deployment system, and began testing.  Then I would discover a newer version on the Adobe website.

Three times I pushed the rock up the mountain.  And three times it rolled down again.  Then I remember I wasn’t in ancient Greece, I was in modern day America.  And in America, three strikes and you’re out.  I surrendered.

7.  At last glance Adobe Reader is Version 9.2 in October 2009.  I do not expect it will be the last upgrade.  Just make sure your company antivirus software protects your computers against viruses and hacks embedded in *.pdf files launched by Adobe Reader.

Sisyphus, toil no more.

Five years after the production rollout of Windows 7, the packagers of the world will see it as a transformative event. 

My predictions are:

1) 70% of desktops will run Windows 7  (Windows XP will be second with zero installations of Vista in Business Environments).

2) Application virtualization will transform the nature of “software support”.  Third party integrators, with offshore employees. will provide applications through images.   These images will be maintained separately and independently of other desktop changes.  

3) And packagers will need to learn to be powershell programmers.  It will be a challenge of a lifetime: to learn O-O programming using UNIX command lines…… 

But in between now and then there is a detail that should not be overlooked.   Currently, more than 70% of the install base is a version of Windows XP!  And 0% of the install base use the production version of Windows 7, ship date October 22, 2009.

1.  Windows 7 will ship with Powershell 2.0.   A ship date for Powershell 2.0 for Windows XP has not been announced but I expect it to be available before the end of this year.

2.  Now I’m an enterprise IT manager and I’m thinking about Powershell.   I know my cost is people time and I need to think about how to use their time productively.   I know Powershell 2.0 is the future but I also know there is a learning curve, at best, my leads only know batch and vb script.  And they’re busy.

3. I’m thinking.   It would be good to use the same scripting language for all my XP and Windows 7 desktops but…

At least 100 customers complained to the VP last time we added some wsh commands to the logon script because they had wsh 5.6 instead of wsh 5.7.  So I need to think about “the effort and pain to get Powershell 2.0 on Windows XP….I need to first get all my Windows XP desktops to SP3, then I need to install and enable Powershell 2.0.   

4.  To do this, I need two projects: to upgrade XP to SP3 and to deploy powershell 2.0 to all the XP SP3 desktops.   Then I’m ready.   But do I really want to do this?   We’re telling everyone we need to replace XP with Windows 7 and now we’re doing two projects to make XP forward compatible with Windows 7…. 

5.  So as the IT manager, I direct my team “we are NOT going to use Powershell 2.0 on XP.   It isn’t worth our time to upgrade them.  So if plan to use Powershell 2.0 you need to make sure it will only ever be used on Windows 7 desktops and never on XP desktops. 

And while I encourage you to learn powershell, don’t use it if it will cause deadlines to slip.  When in doubt, just use vbscript….

Most admins, who have trouble writing a batch file and who only know how to modify a vbscript written by someone else are happy to hear “don’t use powershell”.

But a few forward thinking packagers understand where the opportunity lies and read the Wikipedia Powershell article: http://en.wikipedia.org/wiki/Windows_PowerShell.

And downloads the latest Powershell 2.0 from Microsoft: http://www.microsoft.com/downloads/details.aspx?familyid=7C8051C2-9BFC-4C81-859D-0864979FA403&displaylang=en

And he takes the first steps to become a Powershell guru.

But the effort to package is not free, it requires effort to discover and document the installation, to build and test and automated script.  Put simply, the effort put into packaging must be enough to justify the effort to 1) find a repeatable install process 2) build and debug the install package and 3) test the package in a controlled setting.   Every company I know sets a “minimum number” of installations before packaging.  The places I have worked in have set that number to 10 – 20 installs. 

The packaging process contains three clear and distinct steps:

1.  Environment Staging Process

The goal is to be able to reroduce a working installation on a baseline machine from start to finish.

If your work environment has regular user ids without ”Administrator” access to their machine, it is *CRITICAL*  to do the initial logon and application startup by a regular user.

 Many vendor installers simply fail to work properly when launched by a regular user logon.  While it is not the fault of the packager, it will be simpler to find a workround rather than calling a vendor (who will have nobody who understands msi technology or windows internals).

It is important the install with the Administrator account then start the application with the credentials of the logged on user.

a.  Collect all the vendor installers and installation instructions required to generate the working application.

b.  Review all vendor documentation and create a clean baseline machine with the vendor supported version and service pack of the operating system, such as Windows XP SP3 plus all documented requirements, such as Microsoft Office.

c.  Install the application and document the steps followed to “start and setup the application.

d.  Confirm with the application SME that the application is “complete and working correctly”, and document the “tests used” to prove application functionaliy.

2.   Packaging Process

The goal is to create a silent install that, when completed, permits a user to immediately start the application and do productive work without one time setup or configuration steps.

a.  Separate the different vendor installers

b. Find a way to have each installer start, complete the install, and quit without displaying a dialog box, suppressing all required reboot.

c. Then write a script to launch each installer one by one.   For each installler 1. check whether the install is needed and skip if already installed  2. do the install  3. check for successful install and exit with error code if the install fails.

3.   Package Testing Process

The goal is to confirm the package install, uninstall, and update produce the desired results.

Here, it is critical to do the install as the Administrator of the machine and to do the startup as a regular logon user.

1) Baseline Test

On a clean baseline machine, run the package and confirm application functionality using the tests done during Environment Staging.

2) Uninstall Test

On the same baseline machine, run the uninstall via Add-Remove-Programs and confirm all artifacts (files and registry settings) are removed.

3) Upgrade Test

For each currently supported older version, on a controlled environment, run the install and determine the upgrade install completes successfully and the application runs without error.

My own belief is packaging is “done” with the completion of step 3.   You have a working package that can be copied to a server share location and launched.  In some organizations, this is “more than enough”.  

In larger enterprises with thousands of user computers, this is more likely “not enough”   For packagers in these companies who also have the responsibility for “setting up the package in the deployment system”, I offer these hints, however each deployment system has it’s own quirks.

1. First and foremost, script in a language that can be used directly by your deployment system.   Some deployment systems do not work with *.bat and *.cmd.   Some powerful scripting tools, e.g. winbatch, require a separate compile step lengthens the script change process.

My recommendation is stay with vbscript.  All deployment systems will support it natively and you can always find “code samples specfic to your needs” by a quick internet search.   But in most cases, you do best to adopt the most widely used scripting language and avoid new ones.

2.  Second, most every deployment system worth anything supports “software package reuse”.   Find ways to “minimize variation”:  for example if you already have isscript11 setup and your application has isscript9, try using the existing package.  Often times “forward compatibility” is built in by the vendor.    You don’t need to expend effort on things that are not there and things that didn’t change.

3.  Third most every deployment system accepts msi, mst, and property table overrides so importing an msi and setting up the msi is trivial   However the first time deployment of any vendor msi is unpredictable.  

Many MSIs (vendor name and IT size mean nothing) are not engineered to support enterprise deployment.  Several times, I found out that due to bad msi engineering the only way to have the package install is: have the deployment system 1. copy the installer to c:\apps\source folder then,   2. start the installer at user logon by ”run once” registry key.

Simple enough for those accustomed to ”microsoft indirection” and one off design.

1. Copy the vendor source to your software library share location, specifically a \source subfolder.

By way of explanation, I recommend organizing your package share library by folder and subfolder:

 a top level folder with the vendor name, product and version i.e. Microsoft Office Visio 2003 SP3.

Below are subfolders

\notes             for vendor documentation and packaging notes
\source          for unaltered vendor cd and download
\package       for complete package with *.bat or *.vbs launcher
\extract         for separate ”extracted vendor installers”
\snapshot     for ”repackaged” vendor installer
\config           for “custom” settings

Only the \notes \source and \package folders are always populated in a completed package, the others are created when needed.

2.  On a cleanly imaged machine.  Do a complete manual install of using vendor source.  Then check with an SME that you have a working setup that meets all business requirements. Don’t begin packaging until your setup is confirmed by an application SME!

3.  From your earlier effort, you know the predecessors but you don’t know the vendor installer (yet).   Beware!  Once you are beyond Microsoft, Adobe, Symantec, expect anything and everything!  Many vendors provide proprietary installers and embed multiple msi installers inside their *.exe file.  Most msi installers have design defects and have many many custom actions so their behavior a vendor installer is unpredictable.  

4. Some internet vendors use installers that require access and download from the internet and do not even supply a standalone installer.  If your customer made a commitment to such a vendor without consulting IT, your only choice is ”script the install steps”. Make certain you check vendor website availability send an error message saying vendor xxx site is down.  This way, your help desk will know who to call when the “package doesn’t work”. 

5. If the vendor provides a standalone installer, extract the installer into embedded installers and identify the separate installers used (either *.exe or *.msi).   Beware.   Due to corporate mergers and acquisitions I have several examples of embedded installers inside embedded installers: with each takeover vendor adding an additonal embedded layer.  

6. A well designed installer has documented command line options for extraction.  Others do not and purge installer source objects after the install (effectively breaking msi repair functionality).  For these, start the install dialog but pause at the last dialog before the install begins.   Then look for the location (usually in a local settings\temp subfolder in your user profie) that contains the installer source.  Copy it to the \extract folder.   

7. If you find any embedded installers (such as Adobe Reader, Microsoft Visual C++ Redistributable,  Microsoft Active X,  Sun Java JRE Runtime, Install Shield Script) package them separately as package dependencies.   You will reuse them.

8. After you have extracted the installers, consult Apps Deploy to research how others may have attempted to handle the same application.  They provide important clues but don’t count on them until they are “proven to work” on your desktop.

9.  In the absence of documentation, I suggest the following “generic tips” for handling vendor installers:

a. if the installer is non-msi and the vendor is defunct, repackage the installer as an msi.   Capture msi’s will be well designed, clean and not have “custom action workarounds”.

b. if the installer is msi, do not repackage the msi installer.  Repackaging an msi is never productive, do anything else.

c. if an extracted msi installer “errors out when run” and “isscript” is visible, install isscript.msi as a predecessor and try overriding the default properties with ISSETUPDRIVEN = 1.   Other custom actions in the INSTALLEXECUTESEQUENCE table may also need to be eliminated by commenting them out, i.e. by putting a negative sign in the run sequence number entry.

d. if an msi installer requires “non default settings” set through a dialog box, create a “response transform” to apply with the msi.   Other than documented vendor support for transforms like Adobe, this is the only situation where I  recommend a transform over a direct msi edit. 

10.  Simulate the behavior of the complete install package by 1. installing the package as the Adminstrator (no access to domain resources) and 2. logging on as the first time user and starting the application. 

11.  Once any installer not currently in the deployment system passes step 10,  set it up in the deployment system and make sure it works and mark it complete.

12.  Conversely, fix any defects and do NOT setup any installer in the deployment system until it is 100% debugged outside the deploy system.

1.  The initial excitement comes with the ease with which msi can be imported and set up automatically!

2. The initial testing occurs and results seem positive but anomolies are noticed in that custom user settings are “not correct” even though they tested “perfectly fine” outside the deployment system.

3. Panic sets in when it is realized that the deployment system performs installs with the credentials of the local administrator account.  With a bit of reflection, the desktop engineer realizes “admininstrator” 1) has no access to the credentials of the logon user and 2) has no access any domain resources and can not be made a domain member.

4.  Panic gives way to a sober assessment that some packages and scripts completed before this realization need to be redone.   But how?

Well, my experience with the initial setup design for more than one deployment system suggests:

First, determine whether your deployment system supports deployment using the credentials of the logged on user; check out what happens when you “push an install to a machine without a logged on user”.   The result will tell you “whether your deployment system” can help with the issue.  Don’t be surprised to discover there is no other viable option than to deploy using the administrator (or service) account.

Second, pick on one basic approach for applying custom HKCU registry settings.   All approaches assume you have isolated the HKCU registry settings that need to be applied, probably in the form of an *.reg file.

Approach 1.  add the registry keys and component (with keypath) to the msi so they will be installed with a repair when launched by the logon user.

Approach 2. add the registry keys and component (with keypath) as an msi transform and install with the msi.   They will be installed with a repair when launched by the logon user.

Approach 3.  script the change using vbscript.  Create a second vbscript that essentially copies the “registry change” vbscript to a known location on the machine and sets the HKLM ‘run once’ registry key.   This will run with the next user logon.

While all approaches “work”, they are not the same in ease of maintenance and user acceptance.

Approach 1:  results in the “cleanest” installer but it can be very time to introduce this change on an unfamiliar msi.  Worse, the change has to be reintroduced each time the msi gets updated.   Also, the necessity of a “repair” at first startup can generate questions to the Help Desk.

Approach 2: is the textbook approach but, in my option, is the most costly to maintain.   Because transformed installations can NOT be updated later by a second transform, an uninstall must be performed when the msi gets updated.   The same startup issues apply.

Approach 3: is my preferred approach when I expect the msi will be updated in the future.   By separating the customization from the installer, the next version is far simpler to build, indeed if no custom registry changes occur, the old script can be reused with the newer version msi! 

 The ”repair dialog box” never appears.  The machine script location is documented for reuse by all when a new user logs on the machine.

Another advantage is this approach works “transparently when access to domain resources” is needed to complete a setup – very difficult with msi only.

By the way, when scripting a registry change, it is a best practice to contain all logic in the script rather than having a script apply an external *.reg file.   One object in the deployment system is simpler and simpler is better.  KISS.

2.  Broadly, an msi database contains two different kinds of tables: ”content” tables to organize changes to be installed on the desktop and “run” tables add or remove objects to the desktop.

3.  Content tables are organized heiarchically.   The heiarchy is: Feature, FeatureComponent, Component.   A component may contain keypath, a file or registry key used to check whether the component is installed.   This means each file (or registry) belongs to one component, which belongs to a featurecomponent, which belongs to a feature.   Installs are managed “by feature” – either every component in a feature gets installed or none at all!

4. Run tables process commands using the windows installer program, msiexec.exe.   When an msi is double clicked, the InstallUISequence table process dialog box responses and updates the properties table.  When the last instruction last instruction is comple, control passes to the InstallExecuteSequence table to do the installation.  Completely different tables handle the ”Administrative” and “Advertised” installs. 

5. A silent install (msiexec.exe /i  /qn) bypasses the InstallUISequence table and begins the install using default setups of the Properties table.   The reason so many msi silent installs fail to work properly is bad msi engineering:  the defaults in the properties table are invalid or the code is unstructured.

6. A transform is a “database override” applied together with the original msi by the msiexec.exe command at installation time.  As such, it is a one shot approach: it is not possible to update a “transformed installation” by applying the same msi with a different transform, it is always necessary uninstall the transformed installation to install a changed version.

7.  Usually, it is easier to modify the original msi (work around the design flaw) rather than creating a transform.  An exception is the “response transform”: a fixed response to the InstallUISequence applied with an original msi by msiexec.exe to produce a working silent install. 

8.  A custom action is a “workaround” to perform actions outside the control structure of msiexec.exe (windows installer) and the msi database.   It is true that custom actions are flexible and powerful.  It is also true that custom actions undermine the integrity of the msi and can be difficult to troubleshoot and maintain.   Avoid them whenever possible: find a better way before using one and, as needed, work around those introduced by outside vendors.   Really.