WinSCP and Firefox Fail with Error 0x80070002

wokkeltje · January 04, 2019, 01:09:33 AM

We receive an error when installing the TeamViewer 13 update. Any idea what can be the reason? Other updates are working OK.

<![LOG[Successfully completed synchronous searching of updates.]LOG]!><time="09:02:00.837-60" date="01-04-2019" component="WUAHandler" context="" type="1" thread="1376" file="cwuahandler.cpp:980">
<![LOG[1. Update: 0d6bb41c-cfd5-474f-99a3-9b0c48e581c5, 2 BundledUpdates: 0]LOG]!><time="09:02:01.054-60" date="01-04-2019" component="WUAHandler" context="" type="1" thread="1376" file="cwuahandler.cpp:1698">
<![LOG[1. Update (Missing): TeamViewer 13.2.26558 (0d6bb41c-cfd5-474f-99a3-9b0c48e581c5, 2)]LOG]!><time="09:02:01.054-60" date="01-04-2019" component="WUAHandler" context="" type="1" thread="1376" file="cwuahandler.cpp:1820">
<![LOG[Async installation of updates started.]LOG]!><time="09:02:01.639-60" date="01-04-2019" component="WUAHandler" context="" type="1" thread="1376" file="cwuahandler.cpp:2273">
<![LOG[Update 1 (0d6bb41c-cfd5-474f-99a3-9b0c48e581c5) finished installing (0x80070002), Reboot Required? No]LOG]!><time="09:02:03.073-60" date="01-04-2019" component="WUAHandler" context="" type="1" thread="10632" file="cwuahandler.cpp:2451">
<![LOG[Async install completed.]LOG]!><time="09:02:03.073-60" date="01-04-2019" component="WUAHandler" context="" type="1" thread="10632" file="cwuahandler.cpp:2478">
<![LOG[Installation job encountered some failures. Error = 0x80240022. Commit Result = 0x00000001.]LOG]!><time="09:02:03.074-60" date="01-04-2019" component="WUAHandler" context="" type="2" thread="1376" file="cwuahandler.cpp:4351">
<![LOG[Installation of updates completed.]LOG]!><time="09:02:03.074-60" date="01-04-2019" component="WUAHandler" context="" type="1" thread="1376" file="cwuahandler.cpp:4742">

Justin Chalfant (Patch My PC) · January 04, 2019, 09:15:46 AM

That's an odd exit code returned to WUAUHandler could you email the windowsupdate.log to [email protected]<ourdomainname>, and we can troubleshoot there?

TedLarsen · January 29, 2019, 01:53:10 PM

Merged Topic

Hello,

We are evaluating Patch My PC integration with SCCM in our lab environment with the free catalog. We are currently testing Updating Chrome, 7-Zip and Firefox. We have all the prerequisites installed in our lab and have successfully setup and deployed updates for Chrome and 7-Zip to 2 different Windows 10 VM's. We however are having issues with our FireFox updating on both VM's.

Content is successfully downloading to the clients and Windows Update is attempting to run the update, but is failing with "Command Line Install 0x80070002" Here is the WindowsUpdate.log data:

