The Virtual Shell

App-V 5 – Reporting and TargetInPackage

Dafalk — Mon, 03 Oct 2016 18:37:55 GMT

Hi all, Following on from my previous post about scripting and TargetInPackage, the inbuilt reporting functionality of the App-V Client is also interesting when a package has TargetInPackage set to False. https://blogs.technet.microsoft.com/virtualshell/2016/09/14/app-v-5-scripting-and-targetinpackage/ To enable the reporting functionality the “ReportingEnabled” client configuration needs to be set to 1, so that the client collects launch information. Once this has been enabled then reporting information will be captured. The location of the reporting information is held locally on the machine in the following folder:

C:\ProgramData\Microsoft\AppV\Client\Reporting

Within this folder you will find that there aren’t any files as the files are hidden by default, so you will need to show “Hidden Items” from the “Show/Hide Menu”, once it’s been enabled you will see the xml file holding reporting information. If you open the XML file you will find applications that have been launched and have registered launch information. So, what happens when you launch an application that has TargetInPackage set to false? As per the previous post I’ve launched the HTA application that shows the Operating System Version your using: When you open the reporting XML you won’t see any information for the HTA application? To confirm functionality, I’ve launched my favourite application “Remote Desktop Connection Manager” and you will see below the XML has been updated. Why is this important to understand? Some customers used App-V 4.x to deliver Internet Explorer shortcuts to users e.g. This would then be added to the 4.x reporting XML. In App-V 5.x if TargetInPackage is set to False then this information isn’t added to the reporting information. Hope this helps you understand why reporting information isn’t written to the reporting XML file if TargetInPackage is set to false. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5 – Scripting and TargetInPackage

Dafalk — Wed, 14 Sep 2016 18:47:24 GMT

Hi all, The following post with go into detail about why an App-V script doesn’t run when launching an application, its related to how the App-V Sequencer captures an application. The first thing to note is that what I’m sequencing is an HTA Application which customers use and deliver to their users. A description of what an HTA Application is below: HTML Applications (HTAs) provide a way for you to wrap your scripts up in a graphical user interface, an interface replete with check boxes, radio buttons, drop-down lists and all those other Windows elements you’ve grown to love. https://technet.microsoft.com/en-us/library/ee692768.aspx The HTA that’s been sequenced shows which Operating System Version your using: What I’ve done is created an exe in the scripts folder within the package that needs to be ran on "StartVirtualEnvironment" user script, a custom UserConfig.xml file has been created to add the script. The script has been added to the XML, now to add it to the client using PowerShell with the "-DynamicUserConfigurationPath" parameter: Now when you run the application no script is ran and the application launches as normal. The question is how do you check if any App-V scripts have run and that’s where the App-V Operational Log comes in handy as it logs all "Execute Embedded Scripts" events, e.g. For more information on the Operational Event log check out one of my posts: https://blogs.technet.microsoft.com/virtualshell/2016/04/12/app-v-5-operational-log-usage/ The Operational Event Log doesn’t show any "Execute Embedded Scripts" event so how do you figure out what’s happening here? If you launch the application and check "Get-AppvVirtualProcess" you will see that there are no Virtual Processes for OS_Version.hta… Next was to use "Start-AppvVirtualProcess" to open the package to see what happens and interestingly the Start.exe "AppDemo1" launches…. In the Operational Event Log, you see the “Execute Embedded Scripts” event log entry for Start.exe. And with “Get-AppvVirtualProcess” you will see Start.exe running… So why doesn’t the script run when you launch the shortcut for the application? If you check task manager after you have launched the application, you will see that the EXE that has launched the application is mshta.exe which resides in the C:\Windows\SysWOW64 directory.

"C:\Windows\SysWOW64\mshta.exe" "C:\Users\username\AppData\Local\Microsoft\AppV\Client\Integration\3859F634-0043-4494-B409-57593516FF21\Root\OS_Version.hta" {1E460BD7-F1C3-4B2E-88BF-4E770A288AF5}{1E460BD7-F1C3-4B2E-88BF-4E770A288AF5}

If you’re wondering what the "{1E460BD7-F1C3-4B2E-88BF-4E770A288AF5}{1E460BD7-F1C3-4B2E-88BF-4E770A288AF5}" is after the .hta has been called, its specified in the operating system Classes key (HKCR) for the htafile. The above is a lot of context about what happens but what’s the cause of why the script doesn’t run? Well it’s down to a setting in the AppxManifest.xml file called "TargetInPackage". If you open the AppxManifest.xml file from the package and browse to the Applications section, you will see that the TargetInPackage is set to "false" for OS_Version.hta. So, what does "TargetInPackage" mean and why doesn’t it start a user based script??? When you sequence an application, the sequencer determines where the EXE is that launches the application. In this instance when you launch a HTA file, mshta.exe isn’t part of the package as it’s a windows component so it sets the flag for that EXE that it isn’t in the package. As the EXE isn’t in the package the App-V client doesn’t run hta within the virtual environment it runs it natively on the operating system. As the script that I’m testing with is "StartVirtualEnvironment" as the environment hasn’t started no script is ran.

"C:\Windows\SysWOW64\mshta.exe" "C:\Users\username\AppData\Local\Microsoft\AppV\Client\Integration\3859F634-0043-4494-B409-57593516FF21\Root\OS_Version.hta" {1E460BD7-F1C3-4B2E-88BF-4E770A288AF5}{1E460BD7-F1C3-4B2E-88BF-4E770A288AF5}

There are multiple applications that will have the same behaviour e.g. HTA, Internet Explorer shortcut or any other windows component. Hope this helps you understand why a package script doesn’t run if the TargetInPackage is set to false. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5 – Virtual Service subsystem failure 2A-00000436

Dafalk — Mon, 12 Sep 2016 17:24:12 GMT

