Messages

Hello,

We provide the EXE because there is no direct download for the MSI.

While it might be possible to extract the MSI from the EXE, that adds some extra layers of complexity when it comes to automation, and is something we generally try to avoid. It is best to download the binary directly from the vendor without having to make modifications.

You can still provide an MST file to the EXE, please see this uservoice where the issue is discussed. https://ideas.patchmypc.com/ideas/PATCHMYPC-I-668

Ultimately, we have added software to the publisher based on customer requests in our uservoice https://ideas.patchmypc.com/

There are a lot of scenarios where even in an enterprise environment the user might install software such as CCleaner or Malwarebytes, such as you saw.

Removing such software due to licensing is definitely a good approach, and likely the preferred path, but I can see a scenario where removing software can take time to get the approvals and work through corporate processes. In the meantime, the software could be patched to mitigate potential vulnerabilities.

Are you able to download the files found in the log file, and run the command it is running in an elevated command prompt?

C:\Users\George Brown\AppData\Roaming\PatchMyPC\gacutil.exe /i C:\Users\George Brown\AppData\Roaming\PatchMyPC\Microsoft.Win32.TaskScheduler.dll

It may give you some idea of what is going wrong.

Hello,

This is the update attempting to download, and install the Win32.TaskSchedule dll. This is expected behavior from the publisher.

Is this stopping the tool from running? You may need to create some AV exclusions in Avast.

Hello,

As long as you have updated your ADR to no longer deploy the update, it should not be adding to any SUGs going forward, and not be deployed automatically.

This looks to be a known issue with Adobe.

https://helpx.adobe.com/acrobat/kb/error-1328-applying-patch-to-file.html

Are you able to reproduce the issue if you run a manual install of the update by downloading the binaries from the vendor?

Nunur,

The CMG will continue to be supported by Microsoft, despite using some classic features. It is your best solution for delivering third party updates to an internet based device if you are also using Configuration Manager. You will not see the CMG feature lose support any time in the foreseeable future. You may see them migrate away from the Classic deployment method, but they would provide a migration path to ensure existing class-based customer can moved to the newer implementation and retain support.

As for WuFB, you will definitely need the machine to be Azure AD joined in order to use the feature.

I see you mentioned version 20065, this is not the latest version.

You should see 20067 available to you. Are you able to deploy this version and see if it works as expected?

Hello,

What version are you upgrading from on this device? Was Adobe Acrobat Reader DC running when the update was attempted?

Also, do you happen to have Adobe Acrobat DC installed alongside Adobe Acrobat Reader DC?

Great to hear! Glad you are working now.

That registry entry is supposed to be set by the client setting for ÔÇ£Enable Third Party PatchingÔÇØ when it is set to Yes.

If you do not have a client settings deployment, or your default client settings, with the Enable Software Updates setting, found under software updates, set then the client wonÔÇÖt manage that registry entry on your endpoints.

If that registry entry is not getting set by the Configuration Manager Client, and you know that setting is set, then you may need to repair the CCM client, or check into a corrupt registry.pol

Would you be available for a remote support session? We could quickly work through many of the common problems.

Hi there,

Would you be able to share with us the MSI product code for the version of Java you have currently installed on an affected machine that is seeing this error?

We may have missed a product code within our rule. You should be able to find this within the registry, let us know if you need help finding it!

The code signing certificate is supposed to come down as part of the Software Update Deployment Evaluation cycle. The certificate deployment should be reflected in the updatesdeployment.log on the client. The docs link below provides a little bit of information regarding this.

https://docs.microsoft.com/en-us/mem/configmgr/sum/deploy-use/third-party-software-updates#enable-third-party-updates-on-the-clients

You are correct!

Now that you have a new certificate in place, you will have to republish all the updates that you had previously published. This is because they were signed with a different certificate. Republishing them will ensure they are signed with the appropriate certificate that you've set up.

As for not seeing the certificate on the clients, the only factor for this is the client settings. It might be good to check the resultant client settings of an affected device. See this link for instructions. https://docs.microsoft.com/en-us/mem/configmgr/core/clients/deploy/configure-client-settings#view-client-settings This will show if you possibly have another policy conflicting. Aside from that, you are seeing the certificate in the Third Party Updates tab, so that is all set.

Let us know if you can't get it figured out. We can also set up a support call as well.