Messages

Hey Rob, we will get this out today!

Thanks Frank

I'm personally not familiar with our Home Updater - you originally posted your question in our Enterprise section (which is for different software we offer businesses.)

I've moved your question into the Home Updater area of our forum where the appropriate team can better help answer your question!

Hey Frank, is this for the Patch My PC Home Updater?

Hey laszloberger,

I can reproduce the issue.

I recommend you configure the following feature to prevent the update from installing while the software is running: https://patchmypc.com/manage-conflicting-processes-when-updating-third-party-applications

I will update our catalogue in the coming todays to ensure this is applied by default and set to "Skip".

Hey Burdarper

What you're observing is a bug (or "bad" design) in Intune, and how it handles the "ASAP" assignment option.

We have an article which discusses this here: https://patchmypc.com/intune-asap-assignments-bug

The solution is thankfully fairly straight forward with Patch My PC; for your Ring0 and Ring1 groups in the Patch My PC Publisher, you would change the availability/deadline to be +0 days @ 00:00 rather than leaving them at the default "ASAP". Kindly see attached screenshot which illustrates this.

Hey altu,

What you've observed is expected behaviour; we do not have have anything in the Publisher to manage deployments for ConfigMgr Apps like we do for Intune.

Like you've alluded to, SCCM has built-in capabilities to automate the deployment of software updates via ADRs. Software updates are also the best way to do patching with SCCM, instead of Applications.

Software updates have built-in logic to only apply the update to devices which need it; this enables you to deploy any third-party software update in SCCM to all devices, and the patches will only install on devices requiring the update. For example, if you deployed a Google Chrome x64 third-party software update from SCCM to a device which does not have  Google Chrome x64 installed, the update will do nothing have return "not required" / "not applicable".

You also don't have to use ADRs to deploy software updates with SCCM, you can deploy software updates just like you do any other Microsoft updates in SCCM; you could manually create the SUG, add updates to it, deploy it to a collection, download updates into a Deployment Package and distribute it to your DPs. However, ADRs do automate all of this effort.

You can even automate waved / ringed / phased deployments with software updates in SCCM, and especially so using ADRs, which you cannot with Applications - this is (IMO) an industry-wide best practice for patching; to deploy updates to test devices or power users first, before deploying them to everyone else.

The functionality to preconfigure the assignments for Intune exists in our product because Intune has no concept for automatic assignments, like SCCM does with ADRs.

If your SCCM devices are co-managed and the Client Apps workload is moved to Intune, you can absolutely start leveraging our Intune integration. If you prefer to keep things with SCCM for now, then of course it's possible.

We have an article here which discusses configuring an ADRs in SCCM, specifically for third-party updates:

• https://patchmypc.com/how-to-use-automatic-deployment-rules-adrs-with-patch-my-pc

I hope this helps.

Hello,
I'm using PatchMyPC with WSUS to deploy third-party updates to our servers. However, I have an issue where updates for applications like 7zip are bundled together with KB/security updates. This means that I have to install all updates rather than just the specific third-party update.
How to install only the third-party updates outside the maintenance window?
Thanks in advance

Hi louisegull,

I'm struggling a little to understand what you're asking.

Would it be possible to schedule a call so you can show me in a screenshare?

When this happens again is there a way to pull the update down without you having to post a direct download link?

Thanks

It's unfortunate that Adobe persistently have CDN issues and it's tricky for us because then that creates bad experiences like this for our customers.

A way for us to efficiently solve this problem when vendors experience CDN issues is for us to re-host the binary on our web servers but this has legal and perhaps security implications, too.

I appreciate it is frustrating. We will continue to apply pressure on Adobe via their support channels each time this occurs. Hopefully someone from Adobe will soon realise a pattern and address these problems.

Hi L.A

Do you have the product Node.js Latest enabled and deployed in the Patch My PC Publisher? These "Latest" products are designed to perform major version upgrades: https://patchmypc.com/products-multiple-versions-patch-my-pc

Hi team,

Running through an OS Deployment review in my environment, I've noticed that the PMPC package for Ms edge MSI-X64 with the detection script version 3.5 didn't notice that msedge version 127.0.2478.109 is installed. The PMPC version that is being pushed atm is 127.0.2478.105.

The detection script might need a tweak.

May you share some logs?

%WinDir%\CCM\Logs\AppDiscovery*.log
%WinDir%\CCM\Logs\AppEnforce*.log
%WinDir%\CCM\Logs\AppIntentEval*.log
%WinDir%\CCM\Logs\CAS*.log
%WinDir%\CCM\Logs\CIAgent.*log
%WinDir%\CCM\Logs\DataTransferService*.log
%WinDir%\CCM\Logs\PatchMyPC-ScriptRunner.log
%WinDir%\CCM\Logs\PatchMyPC-SoftwareDetectionScript.log
%WinDir%\CCM\Logs\StateMessage.log
%ProgramData%\PatchMyPC\PatchMyPC-UserNotification.log
%ProgramData%\PatchMyPC\UISettings\UINotificationSettings.xml

