• Welcome to Support Forum: Get Support for Patch My PC Products and Services.

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Andrew Jimenez (Patch My PC)


I think we might need to see installation logs here. It sounds like there might be another installation that is downgrading the app after Patch My PC successfully upgrades it.

Can you please open a support request at: https://patchmypc.com/technical-support

With the Logs indicated under "Intune Applications/Updates Failing to Install on Client Devices" from here: https://patchmypc.com/collecting-log-files-for-patch-my-pc-support#application-troubleshooting-client-logs-intune in a zip file?


The recommendation can be found here: https://www.adobe.com/devnet-docs/acrobatetk/tools/Wizard/basics.html#transform-mst-file-basics

  • Once an MST is applied during an install, another MST can't be used later during an update (say, to change one setting).
  • During an update or repair, the installer references the MST file that the installation used when it was first installed.
  • The only way to use a different MST is to uninstall the product and then reinstall with a new MST file.
Adobe specifically recommends not applying the MST file for updates. I have not seen the MST required for Adobe update deployments, only the initial installation.
So if you are always going to the latest version of Splunk, ie: going from 9.1 to 9.2 when it is released, you should stick with latest. If you stick on a specific release for an extended period of time, choose that release instead, then move your customizations over.

You could also publish both, then pick and choose which one to deploy based on your needs, but that may get too complicated.

I can also confirm that we will be adding a separate entry for 9.2 to the catalog early next week.

That is interesting, it seems like there was an issue when trying to publish the postponed binaries that left you in this state. The best thing to do in this situation would be to delete the existing apps and their content and have Patch My PC recreate them on the next sync.

If you notice a really recent date on one of these apps, feel free to open a case with our support and send over the logs and we might be able to determine why creating the app failed.
We'll also be investigating if 9.2 needs to be added as its own product, which I believe it will be!

Unfortunately, I don't see an easy way to accomplish this. Our notification requires that a conflicting process be open to show up...

I'd recommend taking a look at the PowerShell App Deployment Toolkit for this: https://psappdeploytoolkit.com/ I think it can make a popup with more generic launch conditions.
We'll check out that installer. I believe if you install .NET 6 before workspace, the online installer will still work. If you replace the binary for the ConfigMgr App after Patch My PC has created it, we won't flag it. Hash checks occur after the binary is downloaded from the internet before it is placed in the package.

The best option at the moment is probably to add a post-install script to remove the shortcut, or check if there is a property that can be passed to disable the creation of the shortcut.

A quick Powershell Script with the following could probably do the trick:
Remove-Item C:\Users\*\Desktop\[shortcut.lnk]

Should do the trick, you could also target just the default profile's path to skip removing the shortcut from every user's desktop.
The Modify Published Updates Wizard should work on a WID database with no changes, as it uses the WSUS commands to access the database. I am guessing that your database is quite large, which is causing the slowness (or even timeouts). I would recommend running the native WSUS cleanup routines (probably a few times) to see if that speeds things up.

The Publisher defaults to "Full Content" for updates so that they are immediately available to ConfigMgr for deployment. You can right-click updates in ConfigMgr and set them to "Metadata Only" to not bring in the content, however, if you need to deploy the update later, you will need to switch those products back to "Full Content" and run another Patch My PC Sync to make the content available for ConfigMgr to deploy.
This is expected. For products that have multiple major versions, we will only update within that version, You should be able to deploy the App of version 11 to upgrade version 10.

For more info, check this KB article: https://patchmypc.com/products-multiple-versions-patch-my-pc
The updates are helpful for situations where you do not know where the software is currently installed. The updates have an applicability rule to determine if the software is installed before it runs the update. This helps simplify things, as you do not have to make a group for each specific update, as you can just deploy the update to "All Devices" or similar, and the updates will only install where they are needed.

We have a KB article describing the different use cases here: https://patchmypc.com/intune-apps-vs-intune-updates
The applicability scripts look for any older version of the software, unless the version number is called out specifically in the Product name in the Publisher.

What is likely happening is that you have deployed the 32-bit EXE while having a 64-bit MSI installed or some other combination of installer type and architecture. If the installer type or architecture of the update don't match, the update won't be applicable. If you think you have the 64-bit version of 7-zip, deploy both the MSI and EXE updates, and one of them should be applicable and update your device.
I'm interested in collecting feedback on these. Feel free to submit them on the ideas page. Device drivers become a very deep rabbit hole when it comes to testing, versioning and targeting for devices. So, in general, we are reticent to add them. However, we are also open to exploring new ideas.