Hi all, An error I came across recently was the following error message that’s presented to the user after launching an application. App-V 5.1 Client - 0x84000D2A-0x00000436 / 0x84000D2A-00000436 If you look in the event log you will see the following message:

Process 68 failed to start due to Virtual Services subsystem failure. Package ID {3AAC90AC-7517-496E-A137-60301CB41ADC}. Version ID {57CB1B48-10D6-4DF4-B90D-2483DA241CA2}. Error: 0x84000D2A-0x436

Whenever we receive these messages you need to do a debug on what the error code translates to and which debug event log to enable. The error code translates to the following:

Code: 84000D2A-00000436
Result: Error
Type: Windows
HRESULT: 0x00000436

# for hex 0x436 / decimal 1078
ERROR_DUPLICATE_SERVICE_NAME winerror.h
# The name is already in use as either a service name or a
# service display name.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x436
# for hex 0x436 / decimal 1078
ERROR_DUPLICATE_SERVICE_NAME winerror.h
# The name is already in use as either a service name or a
# service display name.

From a debug perspective you can enable the following log:

App-V 5.1 - Microsoft-AppV-Client/Debug (ServiceLog)

In the debug event log, you will see the following message: From the error message the only way that this error message can occur is if the application that your trying to launch is in a connection group and the "Duplicate virtual service AppDemo Updater" gives this away. If you check the connection group, you will see there are two packages in the connection group. If you open up each package and check the AppxManifest.xml you can see the Virtual Services configuration both have the same Service Name of "AppDemo Updater". AppDemo1 – AppxManifest.xml AppDemo2 – AppxManifest.xml Now we know the cause how can you fix this? Well it’s the deployment configuration file to the rescue. The deployment configuration file has a flag which states whether the services are enabled, if you set this to "false" the Services in that package won’t be deployed (Note: Its been disabled in the AppDemo2 package). When you deploy the package to the machine only the package with Services Enabled="true" will be available in the connection group. Once this is done then the application launches as expected. Hope this helps you troubleshoot and fix this error if you come across it. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5 – Publishing Server Global Refresh Enabled

Dafalk — Wed, 31 Aug 2016 18:49:10 GMT

Hi all, Have you ever wondered how the App-V Client functions when adding a publishing server to the App-V client? This post should help you understand what happens behind the scenes and I need to be clear there is a difference between versions of the client and this is explained below. When you add a publishing server using "Add-AppvPublishingServer" cmdlet the default settings set on the client is the below: The explanation of each key setting from Technet are:

GlobalRefreshEnabled - Enables global publishing refresh (Boolean)
GlobalRefreshOnLogon - Triggers a global publishing refresh on logon. (Boolean)
UserRefreshEnabled - Enables user publishing refresh (Boolean)
UserRefreshOnLogon - Triggers a user publishing refresh onlogon. (Boolean)

https://technet.microsoft.com/en-us/itpro/mdop/appv-v5/about-client-configuration-settings Basically and a key point here is that the GlobalRefreshEnabled and UserRefreshEnabled settings allows a non-admin user to initiate either sync via PowerShell if they are set to "True", if they are set to "False" a non-admin user can’t initiate a sync manually. So when you do a sync as a user in the “Operational” event log you will see the following 3 events:

19001 – Publishing Refresh started. URL: https://appvserver:8181 Global: false
19804 – File type associations, shell extensions, and shortcuts updated.
19002 – Publishing Refresh stopped. URL: https://appvserver:8181 Global: false

This is where it gets interesting and this will only occur with the SP3 client and above and I will explain why. If you change the Publishing Server configuration to enable GlobalRefreshEnabled and GlobalRefreshOnLogon using the Set-AppvPublishingServer cmdlet you will see the following result. If you check the Operational event log now you will now see 6 event in the operational log on a USER sync using "sync-appvpublishingserver 1". (Note: I cleared the event log before initiating this sync) If you look at the event that’s highlighted below you will see something interesting that in the first event 19001 the Global flag is set to "true"!!!!!!!!!!! Why is the Global flag setting "true" when a user has a user refresh only??? If you check the KB for App-V 5.0 SP2 Hotfix 5 we introduced a new feature and note a key piece of text "by using Windows PowerShell." Issue 1: Connection groups cannot support both user-published and global-published packages App-V 5.0 SP2 does not let you create user-entitled connection groups that contain both user-published and global-published packages. With this hotfix release, App-V 5.0 SP2 supports creating user-entitled connection groups that contain user-published and global-published packages by using Windows PowerShell. https://support.microsoft.com/en-gb/kb/2963211 What happened with the SP3 release we extended this support for the App-V Publishing Server on the App-V Client to ensure a connection group could be created that has both machine and user published packages. On a user "sync-appvpublishingserver 1" the client completes a global sync first then a user sync to ensure the connection group can be created. Why is this important to understand? It’s especially important when using Remote Desktop Services where users share the same machine. If a user completes a sync and updates a machine configured package, then the App-V client will send those packages into a pending state and remember to update a machine / globally published package all user MUST log of the machine for that change to take effect. The next question is there a way to turn this off? Well there is a way if you set the publishing server GlobalRefreshEnabled to false then if a user does a user sync the global sync won’t occur. Hope this helps in understanding what happens when syncing against our publishing server. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5 – Troubleshooting the Client using the Event Logs

Dafalk — Thu, 25 Aug 2016 18:56:53 GMT

Hi all, The App-V event log holds lots of great information but the challenge you my face is you have to jump between logs to figure out what actually happened on the client if errors occur. There are 3 default logs that you can use when troubleshooting, they are the Admin, Operational and Virtual Applications log. The challenge with having three logs is that you have to look into them individually, you can’t see them all together unless you are using logman tracing. https://blogs.technet.microsoft.com/virtualshell/2016/05/16/app-v-5-0-etw-tracing-automation-update/ Following on from a post I did about the Operational Log, there are times where when you collect event log information you don’t want to collect certain events that create “noise” in your trace, these were explaining in the following post. https://blogs.technet.microsoft.com/virtualshell/2016/04/12/app-v-5-operational-log-usage/ The post above explains the filter to remove the streaming events, with the App-V 5.1 client there are some new event ids which are quite chatty so they have been included below: So you know how to do a filter manually using the GUI but how about via script? With PowerShell there is a cmdlet which collects event log information which is called “Get-WinEvent” and it has a great parameter called “-FilterXml” and its explained below.

