Messages

Definitely, I will be at MMS!

Fix has been released.

Hello,

We are aware of this issue and should have a fix in today's catalog release, which I expect in the next hour or so. The issue is that filezilla added an ALLUSERS command, and didn't make it default, so the update is installing as the SYSTEM user, not for the whole machine.

Our plan is to remove the VC++ 2015-2019 and move to 2015-2022. Microsoft no longer provides updates for 2015-2019, and 2015-2022 should cover 2015-2019 when it is installed (this is why it does not let you install 2015-2019 when 2015-2022 is already installed, they are actually the same app and 2015-2022 is just a newer version).

We'll need to adjust the applicability rules for 2015-2022 to allow it to upgrade 2015-2019, then remove 2015-2019 from our catalog. I expect this to be completed by the end of March 2023.

Thanks for the reminder on this!

I'll revisit this next week. I've blocked off some time to look deeper into this. Thanks for the reminder!

I confirmed this issue, and we should have a fix with tomorrow's catalog update. Thanks for reporting!

Hi Simon,

Thanks for bringing this to our attention. This seems to be a recent change, we'll review and hopefully get this change in the next catalog release. I will post here with the results if/when we push the change.

Hello,

This happens if we cannot locate the package based on it's packageid, it is likely that the content or app was deleted for some reason. The fix is to delete the existing app and content from ConfigMgr, then run a sync. Patch My PC should create the app, and future updates should work.

Correct, you'll right-click the product under the "Updates" tab (not in the wizard), choose to republish on the next sync. Then run a sync. The old updates without content will be superseded by the newly created republished updates.

Hello,
SecureCRT is a manual download due to the fact that the install is locked behind a paywall. Therefore you must download the software and place it in a location for SCUP to pick it up and package it.

We have instruction and more information on our KB article here: https://patchmypc.com/local-content-repository-for-licensed-applications-that-require-manual-download

Hello,

So unsupported state means that the content for that update is no longer available (it has been deleted from WSUSContent, likely during some sort of manual WSUS maintenance). Because of this, re-signing the updates will not work. The fix here is to re-publish the updates that you see this issue on so that they can be signed with the new certificate, and have their content available again.

You can also use Manage Conflicting Processes to ensure all conflicting Processes are closed before the install occurs.

Adobe Reader has a surprising number of applications that will trigger a reboot if they are running during the installation. /norestart doesn't stop the 3010 exit code, it just stops the installer itself from prompting for a restart. When Software Center gets the 3010 exit code, it handles it as defined in Client Settings.

Two options you can do are to change the reboot behavior or change the exit codes in the deployment type settings to set 3010 to a non reboot code.

Hello,

Just to be clear this error:
C:\Program Files\Patch My PC\Patch My PC Publishing Service\Notification Localizations\GlobalSettings.xml cannot be found
Was not that the settings file couldn't be read, this error just meant that localization features for Manage Conflicting Processes hadn't been enabled. We actually removed that error in the latest build because it was causing confusion.

For your current issue, we use the content location to determine if we've published an app. By deleting the content for the app, it has been essentially orphaned, and will no longer be able to be updated. When deleting a Patch My PC app, the best thing to do is delete the app and the content. Then, on the next sync, Patch My PC will create the app and content anew, and should be able to successfully update it in-place again.

I hesitate to install via the MSI directly, as I believe that initial installs using the MSI usually end up running into the dreaded 1612 issue down the line. I believe the setup.exe (within the original install EXE), would be better suited to run instead of the MSI, however, I do not know if that setup.exe has the same issue during a task sequence than the original install exe.