In a hurry and just want the script, click here.
Synopsis
Work in progress. Not much information about App-V 0x87d01290 error, so just writing up a concise summary of the issue and how it was resolved. Here for prosperity to help others.

Two situations which can lead to a 0x87d01290 error, but the same fix still applies.
FYI: 0x87d01290 is a generic detection failure.
  • Corrupted Manifest.xml, as outlined in detail below.
  • Missing content in the App-V Package Store, see appendix note 1.



Issue
When a computer is built from Task Sequence and completes OK. App-V packages are delivered after TS completion, sometimes the deployment of App-V packages targeted to the user or computer stop/jam, stopping all other App-V packages being delivered to the user or computer.

Some App-V packages are delivered to the client computer but none of the App-V packages are shown in Software Centre. Checking with the command "Get-AppvClientPackage" often shows the error below. The observed packages delivered are computer targeted packages, we had no user target packages assigned to the user account, thus unable to confirm user targeted 
0x87d01290 issues.

Get-AppvClientPackage : Application Virtualization Service failed to
complete requested operation. Operation attempted: Get Packages. Windows Error:
0x800703E7 - Error performing inpage operation Error module: Manifest Library.
Internal error detail: 43E01234800703E7. Please consult AppV Client Event Log
for more details.

Checking in the registry in path "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages", it lists the successfully published applications by App-V GUID. The successfully published appear to function. The successfully published applications appear to function with exception to the applications with a corrupted Manifest.xml.

Once delivery of App-V packages fails due to the corrupted Manifest.xml, it will cause other 0x87D01290 errors to occur. This is due to the App-V client hanging and not responding to the ConfigMgr agent, when it querying for published App-V applications. At this point, new App-V applications will not be deployed/published to the computer, as the agent is unable to determine what is and isn't published.


This error 0x87d01290, effects App-V User and Machine targeted applications. 


This only happens for App-V packages, physical packages deployed OK and are shown in Software Centre

Back-end Client Management: SCCM 2016.
Clients: Windows 10 1803 64-bit Education with many users using each computer.


Please note that the 0x87D01290 error is a symptom of a issue, but not the root cause of the issue itself.  



Discovery
The error event flow is the following
  1. The client computer via ConfigMgr logs will show error 0x87D01290.
  2. SCCM Monitoring for application deployment status will show client computers with an Enforcement State of "An error occurred when querying the App-V WMI provider".

How do you know which apps have this problem?
*Via Reporting Server
You can check SCCM Reporting, goto your reporting URL and dig into the bread crumbs below.
  1. Home > YourSCCMReportingServer_URL > Software Distribution - Application Monitoring > Application Compliance.
  2. Select your application in the drop down menu and then collection (All Windows 10 clients for example). Hit "View Report".
  3. Once the report loads, click on the Application link, this will allow you to dig into the results for more details. Once loaded again, click on the number of errors link, this will show you a breakdown of the errors. You should see an Enforcement State error "An error occurred when querying the App-V WMI provider", this is the 0x87d01290.

As mentioned above, you can You can also see these 0x87d01290 errors in the client machines ConfigMgr agent logs. With CMTrace.exe, the two defining markers in the log are the following.

Log: C:\Windows\CCM\Logs\AppDiscovery.log

Component: AppVHandler
Note 0x87d01290 error.

AppVPackageQueryClient5X::GetPackageDataByPackageGUID() failed for
virtual application [XXXXXXXXXXXXXX]. (0x87d01290)



Log: C:\Windows\CCM\Logs\AppIntentEval.log

Component: AppIntentEval
Note Current State = Error due to App-V being unable to do the evaluation.

ScopeId_XXXXXXXXXXXXXX/RequiredApplication_XXXXXXXXXXXXXX/8 :- Current
State = Error
, Applicability = Unknown, ResolvedState = None, ConfigureState = NotNeeded, Title = ApplicationIntentPolicy

*Via SCCM Query

Found better solution to discover all the 0x87d01290 errors. In SCCM, create a query with the WQL below to list all devices with this error, and the applications that is currently blocked from delivery. This is a dynamic query, so computers will fall out of the collection as they are fixed. Please note the query will list User and Computers with 0x87d01290 errors.


All applications that are not being delivered due to error.

select 
	SMS_R_System.Name,
	SMS_R_System.ResourceId,
	SMS_R_System.OperatingSystemNameandVersion,
	SMS_AppDeploymentAssetDetails.AppName,
	SMS_AppDeploymentAssetDetails.StatusType,
	SMS_AppDeploymentAssetDetails.EnforcementState,
	SMS_AppDeploymentAssetDetails.CollectionName,
	SMS_AppDeploymentAssetDetails.Technology 