-FilterXml 
Uses a structured XML query to select events from one or more event logs.

To generate a valid XML query, use the Create Custom View and Filter Current Log features in Event Viewer. Use the items in the dialog box to create a query, and then click the XML tab to view the query in XML format. You can copy the XML from the XML tab into the value of the FilterXml parameter. For more information about the Event Viewer features, see Event Viewer Help.

Typically, you use an XML query to create a complex query that contains several XPath statements. The XML format also allows you to use a "Suppress" XML element that excludes events from the query. For more information about the XML schema for event log queries, see the following topics in the MSDN (Microsoft Developer Network) library.

-- "Query Schema": https://go.microsoft.com/fwlink/?LinkId=143685 
-- "XML Event Queries" in "Event Selection": https://go.microsoft.com/fwlink/?LinkID=143608

To use the filter using Get-WinEvent you need to get the XML you want to use, so if you create your filter in Event Viewer and then select the “XML” tab you can see the generated XML with the filtering out of Operational Log event IDs (14023,14024,14025,14026,101,102) and its filtering on the last 24 hours of logs. So you have your filter you can now use Get-WinEvent to collect the Operational Log information with the filter set.

$FilterXML_Operational = @"

  
    
    *[System[(EventID=101 or EventID=102 or EventID=14023 or EventID=14024 or EventID=14025 or EventID=14026)]]
  

"@

Get-WinEvent -FilterXml $FilterXML_Operational -ErrorAction SilentlyContinue

Note: I’ve used the -ErrorAction SilentlyContinue due to the fact that if there is no information it will display an error stating there are no events. To expand this to the Admin Log and Virtual Applications log the following code can be used:

$FilterXML_Admin = @"

  
    
  

"@

Get-WinEvent -FilterXml $FilterXML_Admin -ErrorAction SilentlyContinue

$FilterXML_VirtApps = @"

  
    
  

"@

Get-WinEvent -FilterXml $FilterXML_VirtApps -ErrorAction SilentlyContinue

Now we have all three event you can join these together and sort them by “TimeCreated” so that it shows them in chronological order.

$GWE_All = Get-WinEvent -FilterXml $FilterXML_Admin -ErrorAction SilentlyContinue 

$GWE_All += Get-WinEvent -FilterXml $FilterXML_Operational -ErrorAction SilentlyContinue 

$GWE_All += Get-WinEvent -FilterXml $FilterXML_VirtApps -ErrorAction SilentlyContinue 

$GWE_All | sort TimeCreated -Descending

This will output the following data: It’s great to show this in PowerShell but did you notice that only four column properties have been specified in the output to screen? What if you want more data from the event log to be shown? You can run the Get-WinEvent command with the Get-Member switch which will show all the properties available on the object:

Get-WinEvent -FilterXml $FilterXML_Operational -ErrorAction SilentlyContinue | get-member

This will show all the properties that you can use on the output. To specify the properties that you want to output you need to select the objects that you require, for demo purposes I’ve used the following:

$GWE_All | select TimeCreated,Id,LogName,TaskDisplayName,LevelDisplayName,Message

Now we have all the properties available there are better ways of formatting the output, you may like Out-GridView or ConvertTo-Html so I’ve included them both in the script below.

<#
.DISCLAIMER The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
#>

# Adding threading culture change so that get-winevent picks up the messages, if PS culture is set to none en-US then the script will fail
[System.Threading.Thread]::CurrentThread.CurrentCulture = New-Object "System.Globalization.CultureInfo" "en-US"

$FilterXML_Admin = @"

  
    
  

"@

$GWE_All = Get-WinEvent -FilterXml $FilterXML_Admin -ErrorAction SilentlyContinue

$FilterXML_Operational = @"

  
    
    *[System[(EventID=101 or EventID=102 or EventID=14023 or EventID=14024 or EventID=14025 or EventID=14026)]]
  

"@

$GWE_All += Get-WinEvent -FilterXml $FilterXML_Operational -ErrorAction SilentlyContinue

$FilterXML_VirtApps = @"

  
    
  

"@

$GWE_All += Get-WinEvent -FilterXml $FilterXML_VirtApps -ErrorAction SilentlyContinue

$GWE_All = $GWE_All | sort TimeCreated -Descending

#################
# Out-GridView
#################

$GWE_All | select TimeCreated,Id,LogName,TaskDisplayName,LevelDisplayName,Message | Out-GridView

#################
# Convertto-Html
#################

# HTML output path and name
$HTML_Output =  "c:\temp\allEL.html"

# Style Sheet for HTML Report
$CSS = ""

$GWE_All | select TimeCreated,Id,LogName,TaskDisplayName,LevelDisplayName,Message | ConvertTo-Html -head $CSS -body "All App-V 5 Event Logs" | Out-File "$HTML_Output"

invoke-item $HTML_Output

Out-GridView will be displayed like this: ConvertTo-Html will show something like this: SCRIPT DISCLAIMER The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. This helps us internally troubleshoot the App-V 5 client as it allows us to see everything in a single view, so I hope it helps you as well. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5 – Virtual Shell subsystem failure 2A-00000002

Dafalk — Sat, 20 Aug 2016 17:12:27 GMT

Hi all, I came across a really interesting error code recently and thought it was worth sharing why it occurs, the error message that’s presented to the user looks like this when launching an application. App-V 5.0 SP3 Client - 0x9B50172A-0x2 / 0x9B50172A-0x00000002 App-V 5.1 Client - 0x9B501A2A-0x2 / 0x9B501A2A-0x00000002 You can see that the error codes are different but they are the same error code, its the changes in the client version that causes the difference. If you look in the event log you will see the following message:

