Messages

Thanks! Technical Support case has been opened.
I also verified that I'm able to open the WSUS console.

Suddenly started seeing multiple errors in the Patch My PC log file. First noticed it after receiving the daily report email a few days ago. All SCCM apps and updates are failing; some but not all Intune apps and updates are failing.

Only clue I have at the moment is that the server on which we host Patch My PC was transitioned from on-prem to Azure a few days ago, and this *possibly* aligns with when we began seeing the Patch My PC-related errors.

Errors I'm seeing in the log include:
1. An error occurred while publishing with timestamping, and timestamping is enforced: Failed to sign package; error was: 2147954402 [System.InvalidOperationException] HResult: -2146233079. Please see kb: https://patchmypc.com/timestamping-connection-failed
- This was the first error I spotted but doesn't appear to be the root cause of the issue. I temporarily disabled timestamping per the KB but that didn't resolve the issue.

2. An error occurred while getting the list of supported products [Status code: 404]: Not Found
Status: 404
Response:
 [PatchMyPC_Core.Cloud.Api.AppCat.ApiException] HResult: -2146233088

3. An error occurred while getting the list of vendors:
---> Failed to get the list of custom supported products [Status code: NotFound] [System.Exception] HResult: -2146233088

4. An error occurred while sending ConfigMgr Builds telemetry: The RPC server is unavailable.
 [System.Runtime.InteropServices.COMException] HResult: -2146233087

5. An error occurred while connecting to WSUS to gather telemetry: Unable to connect to the remote server

6. A connection to the Patch My PC cloud has not been created yet. Please create a connection first and try again.

7. Failed to verify connection to the cloud: [StatusCode: 404]

8. 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.

There are a few others, but the above examples seem to be the most frequent errors in the log.

Not sure where to begin troubleshooting. I've clicked on the couple "test" type buttons in the Patch My PC console and haven't encountered any errors, but beyond that, my troubleshooting experience with the product has been limited.

Thank you.

Reason I'm asking if PMPC uses WinGet is because my company is considering setting a policy to turn off WinGet. Just want to make sure I understand any impact from a PMPC perspective. Thanks!

Confirming that deleting and recreating the Intune update resolved this issue. Thanks a lot!

Sounds good; I'll give that a try. Thanks!

Wondering if anyone else is seeing an unusually high percentage of installation failures for the GitKraken 9.1.1 (User-x64) update? We're seeing close to a 30% failure rate; however, currently all the failures are for devices that don't have the application installed. The two most popular error descriptions are "Error unzipping downloaded content. (0x87D30067)" and "0x80071509".

Of interest: as noted, on all the devices listed as having failed to install the update, GitKraken is not installed. However, Git IS installed.

Wondering if possibly there's an error in the detection script? It appears to be looking for "Git*", which I'm thinking might be an issue, but not certain.

Thanks for the recommendation of deselecting the "Prevent the end-user from opening an application while the application is updating" checkbox.

Since my original post, I've received reports from a few additional users having the same issue as I described in my original post, but for different applications. So I'm going to check that setting for those apps, as well.

I'm a bit confused, though, about when we should/should not enable/disable that particular setting, especially after discovering that enabling the setting can cause problematic behavior. Any guidance from PMPC regarding best practices for setting/not setting that particular setting?


 

I've had a report from a few users that after Visual Studio Code upgraded from v1.82.3 to 1.83.0, the application would no longer launch from the Start menu or the task bar. We found a registry key at HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\code.exe that appears designed to prevent the application from launching during the upgrade (we have this option set in the PMPC console).

My guess is that the upgrade process is designed to remove this reg key after the upgrade completes. Once we manually delete that registry key, the application launches fine.

I wasn't able to replicate the issue in testing. So far it's been reported only by Windows 11 users, and only 3 users so far.

Mostly wanted to mention it here for visibility. Will update this thread with additional info if the issue becomes more widely reported. 

Thanks, Ben. Will post the logs to the site you noted momentarily.