from 
	SMS_R_System inner join SMS_AppDeploymentAssetDetails 
on 
	SMS_AppDeploymentAssetDetails.MachineID = SMS_R_System.ResourceId 
where 
	SMS_AppDeploymentAssetDetails.StatusType = "5" And 
	SMS_AppDeploymentAssetDetails.Technology = "AppV5X" And 
	SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 10.0" And 
	SMS_AppDeploymentAssetDetails.EnforcementState = "5001"

Distinct devices with error.
Select Distinct 
	SMS_R_System.Name
from 
	SMS_R_System inner join SMS_AppDeploymentAssetDetails on SMS_AppDeploymentAssetDetails.MachineID = SMS_R_System.ResourceId 
where 
	SMS_AppDeploymentAssetDetails.StatusType = "5" And 
	SMS_AppDeploymentAssetDetails.Technology = "AppV5X" And 
	SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 10.0" And 
	SMS_AppDeploymentAssetDetails.EnforcementState = "5001"

*Via checking on the file system
Look in %ProgramData%\Microsoft\AppV\Client\Catalog\Packages and do a recursive search for Manifest.xml files. Check each file and make sure you can open the XML. You will find that one of them may not open, due to corruption? Keep in mind that this is a HardLink to location (I think/I'm pretty sure but I didn't check to be absolute) to %ProgramData%\App-V. A symptom of this manifest error is running the Get-AppvClientPackage cmdlet, you will get error below.
Get-AppvClientPackage : Application Virtualization Service failed to
complete requested operation. Operation attempted: Get Packages. Windows Error:
0x80070005 - Access is denied Error module: Manifest Library. Internal error
detail: 43E0123480070005.

On 3 instances of checking 17 machines, we have found that the Manifest.xml has been OK, but the App-V error still appears when running the Get-AppvClientPackage cmdlet. We think this could be due to malformed XML’s in the user targeted space? This is speculation, yet to look into and confirm. Looked into the user space with malformed XML's and found no issues, used a PowerShell script to recursively check all the App-V XML's  in the user space (AppxManifest.xml, FilesystemMetadata.xml, PackageHistory.xml, StreamMap.xm, DynamicConfiguration.xml and UserManifest.xml) but found no issues. 

So far we have only found this issue in Manifest.xml’s.



Research
Google says very few people have this issue but there is no consensus on how to fix it. Results on Google only show 1 meaningful page of information with the rest being images. Basically we had to fix this the old fashion way!


Root Cause
Don't know. 

We know that the Manifest.xml files cause the problem, but we don't know how the files themselves get corrupted. I suspect that between delivery of the content and publishing causes the corruption - quite an area to cover. 

For reference, this is what I think happens after the file is corrupted
  1. Not sure when corruption occurs, on delivery of files?
  2. ConfigMgr AppDiscovery is run, an application is missing, triggers action to publish missing application.
  3. App-V attempts to publish the application, it breaks at this point(?). 
  4. ConfigMgr agent uses some WMI calls (App-V cmdlets) to query what applications are on the computer, WMI is now broken due to the attempt to publish previously.
  5. Broken WMI (App-V cmdlets) cause ConfigMgr to report an evaluation error, because it can not query correctly/anymore.
    Which each ConfigMgr query for application thereafter, it will report a 0x87d01290.

 I need to state at this point the App-V packages are fine themselves, ie they work OK on other computers.


Fix or Resolution (currently in progress, last updated 2019/02/14)
Final Resolution Applied. In short...
Plan A
  1. Find the corrupt Manifest.xml files and get the App-V package GUID.
  2. Delete the registry keys from the two paths below with the Package GUID.
    HKLM:\SOFTWARE\Microsoft\AppV\Client\Packages\<Package GUID>
    HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\VirtualAppPackages\AppV5XPackages\<Package GUID>
  3. Restart the App-V Client service
  4. Run a ConfigMgr Application Deployment Evaluation Cycle to force the check and deployment applications or do nothing and let nature take its course.
Plan B (Big Fix Approach)
The computer is still having 0x87d01290 issues even after the above fix is applied AND/OR the App-V service is in a stopped state and will not start, trying to start it from GUI will prompt error code 575.
  1. Check the App-V Client service status.
  2. If the service is not running, then clean out the %ProgramData%\Microsoft\AppV\Client\Catalog\Package\<GUID> of all folder and file stubs (symbolic links).
  3. Start the App-V Client service.

Automation via SCCM
Or you can use this script which I produced, it does all of the above with some basic error checking. In almost all cases the computer will need to reboot as the cmdlet to discover any App-V applications running is broken. 

The script can be found on my GitHub Gist on the URL below.
https://gist.github.com/rileyz/93cd70d245ab99fd353a1e39f82f6708

