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">
That's an odd exit code returned to WUAUHandler could you email the windowsupdate.log to support@<ourdomainname>, and we can troubleshoot there?
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.
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.
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.
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.
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.
Please try to sync the catalog again. Looks like the trial didn't get updated for this release. It should be now.
This took care of the issue Justin. 65 is installing properly. Thank you again for your help!
Merged Topic
The cab file does not seem to contain a valid file.
(https://imgur.com/a/Cn80fxA)
https://imgur.com/a/Cn80fxA
Yields the following when deploying to machines:
(https://imgur.com/a/PRR2SBl)
https://imgur.com/a/PRR2SBl
...which is The system cannot find the file specified.
[Edited to provide links to the images - not showing inline.]
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
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.
Can you publish it using our tool in the meantime or would it not matter enough to do that?
Hello. We have same issue with 5.13.8. We are using 1806 publishing. Hotfixes were applied. How to fix this on devices?
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.
Same issue with 5.13.9 :(
Hmm, maybe it's still an SCCM issue. Have you tried publishing using our service?
Is it compatible with 1806+ functionality? I mean, using both the 1806+ and the publishing service.
Yeah, that should be ok. I would only enable this problematic product in the publishing service if you still want to use SCCM.
It worked! Thx! :)
Merged Topics
Hello everyone,
I am new to third party catalogs. I am testing the trial catalog which includes Firefox. I am getting error 0x800700002. DP looks good. Any help is appreciated.
I believe you may have just opened a case via the technical support email page? If so, we can take this case there, and I'll follow up on this post with the resolution.
Yes, I did. I was not sure if I could get support ;D
Thanks
We will always provide support for anyone interested in our product :)
The workaround works. Publishing the update with the Publishing tool instead of publishing with SCCM. There is a bug with spaces in the deployment name with SCCM publishing.
We are also looking into repro-ing the issue and will reach our to the SCCM product group if it's still a problem in the latest 1902 build.
Quote from: nlopezs74 on May 16, 2019, 09:41:34 AM
The workaround works. Publishing the update with the Publishing tool instead of publishing with SCCM. There is a bug with spaces in the deployment name with SCCM publishing.
Yes, it is still a problem with SCCM version 1902. That would be awesome. Thanks for taking the request for a non-paying customer and finding a solution. I will be testing other deployments for a month or two.
Thanks again
Was the update published from 1902 or did you upgrade to 1902 after the update was previously published?
We have a repro in SCCM 1904 TP. We will report to the engineering team at MSFT to make sure they are tracking this issue.
It was the original created with 1810. I am going to try re-creating it with current version.
Thanks
The issue will still exist in 1902 we can confirm that.
OK Thanks.
Merged a few similar topics.
A Little Background
- SCCM 1806 originally had a bug where the in-consolep publishing of a download URL that contained a space such as http://download-installer-origin.cdn.mozilla.net/pub/firefox/releases/66.0.3/win64/en-US/Firefox Setup 66.0.3.exe would fail to publish with full-content. This bug was fixed in CB 1810.
- SCCM 1810 and 1902 resolved the publishing bug with spaces, but it now seems there is another issue on the client side where any update where the installer filename contains a space such as "Firefox Setup 66.0.3 x64.exe" will fail on the client side with error (0x80070002 = The system cannot find the file specified.) We reported this to the SCCM product group on 05/17/2019 and hope for a resolution in a future current branch build.
Workaround for this Issue:UPDATE: See workaround in the post below.The current workaround for this is to re-publish affected updates (Current known updates with issues is WinSCP and Firefox) using our publishing service https://patchmypc.com/publishing-service-setup-documentation as it is not affected by this issue.
More info on how to republish updates with our service at:
When, Why, and How to Republish Update(s) - https://patchmypc.com/faq-scup-catalog#republishing-updates
UPDATE: Workaround Fix Released on May 23, 2019After working with the Microsoft Configuration Manager product group and digging deeper into why this 80070002 (The system cannot find the file specified.) actually occurs. We were able to modify the filename in the SDP to match the downloaded filename from the vendor until a more permanent resolution is added into a future Configuration Manager current branch update.
We have created new updates that were released on May 23, 2019, at 8:30 PM that should resolve the 80070002 error on the client side. This updates will supersede the previous UpdateIDs with the same title name.
- WinSCP 5.15.1 UpdateID: 3e2aa875-ad20-4053-a653-63e8b2dce8f0
- Mozilla Firefox 67.0.0 (x64) UpdateID: 286bda43-2fc1-4f7d-8053-446b4f4a0cba
- Mozilla Firefox 67.0.0 (x86) UpdateID: 9b386b70-6fbc-4e24-803d-e270a4dea9e2
- Mozilla Firefox ESR 60.7.0 (x64) UpdateID: 4ed2b277-bfba-477d-b578-002ccf056179
- Mozilla Firefox ESR 60.7.0 (x86) UpdateID: cdea1ad7-e060-4b03-8fc2-7b95544b45b2