App-V 5.0 SP3 Client
Process 4564 failed to start due to Virtual Shell subsystem failure. Package ID {a3ee2888-fda4-43b8-8ca5-7c2b58a26893}. Version ID {37bdd39e-3760-47f0-b950-2b01e6827930}. Error: 0x9B50172A-0x2

App-V 5.1 Client
Process 4260 failed to start due to Virtual Shell subsystem failure. Package ID {a3ee2888-fda4-43b8-8ca5-7c2b58a26893}. Version ID {37bdd39e-3760-47f0-b950-2b01e6827930}. Error: 0x9B501A2A-0x2

Whenever we receive these messages you need to do a debug on what the error code translates to and which debug event log to enable. Both error codes translate to the following:

Code: 9B50172A-00000002 / 9B501A2A-00000002
Result: Error
Type: Windows
HRESULT: 0x00000002

# winerror.h selected.
# 2 matches found for "0x00000002"
# for hex 0x2 / decimal 2
  ERROR_FILE_NOT_FOUND                                           winerror.h
# The system cannot find the file specified.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x2
# for hex 0x2 / decimal 2
  ERROR_FILE_NOT_FOUND                                           winerror.h
# The system cannot find the file specified.

From a debug perspective you can enable the following logs dependent on the App-V Client version your using:

App-V 5.0 SP3 - Microsoft-AppV-Subsystems-VShell/Debug 
App-V 5.1 - Microsoft-AppV-Client/Debug (ServiceLog)

In the debug event log, you will see the following message: The question now is what are the Integration points with the App-V client? Rules of integration When App-V applications are published to a computer with the App-V Client, some specific actions take place as described in the list below:

Global Publishing: Shortcuts are stored in the All Users profile location and other extension points are stored in the registry in the HKLM hive.
User Publishing: Shortcuts are stored in the current user account profile and other extension points are stored in the registry in the HKCU hive.

https://technet.microsoft.com/en-us/itpro/mdop/appv-v5/application-publishing-and-client-interaction If you check the registry for the user, you will see the integration points for the packages published to the user. There are two keys:

Integration Location: The integration location is the path in the file system to the junction point of the package using the PackageID only
Staged Location: This is the real location within the App-V cache with both the PackageID and VersionID specified

If you check the junction point in explorer you will see that the integration location is pointing to the staged location without the version GUID. To prove that this is the case you can run the following commands which will display the junction points from the Integration location:

cd %LOCALAPPDATA%\Microsoft\AppV\Client\Integration
dir /AL

That’s the context of what the integration point is with App-V but what causes the error? If you check the package that’s causing the error in my case, it’s the PackageID “A3EE2888-FDA4-43B8-8CA5-7C2B58A26893” which can be seen from the debug event log. Note: This is important the Virtual Shell subsystem failure will return the PackageID of the package, if the package is in a connection group then the PackageID and VersionID will actually be the Connection Group GroupID and VersionID so make sure your using the debug event logs for finding which package is causing the issue. You can see below the IDs have changed as the package is now in a connection group.

Process 600 failed to start due to Virtual Shell subsystem failure. Package ID {8d7a6c1a-0336-4a3f-a758-c3d7c4a2b225}. Version ID {735fa6ea-7ce8-4c85-b4f7-186fd97f26e6}. Error: 0x9B50172A-0x2

If you check the PackageID it returns the following and it shows something really interesting that the package is published globally and not to the user. The package not being published to the user is the interesting point here as if you check the registry for the user you will see that the integration point is set in the users registry hive: That’s the cause of this error code, the App-V client reads the integration point information in the registry to check where the integration location is, it then checks if the path is valid and if its not it causes the "sytem cannot find the file specified" hresult. If you delete the key “{A3EE2888-FDA4-43B8-8CA5-7C2B58A26893}” or remove the “Integration Location” and “Staged Location” entries then the application will launch successfully. If you want to check if you have a mismatched integration point you can use the following script:

<#
.DISCLAIMER The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
#>

########################################
# Function Test-RegistryValue
########################################

Function Test-RegistryValue($regkey, $name){

Get-ItemProperty $regkey $name -ErrorAction SilentlyContinue | 
Out-Null
$?

}

########################################
# Function Check-UserRegistryIntegrationPackages
########################################

Function Check-UserRegistryIntegrationPackages(){

$User = "CurrentUser"
$Integration = "SOFTWARE\Microsoft\AppV\Client\Integration\Packages"

# Opening Current User Registry
$registry = [microsoft.win32.registrykey]::OpenRemoteBaseKey("$User","localhost")

$i_CAVURIP = 1
$Results_CAVURIP = @()

$Packages = $registry.OpenSubKey($Integration)

$SubKeys = $Packages.GetSubKeyNames()
$SubkeysCount = $SubKeys.Count

    foreach($Subkey in $SubKeys){

        if((Test-RegistryValue "HKCU:\$Integration\$Subkey" "Integration Location") -eq $true){
        
        $SL = Get-ItemProperty "HKCU:\$Integration\$Subkey" -Name "Staged Location" | select -ExpandProperty "Staged Location"
        $IL = Get-ItemProperty "HKCU:\$Integration\$Subkey" -Name "Integration Location" | select -ExpandProperty "Integration Location"

        $IL_Expanded = [System.Environment]::ExpandEnvironmentVariables($IL)

        $Result_CAVURIP = New-Object System.Object
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name ID -Value $i_CAVURIP
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name RegKey -Value "HKCU:\$Integration\$Subkey"
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name StagedLocation -Value $SL
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name IntegrationLocation -Value $IL
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name IntegrationLocationExpanded -Value $IL_Expanded
        
            if((test-path "$IL_Expanded") -eq $true){

            $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name IntegrationLocationValid -Value $true

            }

            else {

            $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name IntegrationLocationValid -Value $false

            }

        $Results_CAVURIP += $Result_CAVURIP
        $i_CAVURIP++

        }

    }

    return $Results_CAVURIP

}

