Messages

[/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! 

Hey Scott,

After talking with the Devs here, we may have some ideas of how to better tweak the detection logic to help in these scenarios.

Check back with us soon and we may have a solution for this!

At this time however, the suggestions above may help you in the meantime!

Hey Scott,

Based on this post it soundd like you're trying to install a 64-bit update on a 32-bit device (OS). Since those applications/updates can't be installed on a 32-bit OS the detection has been coded to show as not applicable when trying to install a 64-bit product on a 32-bit OS.

I would recommend create a separate collection with those 32-bit devices then target all 32-bit updates to that specific collection. That should help resolve any errors in the AppDiscovery Log since those updates will be applicable.

By default there are no requirement listed under the detection method. You may have the right click option enabled to set those requirements as shown below:



https://ibb.co/GRZqW6f

If you disable that option, then it will not apply to further application packages for that app. Then you can delete that requirement type from the existing package to install it on 64-bit devices.

[ConfigMgr Apps]

Hey RJ,

Thanks for reaching out!

I'll do my best to explain the main differences here but please feel free to reach back out if you need more clarification!

ConfigMgr Apps
- Provides the base installation package of the application which is Published under the Applications node in the ConfigMgr Console.
- Applications can be deployed using all 3 Intent methods (Required, Available, and Uninstall)
- If deployed as REQUIRED the application will forcibly install (If not installed) or update (If detected as installed) on the targeted client devices.
- Applications can also be used in Task Sequences for OSD. We can also update the Application package in place, providing you with the latest version that gets installed during that deployment.

Software Updates
- Provides the update .CAB file for the product which is first Published into your WSUS Database then synced over to the SCCM SUP during a SUP Sync.
- Update packages have Applicability rules defined in WSUS allowing them to only be installed if the client has the application installed and if that application version is older than what is being installed.
- Deployments of Updates can be automated by configuring Auto-Deployment Rules or ADR's within SCCM. https://patchmypc.com/how-to-use-automatic-deployment-rules-adrs-with-patch-my-pc

Overall, it's really up to you as an admin how you would like to handle deployments. I personally would recommend setting applications as available deployments (Required applications can be deployed as well to make sure they're installed) in Software Center and allowing your userbase to install any new apps that are needed. Then going forward, you can publish the update packages for those apps and deploy them during a certain period to update those Available applications. This process can then be Automated to using those ADRs mentioned above.


Just as a side note here that some products are only supported to be Published in certain ways as listed on our Supported Products page: https://patchmypc.com/supported-products

For example, some products can only be published as an Update Package (No application package is available) and vice versa. The Application Package is supported however, the update package is not.

Again, please let us know if you have further questions or reach out to our support email for further assistance!

[email protected]

[10.2.1]

It looks like version 10.2.1.20007 was an out-of-band patch that resolved some found vulns (CVE-IDs: CVE-2022-3602; CVE-2022-3786) which is also using the same major version product code. Because both versions are using the same product code (10.2.1) it breaks our detection.

For reference, I have included the link to our release catalog showing the previous version with CVE's:
https://patchmypc.com/patch-my-pc-catalog-update-11-02-22

Here is the link showing the most current release (10.2.1.20132):
https://patchmypc.com/patch-my-pc-catalog-update-11-09-22

To remediate this, we will either be adding the latest version 10.3.0 (If it's Stable - Pending confirmation) or included a Pre-Req script that will properly identify the 10.2.1.20007 version.

Hopefully that helps answer your question! Unfortunately, I wasn't able to find anything regarding the previous update .20007 just links back to the overall 10.2.1 release notes.

Hello and thank you for bringing this to our attention! We have checked and confirmed that Tenable released a newer version today (10.3.0) that should resolve this issue!

https://docs.tenable.com/releasenotes/Content/nessusagent/agent1030.htm

At this time, I would decline the current Nessus updates as to not cause further failures on pending clients. Once the new version has been added, run a Publisher sync and you should see the latest version being pulled in.

To keep tabs on catalog updates, you can visit our change log here: https://patchmypc.com/category/catalog-updates

Hey Ben,

Thanks for reaching out here! I have created the following idea on our uservoice page requesting the JRE version be added to the catalog. If/when it's been added you will receive a notification so you can enable it in the Publisher!

Here is the link to the idea: https://ideas.patchmypc.com/ideas/PATCHMYPC-I-2547

Let us know if you have further questions!

Best,

Spencer

Thanks for reaching out here!

In a Co-Managed situation, you have a couple ways you can configure this to work in your environment. Since SCCM is not handling Windows Updates, you can enable the Dual Scan functionality so that WSUS/SCCM will still push out Third-Party Updates while Intune will control your Windows Updates.

Here is the Microsoft Learn Document about the Dual Scan Feature - https://learn.microsoft.com/en-us/windows/deployment/update/wufb-wsus

This will allow you to control both Applications and Third-Party Updates via SCCM. Now when you're ready to switch the Client Apps workload over to Intune, then that will also allow you to deploy and control SCCM apps on a Co-Managed device. You can ALSO push both Apps and Updates from Intune to those Co-Managed machines making the need to enable Dual Scan obsolete.

Hopefully that helps you out here, however if you'd like more information on Co-Management Workloads you can reference this here: https://learn.microsoft.com/en-us/mem/configmgr/comanage/workloads

Also, feel free to respond back and we can always follow-up!