Wondering if anyone could shed light on a mystery. We have GitHub 2.27.0 (x64) in Config Mgr and Intune. I see in the email notifications from PMPC that the application was updated on April 10, 2023.

But then we also have a GitHub 2.5.0 (x64) that appeared in Config Mgr and Intune on April 11, but I see nothing in the PMPC email notifications about this version, but the summary in Config Mgr says the app was created by PMPC. In looking, I see that the two applications were created by different versions of PMPC.

One other weird thing was that the deployment wasn't to any of our production collections, just some random test collection.

Wondering if anyone had any info about GitHub CLI version 2.5.0. Thanks!

Thanks, Andrew. So to clarify, just go into the PMPC console, and for any updates in the log w/ the 'unsupported state' message, right-click the update and select 'Republish during next sync cycle'?

Here's my scenario: we updated the third-party certificate we use for PMPC. After that we redownloaded all the third-party updates. Then triggered a WSUS sync and redeployed to our SCCM Distribution Points.

Things looked 99% good at that point. But we did notice when reviewing the Patch My PC log and email and comparing that with the third-party updates in SCCM, a handful of the patches didn't appear to update. I started looking into it and began testing with one patch in particular just to see what would happen.

What I did was bring up the Modify Updates Wizard in the PMPC console. I selected one of the patches that hadn't updated and then I clicked the "Re-Sign Update" button. Then ran a PMPC sync. Noticed a bunch of red error messages in the log file. The message for the specific update I tried to re-sign said:
"The update [Camtasia 2019 19.0.10.17662 (MSI-x64)] has an unsupported state [Failed]".

So I'm guessing that's not the right solution. 

I did a WSUS sync again after that, and did a test deploy of a couple random updates. That seemed to work fine.

However, I still see lots of red messages about unsupported states, as noted above. What's weird to me is that the message is showing even for the updates that I did a test deploy with and they worked.

Not sure what to do now to eliminate the 'unsupported state' messages.

Thanks for the response. To make sure I'm understanding correctly, let's say I want my default Available/Deadline times for all applications to be +0 days and 01:00/02:00.

And let's say I have one application for which I want different Available/Deadline times (say +0 days and 03:00/04:00, for example).

So setting the "Manage assignments" times differently for the application will take precedence over the settings I made at the top level (All Products...)?

When I launch Patch My PC on the server and go to either the "Updates" tab or the "Intune Updates" tab, I can then right-click on "All Products (Right-Click for Customization Options)", and from the list of options, I can choose "Manage assignments".

I can also select an individual application and then right-click "All Products (Right-Click for Customization Options)".

From there I can set "Availability" and "Deadline" times, among other selections.

My question is: which takes precedence: the top-level "Manage assignments", or the one associated with the individual application? For a specific example, let's say the top-level Manage assignments Availability/Deadline settings are set to +0 days at 01:00 and +0 days at 2:00. And let's say that for a specific application, those settings are 03:00 and 04:00.

Wondering which takes precedence.

If I'm using a custom post script with an application, and if I change Patch My PC's default uninstall command in Configuration Manager, will I need to manually update that command every time Patch My PC updates the application?

Application in question is DBeaver. Everything appears to be working correctly in Configuration Manager--I've tested the install and uninstall and both are successful.

I did have to change the default Uninstall command in Configuration Manager (under "Deployment Type"). Originally it was set to "PatchMyPC-ScriptRunner.exe /UnInstallPackage", but this resulted in an error when I attempted to uninstall the application from within Software Center. I think this makes sense since I was using two different Detection Methods: one that confirmed the DBeaver executable was present, and one to confirm a custom registry key was present (which I was setting at the very end of my custom script), and the error code being thrown by the uninstall indicated one of the Detection Methods was still valid even though DBeaver was uninstalled.

So because I changed the default command, is this something I'll need to do manually each time the application gets updated by Patch My PC, or is there a way to get my Uninstall command (which is just the default command for the PowerShell App Deploy Toolkit: "Deploy-Application.exe -DeploymentType 'Uninstall') to "stick"?