Check-UserRegistryIntegrationPackages | ? { $_.IntegrationLocationValid -eq $false }

The main question which I’m sure your thinking about is what can cause this? Generally, it’s caused by profile management solutions preserving the HKCU\Software\Microsoft\AppV registry key. A scenario where this can be caused is a package has been published to the user, you then find that it’s an application that all users require it so you decide to publish it globally (To the machine) and remove the user publishing. Because the profile management solution is preserving the entire HKCU\Software\Microsoft\AppV key the user integration is captured and not removed when the user logs back in even though it’s now published globally. The fix is to remove the entry in the HKCU\Software\Microsoft\AppV location then the application will launch successfully. SCRIPT DISCLAIMER The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. To conclude if you follow the process above you can find out which package is causing the application launch failure. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5 – All Packages COM / Objects Check

Dafalk — Tue, 05 Jul 2016 18:21:43 GMT

Hi all, Following on from my post about how COM mode functionality actually works, I was asked if there is a way to check all package COM and Objects settings on an App-V Client? https://blogs.technet.microsoft.com/virtualshell/2016/05/06/app-v-5-com-mode-functionality/ As I’m posting about it there is obviously a way to do this but you have to read multiple XML that are located locally for each package. There are two main XML files that contain the information about both COM and Object setting and they are included in the Package Catalog:

%PROGRAMDATA%\Microsoft\AppV\Client\Catalog\Packages

If the Package is published globally you will see two extra files “UserManifest.xml” and “UserDeploymentConfiguration.xml” which are created when a package is published globally. https://technet.microsoft.com/en-us/itpro/mdop/appv-v5/application-publishing-and-client-interaction?f=255&MSPPError=-2147217396#bkmk-files-data-storage If you open either XML file, the COM or Objects settings may not be set as there is an OOS (Out of Sequencer) experience where you haven’t checked any of the advanced options on the sequencer i.e. This will give the package the following settings:

COM Mode: Isolated
COM Mode OutOfProcess: true
COM Mode InProcess: false
Objects: true

If you set the values on the advanced tab of the sequencer, then obviously the default OOS settings are changed. The changed values are then updated in the Manifest.xml or UserManifest.xml (dependent upon whether the package is published globally or not). Within the “.appv” package itself the file that gets updated is the AppxManifest.xml. So that’s what it looks like from within the Manifest.xml but what the sequencer also does is it updates the _DeploymentConfig.xml file to have the same values: Now we know what sets the values and how those files are populated on the App-V client time to show all packages added to the machine with there COM / Objects settings as well as where it was pulled from i.e.

Default – Sequencer Default Values
DeploymentConfig – If the "_DeploymentConfig.xml" file was used in the deployment of the package
AppXManifest – Sequencer Advanced Tab Check

Theory done, what does a script look like and the output:

<# .DISCLAIMER The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. #>

########################################
# Function Check-AppVClientPackages
########################################

