Just to help us understand the perspective here - what situation prompted you to make this request? Are you pushing the update for Adobe Acrobat Reader to All Devices, for example, and it is attempting to install on devices that have Adobe Acrobat installed?
If you are deploying Adobe Acrobat Reader as an Intune app, we do have a requirement script in our Community Scripts repo that you can use. This means the Adobe Acrobat Reader Intune app will not install if it detects Adobe Acrobat is already installed.
Just to add some extra thoughts to Spencer's reply here.
When you enable co-management, you are may be already aware that all Intune workloads will be blocked, by default, for devices with the ConfigMgr agent installed. In order to move workloads to Intune, you adjust the co-management workload slider.
When you move the Updates workload to Intune, DualScan is automatically enabled. This means that Windows Updates will come from the Windows Update Service and not WSUS/ConfigMgr. Typically, customers would use Intune to create update policies to manage how updates are scheduled and installed from the Windows Update service. Once DualScan is enabled automatically when you move the updates workload, all "non Microsoft" updates will still scan against WSUS. This means you can continue to publish 3rd party updates from PatchMyPC to WSUS/ConfigMgr and those clients will still receive them.
Most customers move the Updates workload because their clients are now on the "internet" more than they are the corporate network. If that is the case, you will need to be aware of that patch content being pulled over your VPN/WAN. An alternative solution here, to avoid bandwidth congestion on your WAN, is to use the Cloud Management Gateway (CMG) for any clients that connect over a VPN. This will require some boundary work to ensure internet clients are trying to pull content from the CMG rather than an internal distribution point.
Finally, you may have also considered the "Client apps" workload in your co-management scenario. When you move the client apps workload you are now allowing applications to be installed from both ConfigMgr AND Intune. This means, as far as Patch My PC is concerned, you can publish 3rd party updates to either Intune or WSUS/ConfigMgr.
Sorry its taken a while to respond on this thread.
I am just checking the MUI update in my lab now. Are you deploying from Intune or ConfigMgr? Which additional parameters are you passing to the Adobe Reader Updates or are you using a MST to disable updates?
Also, if by chance you are not using the Patch My PC Publisher and using the SCUP catalog only, you would need to create a share on your top level SUP and place the binary in that folder. Share Name would be PatchMyPCRepository - more info in the url posted above
We have identified a problem that appears to affect both 32bit and 64bit products for Adobe Acrobat Reader v22.003.20258.
Yesterday, Adobe changed the name in "Add Remove Programs" for this update.
This issue will affect detection of applications deployed from both ConfigMgr and apps/updates deployed from Intune. The apps will install OK but detection will fail. Updates pushed from WSUS would detect OK because they use the MSI code for detection from the MSP update file.
We are working hard to publish a fix for this in todays catalog. If you need an immediate, interim solution, please follow the workaround guide(s) below.
In ConfigMgr, you can update the $AppToSearch variable value in the ConfigMgr detection script - just remove " DC".
If you choose to do this, you will also need to remove the signature script block from the end of the script too because modification of the script will cause the signature code block to be invalidated.
In Intune, you can find the detection script in the "C:\Program Files\Patch My PC\Patch My PC Publishing Service\Detection Method Scripts for Intune" folder where the Patch My PC Publisher is installed
You can modify the appropriate script to remove " DC" from the $z variable value Once saved, you can replace the detection script for the corresponding Win32app in Intune
We hope to have this fixed in todays catalog release. Once we produce a fix, you will need to "re-publish" those apps again for the new detection script to be effective.
Sorry for any inconvenience. Please reach out if you have any questions in the interim.
Have you tried using "Modify Command Line" and "Pre/Post Scripts" Right Click Options?
You can try the additional argument CONFIGFILE="configuration.pulsepreconfig" in the "Modify Command Line" Right Click Option and then add your custom config file as an additional file in the "Pre/Post Scripts" Right Click Option.