Messages

Hey Alex,

I received your email with the logs yesterday and provided an update. Please respond back to that support email if you have further questions or issues!

Best,

Spencer

Hey Fabian,

Thanks for the update, glad this issue has been resolved! I will inform our internal engineering team so they can assist other customers who may run into this issue as well. 

Best,

Spencer

Hey Alex,

Thanks for reaching out to support!

I tried to repro this issue in my lab, however, was unable to do so. If you can, please send me the following logs from one of the affected clients:

When troubleshooting SCCM application installation errors on a client, we will need multiple client logs. Please include the following logs:

- %WinDir%\CCM\Logs\AppDiscovery*.log
- %WinDir%\CCM\Logs\AppEnforce*.log
- %WinDir%\CCM\Logs\AppIntentEval*.log
- %WinDir%\CCM\Logs\CAS*.log
- %WinDir%\CCM\Logs\CIAgent.*log
- %WinDir%\CCM\Logs\DataTransferService*.log
- %WinDir%\CCM\Logs\PatchMyPC-ScriptRunner.log
     This may be found in the %ProgramData%\PatchMyPC\ if the Install was initiated by the user from Software Center.
- %WinDir%\CCM\Logs\PatchMyPC-SoftwareDetectionScript.log
     This may be found in the %temp% of the user who clicked 'Install' in Software Center if it was an 'Available' deployment.
- %WinDir%\CCM\Logs\StateMessage.log
- %ProgramData%\PatchMyPC\PatchMyPC-UserNotification.log
- %ProgramData%\PatchMyPC\UISettings\UINotificationSettings.xml

Can you also confirm that those ConfigMgr clients are updated or at least matching that of the Admin Console? You can updload the logs to [email protected] for review.

If you have further questions or issues, please let us know! 😊

Thanks, dhwatts for the info! I'm testing this in my lab now with both the EXE and MSI versions to see if there are any issues with the detection logic.

Please still send logs over for review, I will update with my findings as well!

[MSI (s) (1C:84) [08:45:00:504]: Unable to delete the file outside of the engine. LastError = 2]

Thanks for reaching out to Support! I took a look at the MSI log and all i'm seeing is the following:

MSI (s) (1C:84) [08:45:00:504]: Unable to delete the file outside of the engine. LastError = 2

This usually means "File Missing" - This could be a transform file that is in reference in the command line.

To better understand the issue, can you please send the following client-side logs to [email protected]:

Intune Logs:

https://patchmypc.com/collecting-log-files-for-patch-my-pc-support#application-troubleshooting-client-logs-intune:~:text=Intune%20Applications/Updates%20Failing%20to%20Install%20on%20Client%20Devices

SCCM Logs:

https://patchmypc.com/collecting-log-files-for-patch-my-pc-support#:~:text=Third%2DParty%20Software%20Updates%20Failing%20to%20Install%20on%20Client%20Devices

Once we have them, we'll update you with next steps! If you're unable to send the logs through normal email methods, then please upload them here:

https://patchmypc.com/share

One thing I wanted to add here! When using the following command line (/SKIPSTARTINGPOWERAUTOMATESERVICE) and if you're using Manage Confilicting Processes, please ensure that the option to "Prevent the end user from opening the application." is NOT checked. As this will cause the install to hang and fail.

More informations can be found here: https://patchmypc.com/manage-conflicting-processes-when-updating-third-party-applications

Awesome, glad the manual test proved successful! Once the new version is released (Should be in todays catalog) let us know the outcome! Fingers crossed; it should be the same as running it manually!

You're welcome, Vern!

Please do let us know the results of your testings! We may need to update our Known Issues page with this information for other interested parties!

Best,

Spencer

[/SKIPSTARTINGPOWERAUTOMATESERVICE]

Hey Vern,

Wanted to post a follow up that may also help!

You can try to add this command line argument via the right-click option "Modify Command Line" and see if that helps:

/SKIPSTARTINGPOWERAUTOMATESERVICE

Note: That this will prevent the service from trying to start resulting in a 3010 or reboot being required to complete the installation and hopefully start the service again.

I would recommend testing this to ensure you get the proper outcome. However, that is also highlighted in the article above as a recommended solution for some of the other errors with PAD.

Hey Vern,

Thanks for the log files!

After further review it looks like this may be an issue with Security Policies blocking the NT SERVICE\UIFlowService from logging on as a service.

I would verify if you have any GPO's in place for "Deny log on as a service" policy and see if there is an account in there that may be blocking that service from running (i.e. Everyone)

For more information, please reference the following link:

https://support.microsoft.com/en-us/topic/power-automate-desktop-installation-troubleshooting-b2c93d3f-5a90-450a-833d-920a25f2d967#:%5C~:text=Power%20automate%20service%20failed%20to%20start%3A%20Verify%20that%20you%20have%20sufficient%20privileges%20to%20install%20system%20services

Hello,

Thanks for posting on the forum!

For this issue we'll want to look at those client-side logs and try to reproduce it on our side.

Can you please send the following logs to [email protected] and we'll investigate further!

When troubleshooting update installation errors on a client, we will need the following client logs:

%WinDir%\CCM\Logs\CAS*.log
%WinDir%\CCM\Logs\DeltaDownload*.log
%WinDir%\CCM\Logs\DataTransferService*.log
%WinDir%\CCM\Logs\PatchMyPC-ScriptRunner.log (If exist)
This may be found in the %ProgramData%\PatchMyPC\ if the Install was initiated by the user from Software Center.
%WinDir%\CCM\Logs\ScanAgent*.log
%WinDir%\CCM\Logs\StateMessage.log
%WinDir%\CCM\Logs\UpdatesDeployment*.log
%WinDir%\CCM\Logs\UpdatesHandler*.log
%WinDir%\CCM\Logs\UpdatesStore*.log
%WinDir%\CCM\Logs\WUAHandler*.log
%WinDir%\WindowsUpdate.log
You need to run Get-WindowsUpdateLog on Windows 8.1 and newer in PowerShell.
%ProgramData%\PatchMyPC\PatchMyPC-UserNotification.log
%ProgramData%\PatchMyPC\UISettings\UINotificationSettings.xml

We'll also want the MSI log file found in C:\Windows\Temp

Thanks,

Spencer Cruz

Hey Kyle,

Thanks for reaching out here! For this issue we'll need to look at some of the log files. Can you please source the following client side logs from one of the failing clients. You can send the logs to [email protected] and we can assist further!

When troubleshooting Intune application installation errors on a client, we will need multiple client logs. Please include the following logs:

%ProgramData%\PatchMyPCIntuneLogs\PatchMyPC-ScriptRunner.log
  This may be found in the %ProgramData%\PatchMyPC\ if the Install was initiated by the user from Company Portal.

%ProgramData%\PatchMyPCIntuneLogs\PatchMyPC-SoftwareDetectionScript.log

%ProgramData%\PatchMyPCIntuneLogs\PatchMyPC-SoftwareUpdateDetectionScript.log

%ProgramData%\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log

%ProgramData%\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

%ProgramData%\PatchMyPC\PatchMyPC-UserNotification.log

%ProgramData%\PatchMyPC\UISettings\UINotificationSettings.xml

Note: Some Patch My PC log files listed above may be found in %WinDir%\CCM folder if that folder exists.


Thanks,

Spencer Cruz

Hey lissadec,

Thanks for reaching out here!

Looks like there was a new version of UltraEdit released recently that we haven't yet added to the catalog.

Current catalog version - UltraEdit 29.2.34.0 (MSI-x64 en)

Latest release - UltraEdit 29.2.44 (MSI-x64 en)

I have informed our catalog dev of this update and we should have it in the new catalog release for you today!

If you would like to receive notification when we release a new catalog update, then you may subscribe to our catalog release newsletter here: https://patchmypc.com/scup-catalog-newsletter-signup

Hey Mark,

Thanks for reaching out, please do send us those logs for further review!

However, there was an issue with our detection scripts and naming of that specific version (.52) where we had named it .55 by accident. This has since been fixed and we suggest deleting the application using the ConfigMgr Application Wizard then running a Publishing Service Sync to pull down the corrected package/detection for that product.

https://patchmypc.com/how-to-delete-applications-created-by-patch-my-pc-in-sccm

Completely understand the issue and thank you for bringing this to our attention! I see now how this can affect reporting and since the requirements are handling the architecture portion then the detection scripts should just identify and check for both architecture types.

We'll need to check and see how this will affect other products but now that this is on our radar, we can get it addressed!