Messages

With regards to the reboot even though REBOOT=ReallySuppress has been set: Setting REBOOT=ReallySuppress only prevents the app/update from forcing a reboot on the endpoint, it does not negate the need for a reboot. A 3010 exit code is still provided to ConfigMgr/Intune, and those tools will determine if or when a reboot occurs.

You can set the deployment in either ConfigMgr or Intune to show no notifications, and this should prevent the reboot notification from appearing on the endpoints.

I did confirm that this issue should not be occurring now. So the delete and recreate of the Intune update will resolve this issue for you.

Hello,

This was an issue a while ago, and was fixed on our back end some time ago. I am not sure why it is occurring for you now! Delete the Intune Update and have Patch My PC recreate it, and you should see the errors go away. I am going to double-check our back end to ensure that nothing has changed to cause this issue for you.

Hello,

Because those are user-based installs, typical updates as SYSTEM will not detect and update them. The easiest way to update those installs is to actually push the machine-wide Application install to those devices, the Zoom installer is pretty good at updating existing user-based installs with a machine-wide install. Once the machine-wide install is in-place, Patch My PC updates can then continue to update the product.

This is the first I am hearing of it. I know in the past that you could request larger storage size, however, our size limits were not primarily due to Intune, they are also due to WSUS, as there is a max file size limit for WSUS, and built-in to SCUP. We have some plans to increase the max file size, and background work is happening for that now, but I do not expect to support larger installers until next year at the earliest.

Hello,

I just wanted to let you know that we shipped a split UniversalForwarder, if you deselect the UniversalForwarder 9, and select the UniversalForwarder 9.0, you should get the 9.0.6.0 version now!

Hello,

We'll need to "split" the product in our catalog to provide V9.0 and V9.1 versions separately. Please allow us a week or 2 to get this sorted in our catalog.

Hello everyone,

We have no root cause for this issue at this time. What we believe to be happening is that when the Google Chrome Update tries to install, AV blocks the file copy, and the install bombs out partway through. This leaves the old Chrome binaries on the device, and the device is left without Google Chrome in Add/Remove Programs.The common thread that we have found between most of the devices that have had the issue is the following log line in the chrome_installer.log which can be found in C:\Windows\Temp

[0912/180519.266:ERROR:move_tree_work_item.cc(90)] failed move C:\Program Files (x86)\Google\Chrome\Temp\source5400_1011282578\Chrome-bin\116.0.5845.188 to C:\Program Files (x86)\Google\Chrome\Application\116.0.5845.188: Access is denied. (0x5)

After the access denied error, the Chrome installer MAY return with a 1603, but not always. Regardless, the fix has been the same for all customers, reinstall Chrome with the Intune or ConfigMgr App. Afterwards, things should continue working. Sometimes, customers have had to turn AV off for the reinstall to even work, this makes the AV hypothesis a bit stronger. I believe all of the customers that have faced this issue were running Defender.

If you do encounter this issue, please open a support case with Patch My PC, and include the following logs:
C:\Windows\Temp\chrome_installer.log
C:\Windows\CCM\Logs\PatchMyPC-Scriptrunner.log (if exists)
C:\ProgramData\PatchMyPCIntuneLogs\PatchMyPC-Scriptrunner.log (if exists)_
C:\windows\ccm\logs\PatchMyPCInstallLogs\GoogleChromeStandaloneEnterprise64.msi.log (if exists)
%ProgramData%\PatchMyPCInstallLogs\GoogleChromeStandaloneEnterprise64.msi.log (if exists)

Hello,

We have a few reports of this issue now. We are trying to determine the exact cause. We have been unable to replicate the issue internally as well. If anyone is able to, please send over logs to support, specifically, we are looking for the verbose MSI logs (if they are enabled), the log from "C:\Windows\Temp\chrome_installer.log", as well as the PatchMyPC-Scriptrunner.log.

This issue seems sporadic, and we have been unable to tie it to a specific version of Chrome.

Hi Michael,

Your proposed solution looks correct, it also should not cause another scan storm as all you are doing is modifying the content location.

This is a super common issue faced after an in-place server upgrade. The other thing you will want to look out form after things start working again is: https://patchmypc.com/duplicate-patch-my-pc-category-listed-in-software-update-point-products-tab

Hello, it seems Opera released a fixed version after 102 (still version 102) and that is what you are seeing.

Ahh, so that is our home updater. I will confirm that 102 has been pulled from the Home Updater as well.

Hello,

We've rolled back to version 101 in today's catalog. We will keep track and update when the next version is released.

Hello,

We have updated the detection for Screaming Frog so that it detects and updates correctly now.

Hello,

I heard back from the developers. No other variables than the documented ones are exposed to the scripts.

They also mentioned that you will want to ensure if you are writing to the scriptrunner log, you will want to conform to the formatting used by that log (CMTrace format)