• 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 - Ben Whitmore (Patch My PC)

We have seen a number of these cases since Microsoft released a Kerberos hardening patch in October. Restarting the Patch My PC service normally fixes this. Thanks
Hi PS_Alex,

You can right click a configmgr app/product in our catalog to change the localized description. Does this help?

As we work to resolve the bug to display URLs in alerts/logs, please know you can right click any product in the Publisher UI and select "Show package info" which will also show the download URL. Thanks
Hello sw-deploy

The Publisher will use a specific .net class to connect to the internet in the SYSTEM context. To accurately mimic what the Publisher does, please try to access the URL using the following method:-

   • Download PSExec from http://technet.microsoft.com/en-us/sysinternals/bb897553
   • Extract PSExec
   • Open Command Prompt as Administrator
   • Run the following from the location that you extracted PSExec: .\psexec -s -i "C:\Program Files (x86)\Internet Explorer\iexplore.exe"
   • Attempt to access the URLs again
Hi @Kevin.McCurdy!

Yes please reach out, all previous paths we have followed to a HP Enterprise API have resulted in closed beta pages. Can you ping [email protected]?
Hi Korebreach,

These are just overly verbose telemetry activities. They have no bearing on the functionality of the tooling. I hope that helps?

Restoring the PMPC config is easy, we have a guide for that at https://patchmypc.com/backup-and-restore-publisher-settings

You should also consider the code-signing certificate and SUSDB.

If the code-signing certificate private key is marked as exportable, its recommended to move that to your new WSUS server - especially if its a self-signed certificate. If the code-signing certificate is issued from an internal PKI, its not so essential to use-the same one (assuming the code-signing certificate that you use on your new WSUS server to sign updates is also trusted by your clients).

Typically we recommend to use the existing SUSDB if you are doing a site migration. You can install WSUS on your new site server and use the existing DB. You should then also migrate/use the existing WSUS Content folders too. This is a great video on considerations for moving WSUS to a new server https://www.youtube.com/watch?v=bBcJY8_uHCQ - of course, WSUS should be installed be you configure the SUP role as per https://learn.microsoft.com/en-us/mem/configmgr/sum/get-started/install-a-software-update-point


Unfortunately, HP pulled their warranty API, see more at https://developers.hp.com/hp-client-management/forum/warranty-api-currently-unavailable

There is no other accurate way to pull inventory data for HP devices. For this reason, we can only pull in warranty data for Dell and Lenovo devices.
Thanks for the info Grzegorz. Please allow us a little time to review and we will let you know our findings :)
Thanks Tim,

We resolved this today with Lukas. The downstream WSUS server had corrupt column information for some of the updates in the database. We cleared those up and the errors were resolved.
Ah, we are working on this with Lukas today :)
Hi Tim,

Are you syncing Oracle Java SE Development Kit 8/11/21 out of interest?
Hi AndAuf,

Just swinging back round to this. It appears that Screaming Frog may have always been x64 architecture but has recently changed to x86. Me may have some work to do to fix our detection and better understand how we update teh catalog. Please bear with us and we will post an update here very soon.

You can also monitor our catalog release page to see when we release an updated Screaming Frog version if you would prefer


Thanks for bringing this new major version to our attention. Ill let our catalog team know to test and update this in our catalog.

PS. We only have the 64bit version in our catalog, not an x86 version

Thanks again AndAuf
Hey PS_Alex

We are explicitly calling Windows PowerShell to run our pre and post scripts.

(_sysPath, "WindowsPowerShell\v1.0\powershell.exe")

We dont have any plans to consider other interpreters at this time. If you think that would be beneficial, we do have an ideas page where you can drop that suggestion in with a use case :)


Hope that helps!