Archive
App-V 4.6: So your Client Installation or Upgrade has failed: How do you break down the Logging?
App-V 4.6 is still very prevalent out there and will be for a while. With the releases of Windows 8 and Windows 8.1 brought additional service packs for the App-V 4.6 client which means upgrades and/new installs for newer operating systems. Several weeks back on this blog, I went over how to enable advanced MSI logging for troubleshooting MSI installs and upgrades (Remember VOICEWARMUP – https://madvirtualizer.wordpress.com/2014/03/17/enabling-advanced-windows-installer-logging/ ) but I would like to now address some follow up emails I received. Admins would like more specific information on how to go through and read that potentially enormous log in order to find out what is failing where and when.
I would never advising reading a verbose MSI installation log from start to finish especially when dealing with potentially asynchronous actions. MSI logs also have an excessive amount of rollback information incorporated into the log upon failed installations. The seasoned IT Pro often looks for specific keywords such as “error” and “failed” and that can be misleading as not all logs generate these types of messages. In addition, searching on the string “error” can also yield false positives as well.
When I am looking at Verbose MSI logs of App-V 4.6 client installs, I usually analyze the log by doing the following:
- Searching for the error string generated in the App-V Installer User Interface with quotations.
- Searching using the string “1603.” See if it indicates that a custom action has failed.
- Searching using the string “Value 3.” This will indicate an install error. This can also help to identify the custom action failure.
- Searching for string “IsInBadState()” can also be helpful if there is an issue with a failed driver install. This is especially useful in troubleshooting an upgrade. Usually when this occurs, you usually need to delete the driver configuration and state of the specific App-V file system driver specified in order to reattempt the upgrade.
Finally if you need to walk through the App-V custom actions, you can do so by searching by the strings ‘SWI” or “SGC” as all of the App-V custom actions begin with these prefixes.
CustomAction SWI41sp1UpgradeFix returned actual error code 1603
You can walk through the logging of each key App-V custom action. Once you’ve identified what custom action failed, you can then use the following reference to find out specifically what was being attempted with the custom action here: http://support.microsoft.com/kb/2465574. Even though it specifies SP1, it is still valid and helpful for SP2 and SP3. For example the action reference above would be:
Installer : Client
CA: SWI41sp1UpgradeFix
Method name: SWI41sp1UpgradeFix
Description: Modifies an installed instance of the Softgrid 4.1SP1/4.2 client application to correctly support upgrading to a later version.
You can then dive deeper into the timeline of the action and align it with a more deep logging utility such as Process Monitor.
Enabling Advanced Windows Installer Logging
Throughout my tenure while working in support, I would occasionally come across issues where the issue I was troubleshooting with a particular product was the actual installation. Too often the error would be some generic error (with an error code of 1603 or something similar) or one of those “unexpected errors.”
One way to get to more detailed information was to enable advanced debug logging of the Windows Installer service. You can enable advanced logging for a particular package by using the following synatx when attempting to run the installation:
Msiexec /i <path to your .msi package> /L*V C:\Setup.log
where the “L*V” is what enables the Windows Installer to create a verbose log file.
But what if you want to turn on debug logging for not just the packages being installed, but also for the Windows Installer service itself? This was used to isolate the strict name checking issue with App-V 5 MSI wrappers. You will need to do what we call the “Voice Warmup” trick. It gets its name from the fact that enabling all options spells out “voicewarmup.” To do so, do the following
1. From an elevated command prompt, stop the Windows Installer Service if started:
net stop msiserver
2. Open up the Registry Editor.
3. Navigate to the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.
4. Create a new string value (REG_SZ) called “logging.” (No Quotes)
5. In the data field, type “voicewarmup!” (No Quotes)
6. In the same key, you will also need to create a new DWORD value called “debug.”
7. In the data field, type “7.”
8. Exit the Registry Editor.
9. Restart the Windows Installer Service.
net start msiserver
After you install (or attempt to install) the application, the log files will be located in %TEMP%.
I would advise not keeping these values in place on a production server.
App-V 5: MSI Wrapper Caveats (Oh, and App-V WMI classes are different in 5.0)
For those enterprises using 3rd-party ESD (Electronic Software Distribution) products to deploy and manage software, use of the MSI-wrapper makes it easy to incorporate these types of applications into their environments. In App-V, when you “install” a virtual application using the MSI wrapper, all that is being done are custom actions that add and publish the package globally to all users on that machine. In addition, it will place an entry in the “Program and Features” list (formerly Add/Remove Programs.) This entry in the programs list is pretty much the difference between using the MSI to publish the application instead of manually using the PowerShell AppV cmdlets. Because of this entry, it is also advised to always use the programs list (or the msiexec /uninstall command) to remove the application instead of the manual PowerShell commands in order to prevent an orphaned entry from remaining.
It is also important to note that the MSI checks are more resilient in v5, where if you try to uninstall an application that is currently in use, it will echo a 0200000508 error:
Following the warning, the uninstallation stops, the package will remain and the entry will remain in the programs list. This is different from 4.6 where the entry would get removed while the virtual application would remain published and you would have to manually remove the application using SFTMIME cleanup commands. The specific error in 4.6 would be:
The Application Virtualization Client could not complete the operation.
The operation failed to complete because the package is still in use. Report the following error code to your System Administrator
Error code: xxxxxx-xxxxxx04-00001808
In 4.6, once you got the 1808 error, at this point you had to remove the application using the manual SFTMIME command (SFTMIME DELETE PACKAGE) http://technet.microsoft.com/en-us/library/cc843829.aspx
If you are using a 3rd-party ESD (Electronic Software Distribution) product to manage applications, you can query the WMI namespace for App-V to determine if a package is still in use in order to prevent this from happening.
If the package is indeed in use, you can then use the Stop-AppVClientPackage and/or Stop-AppVClientConnectionGroup cmdlet although the standard caveats apply with regards to open documents and unsaved information.
Speaking of WMI
In V5, the WMI classes are now located in a different namespace (rootappv) and the classes have been expanded to align with PowerShell objects. The classes are:
- AppVClientPackage
- AppVClientApplication
- AppVClientConnectionGroup
You can use PowerShell, VBScript, WMIC, or native/managed code to query WMI to get information about virtual applications, packages, and connection groups. For example, you can inventory packages using these PowerShell commands:
$VPackages = Get-WmiObject -Class AppvClientPackage -Namespace rootappv
$VPackages | Format-List -Property Name, InUse, PercentLoaded
What is really great about App-V 5.0’s WMI is the inclusion of Connection groups which allows extensibility for management of not only applications, but super-bubbles (especially with Configuration Manager 2012 SP1 – which actually refers to them as virtual environments.)
MDOP 2013 embeds APP-V MSI’s inside of EXE files
If you are looking for the MSI installer files for APP-V 5 SP1, you will need to manually extract them from the EXE files. The App-V 5.0 SP1 (Client/Server) MSI’s can be extracted using this command:
appv_xxx_setup.exe /Layout /LayoutDir=”<path>”
i.e.
c:temp>appv_client_setup.exe /Layout /LayoutDir=”c:temp”)
The language pack MSI will be laid out with the client or server MSI in the location/path specified in /LayoutDir.
This command is documented here http://technet.microsoft.com/en-us/library/dn144770.aspx.
MED-V 1.0: Windows Installer Service Retriggers MED-V Client installation When Trying to Start Workspace
Upon further investigation, I found that the installation was only installed for the user instead of the entire machine (the MED-V Client.) The MED-V Client was deployed silently using SCCM. The command line in the package to install the MSI did not have the ALLUSERS=1 flag properly set.
The resolution was to redeploy the client using the ALLUSERS=1 Flag. Due to the way the Windows Installer properties handle installations, this is the only remediation.
Refer to the following article:
madvirtualizer
The Mad Virtualizer at Microsoft 