2019/01/29 14:10:08.2712155 4688 7928 Agent * START * Installing updates CallerId = CcmExec
2019/01/29 14:10:08.2712190 4688 7928 Agent Updates to install = 1
2019/01/29 14:10:08.2716668 4688 7928 Agent Title = Mozilla Firefox 64.0.2 (x86)
2019/01/29 14:10:08.2716725 4688 7928 Agent UpdateId = 6DD37419-327D-41B9-A4FF-FDC8523BBA07.2
2019/01/29 14:10:08.3221064 4688 5244 Agent WU client calls back to install call {2386A864-C561-4744-82E7-8DD8B73262E8} with code Call progress and error 0
2019/01/29 14:10:08.4216065 4688 7928 DownloadManager Preparing update for install, updateId = 6DD37419-327D-41B9-A4FF-FDC8523BBA07.2.
2019/01/29 14:10:10.5795395 4688 7928 DownloadManager ExtractUpdateFiles
2019/01/29 14:10:10.5800408 60 5924 Handler * START * Command Line Install Updates to install = 1
2019/01/29 14:10:10.5974280 60 5924 Handler * END * Command Line Install 0x80070002
2019/01/29 14:10:10.6069408 4688 7928 Agent LogHistory called. idUpdate={6DD37419-327D-41B9-A4FF-FDC8523BBA07}.2, resultMapped=80070002, resultUnMapped=80070002
2019/01/29 14:10:10.6166619 4688 7928 Agent Install updates CallerId = CcmExec
2019/01/29 14:10:10.6180361 4688 7928 IdleTimer WU operation (CInstallCall::Init ID 8, operation # 92) stopped; does not use network; is not at background priority
2019/01/29 14:10:10.6341530 856 8016 ComApi Install ClientId = CcmExec
2019/01/29 14:10:10.6341601 856 8016 ComApi Install call complete (succeeded = 0, succeeded with errors = 0, failed = 1, cancelled = 0, unaccounted = 0
2019/01/29 14:10:10.6342353 856 8016 ComApi Reboot required = False
2019/01/29 14:10:10.6342387 856 8016 ComApi Exit code = 0x00000000; Call error code = 0x80240022
2019/01/29 14:10:10.6342408 856 8016 ComApi * END * Install ClientId = CcmExec
2019/01/29 14:10:10.6346787 856 5488 ComApi Install call complete (succeeded = 0, succeeded with errors = 0, failed = 1, cancelled = 0, unaccounted = 0
2019/01/29 14:10:10.6346884 856 5488 ComApi * END * All federated installs have completed. ClientId = CcmExec (cV = KREoBxi3iE2pAwGh.3.0)
2019/01/29 14:10:10.6348720 4688 5244 Agent WU client calls back to install call {2386A864-C561-4744-82E7-8DD8B73262E8} with code Call complete and error 0
2019/01/29 14:10:19.2576868 7768 5176 AppAU * START *
2019/01/29 14:10:19.2577638 7768 5176 AppAU Flight settings ring provisioned default, range-checked minimum search interval: 20 hours
2019/01/29 14:10:19.2759321 7768 5176 AppAU * START * Finding app updates
2019/01/29 14:10:19.2760201 7768 5176 AppAU Desktop OOBE is complete.
2019/01/29 14:10:19.2760566 7768 5176 AppAU Watching user key Software\Microsoft\Windows\CurrentVersion\AppReadiness\S-1-5-21-3997270446-2121233660-126109670-1119 for app readiness state
2019/01/29 14:10:19.2760606 7768 5176 AppAU Waiting for UserState to match 3
2019/01/29 14:10:19.2761614 7768 5176 AppAU UserState value is now 3. Exiting wait.
2019/01/29 14:10:19.2762153 7768 5176 AppAU User apps are ready for update, waiting 15 minutes
2019/01/29 14:11:50.4776790 7964 932 ComApi * START * Federated Search ClientId = Windows Defender Antivirus (77BDAF73-B396-481F-9042-AD358843EC24) (cV: gVCpKlaG5kKT8TQ9.1.0)
2019/01/29 14:11:50.4795539 4688 5548 IdleTimer WU operation (SR.Windows Defender Antivirus (77BDAF73-B396-481F-9042-AD358843EC24) ID 9) started; operation # 113; does use network; is not at background priority
2019/01/29 14:11:50.4796386 4688 6032 Agent Processing auto/pending service registrations and recovery.
2019/01/29 14:11:50.5010584 4688 6032 SLS *FAILED* [80248007] Method failed [SlsDatastoreLookup:797]
2019/01/29 14:11:50.5010662 4688 6032 SLS Retrieving SLS response from server...

It does this on both VM's, and I've tried uninstalling AV, rebooting, etc. The other updates work fine on these same systems, so I think it's only an issue with this FireFox update.

Justin Chalfant (Patch My PC) · January 29, 2019, 03:04:11 PM

Are you using the in-console SCCM publishing? There was a 1806 bug that should fix this. Please apply the latest hotfix. We actually just released a new Firefox a few minutes ago so after doing the hotfix can you try to publish the catalog and use the new Firefox update.

TedLarsen · January 30, 2019, 11:55:47 AM

Yes, we initially setup our test environment using the in-console publishing, but after the fact, we installed the Patch my PC publishing service to test that functionality. I'm hoping that's not contributing to this issue, but given the other application updates are working fine, I doubt that's the case.

If this is hotfix KB4462978 you are referring to, we already have that hotfix installed. Is this a different one you are referring to?

Also, I republished the catalog about 5 minutes ago and no updates were pulled down. Most current release for Firefox still shows 64.0.2 as the latest release. This is the version we are having issues with.

Justin Chalfant (Patch My PC) · January 30, 2019, 03:02:04 PM

Quote from: TedLarsen on January 30, 2019, 11:55:47 AM
Yes, we initially setup our test environment using the in-console publishing, but after the fact, we installed the Patch my PC publishing service to test that functionality. I'm hoping that's not contributing to this issue, but given the other application updates are working fine, I doubt that's the case.

No that wouldn't matter. Firefox would have been ignored if it was previously published using SCCM so it would have had this issue.

Firefox 65.0 was actually released in yesterday's catalog update. If it's enabled in the publishing service products, could you go ahead and run a manual sync to publish this new update. The previous one will become superseded. After publishing, just sync you SCCM SUP and the new update will be available. The new version should just work since the publishing service never had this issue.

TedLarsen · January 31, 2019, 10:25:20 AM

Hi Justin. I'm still not seeing FF 65 download this morning in the latest sync. Note that we are using the trial catalog (if that matters to you). Attached is the sync log from this morning. It appears that it's still trying to download FF 64.0.2. There are also consequently two "verification of file signature fails" listed, but unsure of those are related to the FF issue or not.

Thank you for your time on this.

Justin Chalfant (Patch My PC) · January 31, 2019, 06:08:23 PM

Please try to sync the catalog again. Looks like the trial didn't get updated for this release. It should be now.

TedLarsen · February 01, 2019, 10:06:18 AM

This took care of the issue Justin. 65 is installing properly. Thank you again for your help!

mythosaz · February 13, 2019, 06:56:22 PM

Merged Topic

The cab file does not seem to contain a valid file.

https://imgur.com/a/Cn80fxA

Yields the following when deploying to machines:

https://imgur.com/a/PRR2SBl

...which is The system cannot find the file specified.

[Edited to provide links to the images - not showing inline.]

Justin Chalfant (Patch My PC) · February 13, 2019, 06:59:11 PM

Did you use SCCM 1806 to publish the update content for this WinSCP update? There was a bug in 1806 that I believe may have been addressed in 1810 that causes the downloaded filename not to be correct in a few scenarios.

This issue shouldn't happen if you use SCUP or our publishing service https://patchmypc.com/publishing-service-setup-documentation

Adding error description for search results: The software change returned error code 0x80070002

mythosaz · February 13, 2019, 08:26:59 PM

Yes, this is 1806.
No, the hotfix is not applied.
I am importing "directly" through the new Third-Party Software Update Catalogs process.

Scheduling a window for the hotfix will take some time. I've disabled (or rather, edited the membership of) the patch for now.

Justin Chalfant (Patch My PC) · February 14, 2019, 06:14:02 AM

Can you publish it using our tool in the meantime or would it not matter enough to do that?

DVK · March 20, 2019, 09:41:11 AM

Hello. We have same issue with 5.13.8. We are using 1806 publishing. Hotfixes were applied. How to fix this on devices?

Justin Chalfant (Patch My PC) · March 20, 2019, 09:45:56 AM

The update will need to be republished using our publishing service as a workaround until the next WinSCP update comes out then SCCM should work if all hotfixes are applied.