Function Check-AppVClientPackages(){

$PKGS = Get-AppvClientPackage -all | sort Name

$Results_PC = @()

    foreach($PKG in $PKGs){

    $Package_Name = $PKG.Name
    $Package_PID = $PKG.PackageId
    $Package_VID = $PKG.VersionId
    $Package_IPG = $PKG.IsPublishedGlobally
    $Package_V = $PKG.Version
    $Package_DCP = $PKG.GetDynamicDeploymentConfigurationPath()

    $Result_PC = New-Object System.Object
    $Result_PC | Add-Member -MemberType NoteProperty -Name Name -Value $Package_Name
    $Result_PC | Add-Member -MemberType NoteProperty -Name PackageId -Value $Package_PID
    $Result_PC | Add-Member -MemberType NoteProperty -Name VersionId -Value $Package_VID
    $Result_PC | Add-Member -MemberType NoteProperty -Name Version -Value $Package_V
    $Result_PC | Add-Member -MemberType NoteProperty -Name IsPublishedGlobally -Value $Package_IPG

    # DeploymentConfiguration.xml

    [xml]$ManConDP = gc $Package_DCP

    $DP_Objects = $ManConDP.DeploymentConfiguration.UserConfiguration.Subsystems.Objects.Enabled
    $DP_COM_Mode = $ManConDP.DeploymentConfiguration.UserConfiguration.Subsystems.COM.Mode
    $DP_COM_OutP = $ManConDP.DeploymentConfiguration.UserConfiguration.Subsystems.COM.IntegratedCOMAttributes.OutOfProcessEnabled
    $DP_COM_InP = $ManConDP.DeploymentConfiguration.UserConfiguration.Subsystems.COM.IntegratedCOMAttributes.InProcessEnabled

    # AppxManifest.xml

    $Package_Dir = [io.path]::GetDirectoryName($Package_DCP)

        if($Package_IPG -eq $true){
        
        $Package_Man = "$Package_Dir\UserManifest.xml"
        
        }

        elseif($Package_IPG -eq $false){

        $Package_Man = "$Package_Dir\Manifest.xml"
        
        }

    [xml]$ManConAppx = gc $Package_Man

    $Appx_Objects = ($ManConAppx.Package.Extensions.Extension | ? { $_.Category -eq "AppV.Objects" }).Objects
    $Appx_COM_Mode = $ManConAppx.Package.ExtensionsConfiguration.COM.Mode
    $Appx_COM_OutP = $ManConAppx.Package.ExtensionsConfiguration.COM.IntegratedCOMAttributes.OutOfProcessEnabled
    $Appx_COM_InP = $ManConAppx.Package.ExtensionsConfiguration.COM.IntegratedCOMAttributes.InProcessEnabled

    Clear-Variable Package_Man
    Clear-Variable ManConDP
    Clear-Variable ManConAppx

        # Object Configuration

        if($DP_Objects -eq $null -and $Appx_Objects -eq $null){

        $Package_Objects = "true"
        $Package_Objects_Set = "Default"

        }

        elseif($DP_Objects -ne $null){

        $Package_Objects = $DP_Objects
        $Package_Objects_Set = "DeploymentConfiguration"

        }

        elseif($Appx_Objects -ne $null){

        $Package_Objects = $Appx_Objects
        $Package_Objects_Set = "AppXManifest"

        }

        # COM Mode

        if($DP_COM_Mode -eq $null -and $Appx_COM_Mode -eq $null){

        $Package_COM_Mode = "Isolated"
        $Package_COM_Set = "Default"

        }

        elseif($DP_COM_Mode -ne $null){

        $Package_COM_Mode = $DP_COM_Mode
        $Package_COM_Set = "DeploymentConfiguration"

        }

        elseif($Appx_COM_Mode -ne $null){

        $Package_COM_Mode = $Appx_COM_Mode
        $Package_COM_Set = "AppXManifest"

        }

        # COM Mode OutProcess

        if($DP_COM_OutP -eq $null -and $Appx_COM_OutP -eq $null){

        $Package_COM_OutP = "true"

        }

        elseif($DP_COM_OutP -ne $null){

        $Package_COM_OutP = $DP_COM_OutP

        }

        elseif($Appx_COM_OutP -ne $null){

        $Package_COM_OutP = $Appx_COM_OutP

        }

        # COM Mode InProcess

        if($DP_COM_InP -eq $null -and $Appx_COM_InP -eq $null){

        $Package_COM_InP = "false"

        }

        elseif($DP_COM_InP -ne $null){

        $Package_COM_InP = $DP_COM_InP

        }

        elseif($Appx_COM_InP -ne $null){

        $Package_COM_InP = $Appx_COM_InP

        }

    $Result_PC | Add-Member -MemberType NoteProperty -Name Objects -Value $Package_Objects
    $Result_PC | Add-Member -MemberType NoteProperty -Name ObjectsSetBy -Value $Package_Objects_Set
    $Result_PC | Add-Member -MemberType NoteProperty -Name COMMode -Value $Package_COM_Mode
    $Result_PC | Add-Member -MemberType NoteProperty -Name COMModeSetBy -Value $Package_COM_Set
    $Result_PC | Add-Member -MemberType NoteProperty -Name COMOutP -Value $Package_COM_OutP
    $Result_PC | Add-Member -MemberType NoteProperty -Name COMInP -Value $Package_COM_InP

    if($Package_Objects_Set -ne $null){ Clear-Variable Package_Objects_Set }
    if($Package_COM_Set -ne $null){ Clear-Variable Package_COM_Set }

    $Results_PC += $Result_PC

    }

return $Results_PC

}

Check-AppVClientPackages

The result will look something like this. SCRIPT DISCLAIMER The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. Hope this helps in understanding how your packages were sequenced. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5.0 – ETW Tracing Automation [Update]

Dafalk — Mon, 16 May 2016 20:09:46 GMT

Hi all, I've had some feedback on a post that I did on VirtualWorld stating it took along time to convert the ETL output into a readable format so its time to share the updated script to address this. https://blogs.technet.microsoft.com/virtualworld/2014/04/12/app-v-5-0-etw-tracing-automation/ When you collect the trace you will see a lot of "SharedPerformance" entries as shown below. The "SharedPerformance" entries provide information about how the App-V 5 Client is performing when completing tasks, e.g "VReg.CloseKey" of the App-V 5 environment. To remove these entries from your debug trace you can run the following script which checks "if $entry is not Microsoft-AppV-SharedPerformance", then add it to the collector.

$trace = "APPV5Debug"
$Date = get-date -f "ddMMhhmm"
$ETL_trace_output = "c:\temp\appv5Debug.etl"
$EVTX_trace_output = "c:\temp\appv5Debug$Date.evtx"
$TXT_trace_output = "c:\temp\appv5Debug$Date.txt"

$Random = Get-Random
$ProviderFile = "$env:temp\AppVClientProviders$Random.txt"

$Providers = Get-WinEvent -ListProvider Microsoft-AppV*

$AppVProviders = $Providers.Name | sort

foreach($entry in $AppVProviders){

    if($entry -ne "Microsoft-AppV-SharedPerformance"){
    ac $ProviderFile $entry
    }

}

write-host

$query_logman = logman query APPV5DEBUG

if($LASTEXITCODE -eq "-2144337918"){
write-host "Data Collector Set was not found"
write-host
write-host "Creating Logman Trace..."
logman.exe create trace $trace -o "$ETL_trace_output" -f bincirc -max 512 -pf "$ProviderFile" -ct perf -ow --v
write-host
}

elseif($LASTEXITCODE -eq "0"){
write-host "Data Collector Set already exists..."
write-host "Deleting to ensure all the App-V Collectors are available..."
write-host
logman.exe delete $trace
write-host "Creating Logman Trace..."
logman.exe create trace $trace -o "$ETL_trace_output" -f bincirc -max 512 -pf "$ProviderFile" -ct perf -ow --v
write-host
}

$Start_Trace = read-host -prompt "Do you want start the trace now? (Y/N)"
    
if ($Start_Trace -eq "Y" -or $Start_Trace -eq "y"){
write-host "Starting Logman Trace $Trace" -f yellow
logman.exe start $trace
write-host
}
elseif ($Start_Trace -eq "N" -or $Start_Trace -eq "n"){
write-host "You will need to start the trace manually from perfmon.exe..." -f yellow
}

$Stop_Trace = read-host -prompt "Do you want stop the trace now? (Y/N)"
    
