• 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)

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.
This was shipped in yesterday's 4/4/2024 catalog release.
Perfect, the case was actually assigned to me :)

I'll continue via the support route and mark this as solved for now.
Based on the information provided. It sounds like there is an issue with the WSUS Code-Signing certificate on this machine.

An error occurred while extracting the certificate from WSUS:  C:\Users\[username]\AppData\Local\Temp\PMP-c45ja3yy\eixflf02.tmp : The underlying connection was closed: An unexpected error occurred on a receive.

Is likely the cause of your failures.

Is WSUS installed and configured on this server? Can you open the WSUS Console?

We'll likely need logs to troubleshoot further, feel free to open a case with us here: Technical Support

For custom apps, we require a silent install argument for the installer at this time, however, we may remove that requirement in the future. If the installer is running in the background, typically that means that the installation is never completing. This is usually due to incorrect install parameters.

It is always recommended to ensure that you can install the software silently in an admin (or better yet, psexec running as SYSTEM) command prompt before adding the application to Custom Apps.

We were unaware of a new major version. We'll look into getting this version added to our catalog!
Hello, we've attempted to replicate this issue with various setups and have been unable to replicate. Can you please open a support request here: Patch My PC Technical Support
Please provide information about the initial installation, as well as the MSI logs.
I would publish the base install app with Patch My PC, then uncheck the product so that Patch My PC does not update it further. Deploy out the base install, then let Zscaler handle it from there. The only issue you will run into is if you want to deploy an OLDER version from Zscaler, because then the Patch My PC app will continuously re-upgrade it if it downgrades.
For Zscaler, our we provide the latest available release. I would say if you want to manage the deployments beyond deploying the latest release, use the Zscaler console over using Patch My PC. If you always want the latest available, then the Patch My PC update is the way to go.

I would use scenario 3, and add a prescript. The prescript would do the following:
  • Determine the audience (not sure how to do this, maybe a registry value on the endpoint)
  • Copy the appropriate audience file to the path: Copy-item $PSScriptroot\Teamviewer_Settings_1.tvopt $PSScriptroot\TeamViewer_Settings.tvopt

When setting up Patch My PC, in Additional files you would have 2 additionalfiles instead of 1:
  • Teamviewer_Settings_1.tvopt
  • Teamviewer_Settings_2.tvopt

Everything else would be the same
Update here. An internal bug has been submitted to the dev team. The following can be used as a workaround:
  • Navigate to the ConfigMgr Apps tab
  • Select then de-select any product (this will light up the apply button)
  • Make your changes to Manage Conflicting Processes
  • Click Apply
  • Save and Close, then check that the settings adjustment was saved.

Updates deployed via WSUS are unable to patch user-based installs as they run as the SYSTEM account. This is a limitation of WSUS itself, and something we will not be able to change. Webex, and a few other applications in our catalog are a bit weird because even when they are installed as a User-based application, they still register themselves as a Machine-wide install. Because of this, our WSUS update for Webex does some file checks in addition to the MSI installation check. This can cause a lot of confusion, even for our support staff, as the applications look like they are installed as SYSTEM, but are not. In fact, trying to remove these installs using the SYSTEM account will fail, because the MSI is not registered System-wide (at the moment, I think this is hidden somewhere deep in WMI).

We have improved our user-based application compatibility by offering user-based apps under the ConfigMgr Apps/Intune Apps and Intune Updates tabs in Patch My PC.

Quote from: ekraus on May 17, 2023, 09:47:52 AMSo, I'm just running into this myself and, as Eddie78701 mentioned, it's a user install that appears in Hardware Inventory. This would mean, and I confirmed, that it has an entry in the HKLM area of the registry (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall). Below is the IsInstallable Rules taken from Cisco Webex Meetings and modified for Webex; I used the version referenced in the original post. Is it possible that the detection of the update could be augmented to use something like this?

<bar:RegKeyLoop RegType32="true" Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" TrueIf="Any">
  <bar:RegSzToVersion RegType32="true" Key="HKEY_LOOP_TARGET" Subkey="\" Comparison="LessThan" Data="" Value="DisplayVersion" />
  <bar:RegSz RegType32="true" Key="HKEY_LOOP_TARGET" Subkey="\" Comparison="BeginsWith" Data="Webex" Value="DisplayName" />
  <bar:RegDword RegType32="true" Key="HKEY_LOOP_TARGET" Subkey="\" Comparison="EqualTo" Data="1" Value="WindowsInstaller" />

Our current detection method for Webex for WSUS updates looks for the Webex MSI to be installed (which would be true on a user or machine-based installation) as well as files in Program Files. This ensures that the application to be patched is actually the machine-wide installation, and not the user-based installation. If we modified the applicability rules to look for the application in the registry like Webex Meetings, the update would install, but you would be left with 2 installations, one for the user, and one machine-wide.

Additionally, we have recently made some headway with these sort of apps by using our pre-scripts feature to remove the user-based applications with some help from PSADT. See the following script for an example: https://github.com/PatchMyPCTeam/Community-Scripts/tree/main/Install/Pre-Install/Remove-RemoteDesktopSystemUser

Using a ConfigMgr App deployment of Webex along with a prescript similar to the above (we'll work on getting that script up on the GitHub in the next day or so), should allow you to "migrate" an existing user-based installation of Webex to Machine-wide. I don't believe this will be a cure-all, however, as many security products flag user-impersonation as a malicious action, and may block such scripts.

I hope this has provided some background on the issue and the challenges we face when patching certain applications.
Unfortunately, there isn't a way to use this for an update, as the update would have to be applicable to the product already installed on the device.