Detection method via Registry key.
This can be set in the house keeping part of the script.

Logs, if you want to gather the logs to a local location for further checking, use this PowerShell script below. Keep in mind that I used the RDP port to check the computer is alive, adjust for your requirements. Our site has some restrictions, hence the open port check.

SCCM Notes
  • Software Type: Applications
    Detection Method: Registry 
    *Do no use type Packages, as this is run in 32-Bit mode, thus script will not work properly in 64-bit computers.
  • Collection: Use the dynamic collection query above in section "Distinct devices with error".

Observations
  • We have found some computers have no XML errors and the cmdlet works fine, but 0x87d01290 is still present. Still looking into this scenario.
  • Related to the above. We have found that the error can still be present in the SCCM query due to App-V packages that are user published causing the 0x87d01290 error. Still looking on how we can resolve, but could be difficult because its user based publishing.
  • Also related to the above. We have found computers with the 0x87d01290 error but the XMLs were OK (not sure about user published packages). When running the Get-AppVpackage cmdlet, it did not return anything (hangs). App-V packages are not shown in Software Center. This was found to be an issue with the App-V client service, it was failing to start with error 575. After applying the Big Fix Approach, the service started OK and App-V packages were being processed OK.
  • It will pay to review the data from the query "All applications that are not being delivered due to error", I found that most computers were resolved with the script. I state resolved from a App-V Device based Publishing perspective, but App-V packages that were User Published still had an error with 0x87d01290.
  • I have seen AppEnforce error 0x87d0128f  cause 0x87d01290 errors. This is due to missing content in the Package Store, see appendix note 1, for more details. 
Script Bugs
Conclusion
Seems to be working, all machine based App-V packages now appear to deploy correctly. The User targeted App-V packages seems to still appear with the error, we are not sure if this is due to a fubar'd machine, or there is a still a problem. Havent had the time to look at User targeted App-V packages with the 0x87d01290 error. We thought this might be out of date error state in SCCM SQL db, so we tried removing the objects from SCCM and letting it call home to re-add itself - the error still showed... so still looking it.


Google says try the following which didn't work... (saving you testing grief hopefully)
1) Reinitialize the wmi namespace the command below = DID NOT RESOLVE
https://social.technet.microsoft.com/Forums/en-US/5e8d1f7c-abd0-4d05-a956-bbe886d1447b/appv-51-and-sccm-2012-error?forum=mdopappv
mofcomp "C:\Windows\WinSxS\wow64_microsoft-windows-a..appvprogrammability_31bf3856ad364e35_10.0.17134.1_none_dbe491204bf36f48\Microsoft.AppV.AppVClientWmi.mof"

2) Nuke this registry key and reboot or preferred, let ConfigMgr do a normal evaluation cycle = DO NOT WORK
https://social.technet.microsoft.com/Forums/en-US/5e8d1f7c-abd0-4d05-a956-bbe886d1447b/appv-51-and-sccm-2012-error?forum=mdopappv
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages

Update 3 09/29 = I lied in update 2, seems only work on some machines and is not reliable. 
Update 2 09/28 = Confirmed fix/hack works (hurrah).

Update 1 09/28 = Testing in progress, seems to work.


Credits

Mal Lagden for provding the other half of the solution from the ConfigMgr driving App-V persepctive.

Colin Millins for discovering the malformed Manifests.xml's, which breaks the processing of App-V packages.



Edit Log

  • 2019/02/16: Updated sections with new details. Added details in re 0x87d0128f error.
  • 2019/02/14: Issue with SCCM Detection method, removed PowerShell detection method, replaced with registry.
  • 2018/11/05: Updated conclusion. 
  • 2018/10/20: Added progress updates and SCCM detection method.
  • 2018/10/15: Squashed a bug in the script, see script version history for more details.
  • 2018/10/02: Added findings in regards to user space, and script to pull logs from clients.
  • 2018/10/01: Added WQL query, added CCM log location details.
  • 2018/09/28: Expanded fix with help of Mal. AppVirtGuru is not indexed by Google, moved to ITNinja for better visibility, why do all this if it’s not going help anyone!?
  • 2018/09/24: Initial post and expansion of details.



Appendix
Note 1.  I have observed a different error in the AppEnforce logs, a 0x87d0128f error, which in turn produces 0x87d01290.  I found the error was related to content missing in the Package Store (%ProgramData%\App-V\AppVGUID\), not sure how this happened as this is a protected area only accessible by the Trusted Installer/SYSTEM.  Good news, the fix is still the same.  I have updated the script to detect for missing Package Store content, and apply the fix as necessary. Just to note, I think 0x87d0128f is a generic publish failure.