if ($Stop_Trace -eq "Y" -or $Stop -eq "y"){
write-host "Stopping Logman Trace $Trace" -f yellow
logman.exe stop $trace
write-host
write-host "Converting Trace to EVTX format..."
tracerpt.exe -l $ETL_trace_output -lr -of EVTX -o $EVTX_trace_output
write-host
write-host "Converting Trace to TXT format..."
Netsh trace convert $ETL_trace_output $TXT_Trace_output DUMP=TXT report=no
write-host "TXT file written to $TXT_Trace_output..."
write-host
write-host "Opening EVTX trace - $EVTX_Trace_output..."
Invoke-Item $EVTX_Trace_output
}
elseif ($Stop_Trace -eq "N" -or $Stop_Trace -eq "n"){
write-host "You will need to stop the trace manually from perfmon.exe..." -f yellow
}

SCRIPT DISCLAIMER The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Now the ETW tracing will be a lot quicker in the conversion and I've also added the export to TXT file for those who prefer TXT file manipulation. You could always use trace32.exe or cmtrace.exe to view the data. Hope this update helps in your troubleshooting. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5 – COM Mode Functionality

Dafalk — Fri, 06 May 2016 18:51:21 GMT

Hi all, Following on from my colleagues post about COM Mode it would be good to understand how COM Mode actually works when you deploy an App-V 5 package with COM Mode set to “Integrated” or “Isolated”. https://blogs.technet.microsoft.com/gladiatormsft/2015/01/13/app-v-5-further-into-com-and-dynamic-virtualization/ I’m going to be using an application called Microsoft MapPoint 2004 to show how this works on the client. The first question is what is COM Mode and its functionality? COM is a registry based subsystem which provides an interface for applications to interact with an object whether it be an EXE or DLL. “Each COM class is identified by a CLSID, a unique 128-bit GUID, which the server must register. COM uses this CLSID, at the request of a client, to associate specific data with the DLL or EXE containing the code that implements the class, thus creating an instance of the object.” https://msdn.microsoft.com/en-us/library/windows/desktop/ms678406(v=vs.85).aspx All COM classes are stored in the registry “HKEY_LOCAL_MACHINE\SOFTWARE\Classes”. If you view the Virtual Registry for the package you will see that MapPoint has a COM entry and a CLSID specified which means applications can interact with it via a COM Call. If you then browse to the CLSID specified above, you will see the “LocalServer32” is set to point to MapPoint.exe. So that’s a COM object captured during the sequencing process but what happens when you deploy the package to your machine? The first thing to remember is that App-V 5 is an isolation technology which means by default, when you sequence an application COM Mode functionality will be set to “Isolated” which means the CLSID won’t be written to the local operating system. You can also see this setting in your “_DeploymentConfig.xml” file. Once you have added your package and deployed it to the machine you will see the following entry in the “native” registry. Note the CLSID reference isn’t set / available.

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MapPoint.Application

If your testing COM Mode functionality for your application there is a PowerShell command that you can use to load / test the COM Object:

New-Object -ComObject MapPoint.Application

If you run the command in a PowerShell window, as the package is set as “Isolated” then the COM call fails. Let’s see what happens when you change the COM Mode functionality in the “_DeploymentConfig.xml” to “Integrated” and be aware I’ve left “OutOfProcessEnabled” and “InProcessEnabled” to false on purpose. You will see exactly the same as the package being “Isolated” no CLSID for the package because we don’t integrate COM into the OS until “OutOfProcessEnabled” is set to true. https://blogs.technet.microsoft.com/appv/2013/01/03/microsoft-application-virtualization-5-0-integration/ Now I’ve changed the configuration file for OOP to "true", so what happens on the Operating System? The CLSID is now set in the “native” registry which means you can manipulate it via a COM Object call. If you run the same command as above the COM object call from PowerShell now works. If you look in Task Manager you will see the MapPoint.exe process running but no GUI available to the user. So MapPoint.exe is loaded, what can you do with the object? You can see below the object can be manipulated and MapPoint methods can be used to “OpenMap” etc. Hope this shows how COM integrates from an App-V 5 Package sequence to a client deployment. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

App-V 5 - Service failed to complete requested operation - 06-00000011

Dafalk — Thu, 28 Apr 2016 16:59:33 GMT

Hi all, I've worked with a few customers and they were receiving the following error code when running the "Get-AppvClientPackage" PowerShell cmdlet.

Get-AppvClientPackage : Application Virtualization Service failed to complete requested operation.
Operation attempted: Get Packages.
AppV Error Code: 0600000011.
Error module: Catalog. Internal error detail: 86B09F0600000011.
Please consult AppV Client Event Log for more details.

If you translate the error code it translates to:

Code: 86B09F06-00000011
Result: Error
Type: App-V
Module: Catalog (06)
HRESULT: 0x00000011
Message: ERROR_NOT_SAME_DEVICE

