App-V Deployment MSI Fixups: Proper Rollback on Failure and Installing to Stand-Alone Clients From Network Print E-mail

If you are running the App-V client in a stand alone mode, you have probably run into some frustrating situations trying to get the MSI to install properly.  Worse yet, when the MSI package fails, it does not completely rollback the package addition to the client – so you end up with a half-baked deployment.  Let's take a look at the details and then give you some files and transforms that do all the work for you.

The Symptoms

The downloadable files in this solution are a part of the course App-V Sequencing Engineer (ENG-70).

Version Baseline: The following symptoms and solutions were experienced with an App-V 4.6 package that was built and tested on Windows 7.

I know it can be frustrating tracking a symptom to the cause – so I am going to spend some time here being fairly verbose about the evidence you should find if you are experiencing this problem.  Once you have confirmed you are experiencing this problem, you can skip ahead to the solutions.

If you have attempted to run a deployment MSI without copying it locally first, you may have seen any of the following errors:

On Screen

App-v MSI Package Error 

Application Virtualization Error
The Application Virtualization Client could not launch PSPad
The system cannot find the path specified.
Error code: 4605F3-14200C2A-00000003

App-V Client Log

[07/14/2010 12:32:31:561 AMGR WRN] {tid=390}
Attempting Transport Connection
URL: file://T:\ANYWAE\Virtualized Apps\App-V\PSPAD45.004\PS Pad Editor_3.sft
Error: 14200C2A-00000003

[07/14/2010 12:32:46:561 AMGR WRN] {tid=390}
Attempting Transport Connection
URL: file://T:\ANYWAE\Virtualized Apps\App-V\PSPAD45.004\PS Pad Editor_3.sft
Error: 14200C2A-00000003

[07/14/2010 12:33:01:561 AMGR WRN] {tid=390}
Attempting Transport Connection
URL: file://T:\ANYWAE\Virtualized Apps\App-V\PSPAD45.004\PS Pad Editor_3.sft
Error: 14200C2A-00000003

[07/14/2010 12:33:01:561 JGSW ERR] {tid=3F0}
The Application Virtualization Client could not connect to stream URL 'file://T:\ANYWAE\Virtualized Apps\App-V\PSPAD45.004\PS Pad Editor_3.sft' (rc 14200C2A-00000003, original rc 14200C2A-00000003).

[07/14/2010 12:33:01:561 MIME ERR] {tid=3F0}
The Application Virtualization Client could not complete the operation.

The system cannot find the path specified.

Error code: 4605F3-14200C2A-00000003

Windows Event Log Messages

The windows event log will include a succession of messages including Application Virtualization Client 3211, 5009 and 3001 followed by MsiInstaller 11708 and 1033

1. Event log errors - base problem

Application Virtualization Client 3211
Application Virtualization Client 5009
Application Virtualization Client 3001

MsiInstaller 11708
MsiInstaller 1033

Windows Installer Log Messages

SoftGrid Action: LoadSoftGridPackage Details: Action started
SoftGrid Action: LoadSoftGridPackage Details: Loading SoftGrid package.
SoftGrid Action:  Details: Action started
SoftGrid Action:  Details: Action ended
SoftGrid Action: LoadSoftGridPackage Details: Mime command failed. Error: 3 ,cmd: C:\Program Files\Microsoft Application Virtualization Client\sftmime.exe ,parms:  LOAD PACKAGE:{12A596CE-AE8F-41F8-A419-753C31C366CB} /SFTPATH "T:\\ANYWAE\\Virtualized Apps\\App-V\\PSPAD45.004\\PS Pad Editor_3.sft"
SoftGrid Action: LoadSoftGridPackage Details: Action ended
SoftGrid Action: LoadSoftGridPackage Details: Action ended
CustomAction LoadSoftGridPackage returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 12:44:25: InstallFinalize. Return value 3.

Problem #1: Rollback Leaves App-V Client Remnants

The App-V generated MSIs do not have rollback custom actions for the install custom actions that registered the package in the App-V client.  Consequently the rollback action leaves these entries intact.  This includes the shortcuts!

Launch Errors

If you attempt to launch an App-V application that has had in improper rollback, you receive many of the same errors as the initial install above, but with slight variations relating to launching the package.  If you run your MSIs completely silent the previous errors may not have presented, but the the following errors occur during an attempt launch.

On Screen

2. App-v launch error after ignoring msi error scenrio 1

Application Virtualization Error
The Application Virtualization Client could not launch PSPad
The system cannot find the path specified.
Error code: 4605F3-14200C2A-00000003

App-V Client Log (only differences versus install errors listed above)

[07/14/2010 14:20:39:875 TRAY ERR] {tid=AD0:usr=jane}
The Application Virtualization Client could not launch PSPad

The system cannot find the path specified.

Error code: 4605F3-14200C2A-00000003

Windows Event Log

2. event log after ignoring error

Application Virtualization Client 3211
Application Virtualization Client 5009
Application Virtualization Client 3008 (New as compared to install)

Application Virtualization Client 3001

Solution to Problem #1: Incorporate Rollback Custom Actions

You may be wondering if you can safely create rollback custom actions for the App-V generated deployment MSIs.  The answer is yes because it is essentially just duplicate to the existing uninstall custom action and tell it to do its magic only on rollback.

Enjoying your read? Subscribe to our newsletter (without loosing your place in this article).
(Please ensure that the confirmation email clears your spam filter so that you will see future mailings.)

Note: If you do not wish to do this manually, you can download the files for this article.  They include a transform that you can either specify with TRANSFORMS= or permanently merge into the MSI with an include script.

Note: Any mention of specific sequence numbers is subject to change whenever the App-V sequencer version changes.  (The sequencer generates these MSIs.)

Fixing this is accomplished by the following steps.  If you do them in a transform you will be able to apply them to all of your App-V packages: 

  1. Copy the custom actions RemoveSoftGridPackage and RemoveSoftGridPackage_CustomActionData and give them new names.  Let’s preface the names with RB_ for the sake of the rest of these instructions.
    “RemoveSoftGridPackage” becomes “RB_RemoveSoftGridPackage”
    “RemoveSoftGridPackage_CustomActionData” becomes “RB_RemoveSoftGridPackage_CustomActionData”
    ORCA: Right click Custom Action table row and select “Copy Row(s)” then Right-click and select “Paste Row(s)”
    InstallShield: Right click Custom Action and Select “Clone”
  2. Change the property name in RB_RemoveSoftGridPackage_CustomActionData to RB_RemoveSoftGridPackage (matches the new rollback custom action).
  3. Change the custom action execution mode to only run during roll back.
    ORCA: In Orca you would change the “Type” column in the “CustomAction” table from “11265” to “11521”.
    InstallShield: In InstallShield you would change “In-Script Execution” from “Deferred Execution in System Context” to “Rollback Execution in System Context”
  4. Remove the condition from “RB_RemoveSoftGridPackage”
  5. Insert the custom actions right before the existing custom action “AddSoftGridPackageOverrideURL_CustomActionData” (in the AppV 4.6 package I am working with this existing action is at sequence number 6549.
    IMPORTANT: “RB_RemoveSoftGridPackage_CustomActionData” must come first – I placed it at sequence number 6535.  Then add “RB_RemoveSoftGridPackage” at sequence number 6540.
  6. The final step of the deployment MSIs built by App-V is to run.


Problem #2: Requirement To Copy All Files Locally In Order to Install to the Stand-Alone App-V Client

So why can’t the App-V generated MSIs install locally without copying the files locally first?  To install the package locally the MSI package runs the custom action LoadSoftGridPackage.  This custom action requires administrator rights.  Whoever developed the code to generate the MSI dutifully followed the SDK with regard to how elevated custom actions should be built.  This includes setting the custom action to run deferred in the system context.

Custom actions marked in this fashion run under the system account.  Even if you run the package under a fully elevated administrator account, Windows Installer transfers control to the MSI service account for processing of all deferred standard and custom actions.  When processed by the system account, these actions have no access to the network.  The LoadSoftGridPackage custom action requires access to the .SFT where we run the MSI from in order to complete successfully, but it is cut off by running under the system account.

Of course if the files are copied locally, the system account can access these files and the LoadSoftGridPackage custom action completes successfully.

If you've been packaging with MSI for a while you probably wonder "Why can't the App-V client just use the SFT file that it just copied to the Q: drive to avoid this whole mess?"  The Q drive is only accessible to the App-V client, so msiexec.exe cannot access it.  There is another reason as well - your MSI package does not actually install the SFT.  If you look at the MSI log of these packages they copy ICOs, OSDs and the manifest.xml file to a subfolder of App-V.  The LoadSoftGridPackage custom action actually handles the processing of the sft.

Back to our underperforming custom action.  The SDK requirement to have the LoadSoftGridPackage custom action run under the deferred system context does not take into account that most package installs in corporate environments occur under Windows services that have full admin rights.  This means that in many cases the user account that started the package (software distribution service) has network access AND FULL ELEVATED admin rights!  Under Windows 7, services do not have a filtered token – in other words they run as the equivalent of an elevated admin.

Super Secret Trick: When testing for MSI behavior under software distribution that runs as a Windows service always do your testing from an ELEVATED CMD.EXE command console.  You don’t have to schedule a software distribution job for each test and in 99% of cases your test results will match the final test under the distribution system.

So, if this is your deployment scenario you can edit the package to change this one custom action and then you can install the App-V package from the network without first copying the files locally.

Before you get too excited, a couple caveats exist for this approach:

  • It does not work with Group Policy deployment because there is no way to elevate your session before msiexec.exe starts (the state of a Windows service running under the System account)
  • If your distribution system uses the system account to actually process distribution jobs, rather than a user account that has network access, then this solution will not work since the account starting msiexec.exe does not have network access.  (Some distribution system use separate accounts for accessing the network and for running jobs locally.)
  • If end users are expected to start the App-V generated MSIs in their own session, this method will not work – even if they are admins.
  • The functionality is dependent on Pre-elevated (before staring msiexec.exe) admin rights of the user id starting msiexec.exe.  This user id must also have rights on the network.
  • Drive letters may cause problems if they are not present for the ELEVATED user starting the package.  Although this should not affect most software distribution scenarios, it may affect you if you plan to start App-V deployment MSI's in the user context of users who are protected admins (admins with uac enabled).   Use UNCs.  See below for a link to a script that can find the UNC of any mapped drive letter.

Here are the steps for implementing this:

  1. Change the custom action attributes so that it will be executed deferred, but without System Context.
  2. In the next step use only UNC references in the next step.  (For a description of why and a script function that automatically determines a UNC from a mapped drive letter, check here.)
  3. Elevated a command console (CMD.EXE) and use msiexec.exe to run the package.

Our transform includes the following additional fixes as well:

  1. Rollback fix up discussed above.
  2. Uses a property to turn on the new behavior and retrains the standard behavior as the default.
  3. Turns on logging for MSI 4.0 and later (Vista or later or XP with MSI 4.5 – SP3 does not include 4.5)
  4. Checks to make sure package is pre-elevated and generates a failure message if it is executed in a non-elevated context.

If You Don’t Get It Quite Right

If you run the newly created package without elevating before calling MSI, you will receive this message:

App-V MSI Package Error for non-system context CA before install finalize

Application Virtualization Error
The Application Virtualization Client could not complete the operation.
You are not allowed to perform the action you attempted.  Some operations require you to be an Administrator or have special permissions configured.  Others cannot be performed when you are connected remotely to the Application Virtualization Client.
Error code: 4605F3-0F807904-00000A24

Pre-Elevating For Admin Users

If your users Are Admins and you want them to be able to double click App-V deployment MSIs on the network, then you will need to pre-elevate them.  This can be done via a custom shell extension.  Here is an example:


The files for this article include the registry file required to make the above context menu addition.  This technique is from Windows 7 Packaging Engineer (ENG-51).

The Files

The following files are included in the download.  They were created and tested on the App-V 4.6 Sequencer and Client running on Windows 7.  Based on a comparison of App-V 4.5 MSI packages - the files should work fine on 4.5 and Windows XP.  If you do not find this to be the case, please contact us!

  • FixAppVRollBack.mst - causes AppV packages to rollback correctly.
  • DeployAppVFromNetworkAndFixRollBack.mst - allows app-v package to be deployed from network UNC without being copied locally first.  Includes rollback fix and retains original package behavior for situations where it is required.
  • DeployAppVFromNetwork-AlwaysOn.mst - does not include extra logic to retain original package behavior (simplier).
  • applytransform.vbs and edit_me_permanently_apply_transform.bat - sample files for permanently applying the above transforms to an MSI or to the App-V sequencer template.msi which is usually located at C:\Program Files\Microsoft Application Virtualization Sequencer\resources\template.msi
  • MSI-MSP Context Menus - ADD Install Pre-Elevated Choice.reg - adds "Install (Pre-elevated)" to .MSI file context menu.
  • MSI-MSP Context Menus - Change Default Install to be Pre-Elevated.reg - makes default "Install" context menu always preelevate.
  • MSI-MSP Context Menus - Restore Normal Operation.reg - restore normal .MSI context menu.
  • README.TXT - instructions on how to use the above files.

App-V Sequencing Engineer (ENG-70)

This script is used in our training track App-V Sequencing Engineer (ENG-70). The course is designed to give you a solid background on the native Windows XP application runtime environment, bring you up to speed on the Windows 7 runtime environment and teach you about structured troubleshooting before diving into App-V sequencing.


To get your copy of the files we only require that you answer some survey questions and subscribe to our Newsletter (including confirming your email address). As with all our lists you can easily unsubscribe at the bottom of all future mailings.

Click here to get your copy.