Also share all of the smsts*.log files aswell. Feel free to upload to https://patchmypc.com/share for privacy, or email [email protected].

There is an ongoing issue with Adobe's CDN where the following URL downloads a different file in some parts of the world:

https://ardownload2.adobe.com/pub/adobe/acrobat/win/AcrobatDC/2400220759/AcrobatDCx64Upd2400220759.msp

Analyzing the files downloaded in the US compared with the UK seems to suggest both files are identical, however, the non-US .msp file has an invalid digital signature.

They're both signed with the same code signing certificate by Adobe, so we don't believe there is cause for concern and it is likely a mistake in Adobe's release pipeline. It's unclear why the digital signature is invalid in the non-US file, however, in any case the SHA256 value is different between the two files.

As part of our security validation process built into the Patch My PC Publisher, all packages published must pass hash validation before publishing the package into your environment/tenant. As Adobe's CDN is distributing a different file globally, some customers may experience a failure publishing the product "Adobe Acrobat DC Continuous (x64)" with the below error in PatchMyPC.log, or email or webhook alerts:

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. It could also have been induced by a firewall issue. Additional details:Hash from catalog [qQ6Ki1uw6vUAK6JNlZb3y30QrA0=] doesn't match downloaded update hash of [o7ffhYWlMXvpYoPklinPQbYLiMk=]

We have notified Adobe of the issue in a support thread on their forum a few releases back (it was related to a previous release, but they have the same issue again and again): Invalid digital signature on AcrobatDCx64Upd230082... - Adobe Community - 14457702 - kindly upvote, comment, or if you have the means to, escalate this thread to an Adobe contact.

In the meantime, you can work around this by downloading the correct AcrobatDCx64Upd2400220759.msp (with the valid digital signature) using the below link hosted on our OneDrive and publishing it using your local content repository. Please make sure you have the option enabled to "Check the local content repository for content files before attempting to download content files from the Internet."

https://patchmypc-my.sharepoint.com/:u:/p/liviu/EdJTVoLPnT9Piy82OYmpIekBDL0j4QPprZURw_RS2FCVrA?e=baQxpc

Thank you. It looks like the hash of the .msi for Google Chrome's enterprise installer has changed, indicating a new version has been released. We will get this updated in the next catalogue release (more than likely today.)

Hello, I want to remove my catalog products inside SCCM SUP settings. How can I do this?
Please guide me. Thanks in advance!

Hi henrybullock,

What exactly do you want to remove and why? A screenshot might help illustrate accurately what it is you want to remove.

[Modify command line]

Hi, I am going through the initial setup of our PMPC apps. 
I need to install SoapUI using the answer file method as we need to put the tutorials in a custom location. 

Our current command line is "SoapUI-x64-5.7.0.exe -q -overwrite -varfile response.varfile" and the varfile contains the info instructing the tutorials to be redirected to another drive. 

question is, how do I configure PMPC to target that varfile. 

I'm guessing I drop it in a set / never changing network location and use the full path to it.  Is that how it is done or is there a different preferred method?  I have another app with a similar setup as well.  VSCode - requires this addition" /LOADINF="VSCode.inf"

Hello

Using the Patch My PC Publisher you can add your own arguments and include additional files within the packages. I'll show you how to do this below. Once you include the .varfile file as an additional file, you'll just need to reference the file relatively as it will be in the same directory as the .exe itself when it is stored server -side (and also in the cache folder when downloaded by the client, too.)

• Right-click on SoapUI in the Patch My PC Publisher
• Choose Modify command line and enter: -overwrite -varfile response.varfile (note I have omitted the -q parameter as this is applied by default, in this window we're supplying additional custom parameters.)
• Right-click on the product again and choose Add custom pre/post script
• Within the Additional files section, browse out and choose your response.varfile and click OK
• If this is for an Intune package, I recommend deleting the package in Intune and syncing the Patch My PC Publisher (via the Sync Schedule tab > Run Publishing Service Sync). For anything else (i.e. SCCM or WSUS), I recommend right-clicking on the product again, before synchronising, and select Republish during next sync schedule

Here are a couple of useful reference articles relevant to my suggestions:

• Modify command line
• Add custom pre/post scripts

I hope this helps![/list]

Hi Julian,

Thank you for making us aware of this. Have you contacted VMWare for support and notified them of a potential bug?