Knowing how App-V 5 works ( https://blogs.technet.microsoft.com/virtualshell/2016/04/15/app-v-5-wmi-usage/ ) we checked WMI functionality on the client to see if that was ok, but running a wbemtest and testing the "AppvClientPackage" instance caused the following error: The 0x80004005 error translates to a WMI "Generic Failure" so that doesn't really help but there is obviously a problem. For some general WMI troubleshooting check out the following post: https://blogs.technet.microsoft.com/configmgrteam/2009/05/08/wmi-troubleshooting-tips/ As its an App-V 5 client error its time to have a look at some of the debug logs, so we used a script that I wrote and posted here: https://blogs.technet.com/b/virtualworld/archive/2014/04/12/app-v-5-0-etw-tracing-automation.aspx First look in the debug event log output was the following entry which is trying to give away the issue.

ERROR: Failed to load a manifest document from the Catalog for package 0db55a56-24ea-4918-9f7a-d7f3e75f6440, version 037ecc82-414c-46f9-b5bc-1022b5dfa79a because the manifest actually belongs to package 0db55a56-24ea-4918-9f7a-d7f3e75f6440, version 3f84e348-7378-44ca-9630-458fbc936c4e.

The error message is now telling us what to do "VerifyManifestDocument" but where should I look for this? Well the error code translated module is the Catalog and its failing on a "Get-AppvClientPackage" so lets check the machine catalog for all packages.

C:\ProgramData\Microsoft\AppV\Client\Catalog\Packages

What you will see in the folder for the PackageID "0db55a56-24ea-4918-9f7a-d7f3e75f6440" is two folders which means that there have been two versions of the package added to the machine. If you open up the folder with the VersionID "037ecc82-414c-46f9-b5bc-1022b5dfa79a" that's causing the issue from the event log entry and there should be two files:

DeploymentConfiguration.xml
Manifest.xml

If you open up the Manifest.xml you will actually see the problem, the VersionID specified in the Manifest.xml "3f84e348-7378-44ca-9630-458fbc936c4e" is for the other version of the package when it should be "037ecc82-414c-46f9-b5bc-1022b5dfa79a". So firstly how do you fix it? And secondly what causes it to occur which is the most important piece. To fix this you have to remove the package from the machine, but as you can't use "Get-AppvClientPackage" you have to use the "Remove-AppvClientPackage" directly as that still works in this situation.

Remove-AppvClientPackage [-PackageId] GUID [-VersionId] GUID

You can see below, the initial "Get-AppvClientPackage" fails, then I've removed the package using the PackageID and VersionID, which allows the "Get-AppvClientPackage" cmdlet and WMI query to function correctly. As per my other posts there has to be some scripting automation to help you, so here is it a PowerShell script to check all package catalog entries. What the script is doing is:

Looping through all the Package Catalog entries in the Registry
For each package it opens up the Manifest.xml for PackageID and VersionID and checks if they are the same
If the Package Catalog VersionID matches the VersionID inside the manifest then its a "Pass", if not it sets the output as a "Fail".

########################################
# Function Check-AppVCatalogManifest
########################################

function Check-AppVCatalogManifest(){

$Catalog = "C:\Programdata\Microsoft\AppV\Client\Catalog\Packages"

$i_CAVCM = 1
$Results_CAVCM = @()

$AppVCatalogManifest = gci $Catalog

    foreach($CM in $AppVCatalogManifest){

        $AppVCatalogManifestID_Folder = $CM.Name

        $AppVCatalogManifestID = $AppVCatalogManifestID_Folder.Trim("{","}")

        $Version = gci $Catalog\$AppVCatalogManifestID_Folder

            Foreach($CM_v in $Version){

            $Result_CAVCM = New-Object System.Object
            $Result_CAVCM | Add-Member -MemberType NoteProperty -Name ID -Value $i_CAVCM

            $VersionId_Folder = $CM_v.Name

            $VersionID = $VersionId_Folder.Trim("{","}")

            $Manifest = "$Catalog\$AppVCatalogManifestID_Folder\$VersionId_Folder\Manifest.xml"

            [xml]$ManCon = gc $Manifest

            $DisplayName = $ManCon.Package.Properties.DisplayName
            $Man_PackageID = ($ManCon.Package.Identity.PackageId).toUpper()
            $Man_VersionID = ($ManCon.Package.Identity.VersionId).toUpper()
            
                if($Man_VersionID -eq $VersionID){

                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name DisplayName -Value $DisplayName
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name PackageID -Value $AppVCatalogManifestID
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name VersionID -Value $VersionId
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name Manifest -Value $Manifest
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name Status -Value "Pass"

                }

                else {

                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name DisplayName -Value $DisplayName
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name PackageID -Value $AppVCatalogManifestID
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name VersionID -Value $VersionId
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name Manifest -Value $Manifest
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name Status -Value "Fail"

                }

            $Results_CAVCM += $Result_CAVCM
            $i_CAVCM++

            }

    }

    return $Results_CAVCM

}

Check-AppVCatalogManifest

Once this is ran it will return a status of "Pass" or "Fail", if a package fails that package would need to be removed following the steps above. If you want to just check for failures then you can add the following to the script:

Check-AppVCatalogManifest | Where-Object { $_.Status -eq "Fail" }

PackageName.appv
PackageName_2.appv
PackageName_3.appv

If its unchecked then every time you save it the package name with stay the same i.e. PackageName.appv. So how does this relate to the error? This comes down to how you manage your packages on your content share! You maybe thinking why does that matter? Here's the scenario:

On the sequencer you create a package called PackageName.appv
You then copy the package to your content share \\appvserver\contentshare\PackageName folder
You then add that package to the App-V 5 Management Server and stream it to your App-V 5 client via the "Sync-AppvPublishingServer" cmdlet
You then find there is something wrong with the package so you remove it from the Management Server and re-sync the App-V 5 Client which unpublishes the package but it doesn't remove the package from the machine (This is the important piece)
You then copy the package to the sequencer and upgrade or edit it, once saved you copy it to the SAME folder \\appvserver\contentshare\PackageName 0verwritting the previous files
Once copied you add the new package which has the same PackageID, same .appv filename, but a new VersionID and Version i.e. 0.0.0.1 to the Management Server
You then stream that package to your client and everything looks good, the upgraded package works, but remember there are two packages streamed from the same folder with the same filename for the .appv file i.e. PackageName.appv
The machine is either rebooted or the App-V Client service is restarted
Once restarted if you run "Get-AppvClientPackage" from PowerShell the error occurs and you have to follow the steps above to address it

The only way I can show this as you can't run a get "Get-AppvClientPackage" is to check the path set in the registry and you will see both Versions of the Package are using the same PackageURI.

\\appvserver\contentstore\Visual Studio Code 1.0.0 x64\Visual Studio Code 1.0.0 x64.appv

To conclude if you follow the process above to manage your packages you may get the above issue on the App-V 5 client, make sure your testing is done in a test environment not in production. David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell