Messages

Thank you for investigation and a quick resolution. Appreciate the help and the logic behind what occurred. Justin and Andrew are fantastic and very knowledgeable on this product! Thank you for all your efforts on this product, and thank you again for your help today.

I'll open a ticket. Thanks.

We're getting reports from customers stating that if Mozilla Firefox 76 or 76.0.1 is being installed or updated - the clients are removing that version and installing ESR 68. I've reviewed the System Logs on a couple clients and can confirm that this is happening via the detection/update process. Not sure if the code is contaminated or a version rule is incorrect. We had both regular current production Firefox and Firefox ESR as update products - I've since removed the ESR option.

This has been happening in the log the last few syncs.

Can not find webexapp.msi in local content repository, will download instead   Downloader   12/4/2019 1:30:12 PM   6 (0x0006)
Starting download for: https://akamaicdn.webex.com/client/webexapp.msi   Downloader   12/4/2019 1:30:12 PM   6 (0x0006)
Finished downloading file: [https://akamaicdn.webex.com/client/webexapp.msi] Average speed: 23.5 MB/s (72 MB)   Downloader   12/4/2019 1:30:16 PM   58 (0x003A)
Successfully downloaded the update   Downloader   12/4/2019 1:30:16 PM   6 (0x0006)
The hash of file downloaded is different than the file hash in our catalog. Hash errors happen when vendors release updates that aren't available in our catalog yet. This error should be resolved in the next catalog update. Additional details: Downloaded Hash [JNXBlzkxQVatqoc7gmbr8izYz00=] Catalog Hash [4KocqF8Hwsk4jzSQDCGOsRDTO7w=]   Worker   12/4/2019 1:30:16 PM   6 (0x0006)
*** Report :       
A total of 0 update was published, 0 update was revised, 0 update was expired, 0 application was published into SCCM, 0 SCCM package was updated, 0 package was revised in SCCM, 0 application was auto-enabled and 0 update was auto-enabled   
*** Failed :    
Cisco WebEx Meetings 39.10.2.177 has failed to be published with full content : DigestFailed   
   
Catalog subscription is licensed to   
*** End of report   Worker   12/4/2019 1:30:20 PM   6 (0x0006)
Next run date is: 12/4/2019 5:29:51 PM   Worker   12/4/2019 1:30:20 PM   6 (0x0006)
Starting download for: https://patchmypc.com/scupcatalog/downloads/publishingservice/latestversion.xml   Downloader   12/4/2019 1:30:20 PM   6 (0x0006)

Just to drop a post in the Kudos bucket. We've deployed 5 packages out of this catalog, in our first week. Made our Security guys happy, as the Tenable scan numbers drop. The response to posts for issues has been outstanding, either minutes or a few hours at most. Integration with WSUS and SCCM, quick turnaround for updates, Signed packages, software patches for third party apps... sincerely, guys and gals, great product... great support.  Thank you for all the hard work and effort you put into this!

Yes sir. English, US.

Yep, both. As far as I can figure, Mozilla knows that on a x64 bit machine, the x86 gets installed as well, and has been for some time - back to ver 50, at least. It is all over their forums. They recommend choosing the x86 version and removing it. For example - not going to post this as a working URL "https://support.mozilla.org/en-US/questions/1187643"

Key mentioned does exist. Only references x64 bit path (C:\Program Files\Mozilla Firefox)

Difference being located - as far as I can see in: HKLM\Software\Mozilla\Mozilla Firefox 62.0.3 points to C:\Program Files\Mozilla Firefox\firefox.exe, and HKLM\Software\Mozilla\Mozilla Firefox 65.0.1 points to C:\Program Files (x86)\Mozilla Firefox\firefox.exe.

Any known reason why when Firefox installs on a machine with both x64 and x86 versions - Firefox issue - that the patch runs on the x64 bit version and not x86? Case in point, we've several machines that have both versions, but only the x64 version gets updated to 65.0.1 and the x86 version is left alone? Is that a firefox issue or a detection rule issue, or does the client/customer actually need to run the x86 version to get it to recognize the install path?

Got it all straightened out now, updates are working as designed. Great product, please keep up the great work!

This doesn't mean the cert on WSUS:8531, correct? It means the cert that's on the signature of the file/update?

Catalog version 1.2.3, trying to publish our first update after purchase of Patch My PC. We've setup our WSUS to SSL - have both http and https available. Clients in testing have gone to the https side. I've got a valid cert on the publishing service, and have verified the updates are signed with same cert. Turned on publishing and the three clients i have in testing appear to have same cert. However, when running Windows Update, I get the above error.

{22EF6D8F-155B-495B-A0A0-C661FB1041E5}   2019-02-21 14:11:31:020-0500   1   148 [AGENT_DETECTION_FAILED]   101   {00000000-0000-0000-0000-000000000000}   0   800b0109   UpdateOrchestrator   Failure   Software Synchronization   Windows Update Client failed to detect with error 0x800b0109.   Km3z7UUvykqwGape.1.1.0.0.3.0