Messages

I was testing our latest wave of Patch My PC updates which now includes updates for FastStone Capture. I have found that the update applies successfully and is detected as such (The DisplayVersion is updated in the registry and reflected in Add/Remove Programs), however, it does not appear that the binary is updated. Further, when going to Help > About, the application says it is still the previous version.

This appears to occur because when the application is running at the time of update and does not have this problem if the application is not running or is closed first. Since FastStone, by nature, is always running, I was surprised that it was not already on your list of Products that Require Applications be Closed Before Installation found on the Known Issues and Considerations page. I'm pretty good about checking this prior to implementing new updates, so I was surprised that it was absent. Is this something that could be added to this page?

I see that the latest version of WebView2 was published over the weekend and the GitHub thread you linked says it's good to go now. Just closing the loop here; can we get a confirmation that the Patch My PC detection is functional again?

I ran into a self-created snafu with Microsoft WebView2 today where installs of the product were failing in our task sequence. We were using the Patch My PC packaged deployment to ensure that WebView2 was the most current version and found today that it WebView2 was updating on its own before reaching the Install Application step where we had it. Since we happen to be in the limbo period where the latest published version of WebView2 is less than the most current version available from Microsoft, the install was throwing a -2147219187 (GOOPDATEINSTALL_E_INSTALLER_HIGHER_VERSION_EXISTS). After examining the detection script, it doesn't look like it's doing a greater than or equal to operation on the version being installed. Is this something that could be modified for future versions of WebView2?

The BYPASSOUTLOOKCHECK=1 is already a parameter being used by Patch My PC for the install. Wouldn't adding it in this way pass it twice on install? Additionally, I do have other properties defined in this way for SSO and I do not see those properties in the uninstall log.

I'm working on testing the deployment of the Egress Outlook Add-in and found that, when uninstalling, it will prompt to close Outlook if it is running. This looks to be because the BYPASSOUTLOOKCHECK=1 property isn't being passed to the uninstall like it is for the install of the product. I could add a post-deployment script to get around this, sure, but is there a way to add this property as part of the uninstall string?

We recently updated our WSUS certificate and, as a test to validate things were honky dory, I enabled a previously unenabled application and update; in this case BlueJeans. After a couple of manual syncs and waiting a few days, I've noticed that it hasn't been published into ConfigMgr. When investigating, I found that there are no package details for it at all. Is BlueJeans still an available product in the Patch My PC catalog?

Thank you!

Is it possible to use a local EXE, meaning it already or will exist on the machine, as a Post Script action or does the EXE have to be included with the update/application? I am working on making the Tenable Nessus Agent 10 available and want to run a command after install using the installed agent, but the exit code in the ScriptRunner log is non-zero, so I'm not certain it ran the way I intended. Can I do this in this way or should I wrap this command into a script?

Just bumping this for visibility. Is there a possibility to receive a reply from an admin on this, please?

So, 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">
<lar:And>
  <bar:RegSzToVersion RegType32="true" Key="HKEY_LOOP_TARGET" Subkey="\" Comparison="LessThan" Data="43.4.0.25959" 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" />
</lar:And>
</bar:RegKeyLoop>

I see that the catalog was updated yesterday and can confirm that Cisco Webex Meetings 43.4.5.1 came through without issue. Thank you!

I've recently enabled Cisco Webex Meetings as an update and it has failed to publish for four straight days. The version expected is 43.5.2.4, but when I download the MSI using the link in the Patch My PC console (https://akamaicdn.webex.com/client/webexapp.msi), the version received is 43.4.5.1, so this explains the hash error. Does the catalog need to be updated to allow for this older version?

Is there a way to make applications created by Patch My PC that are deployed as available so the user can interact with the install? My use case is for Wireshark, specifically. The silent install for Wireshark does not include Npcap whereas the interactive install provides the user with the option to install it and I'd love for this to be an option with the Patch My PC delivered app.