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.

Messages - Adam Cook

Pages: [1] 2 3 4 5
I'm old enough to be able to say that I can't tell you how many hundreds of times I've been told that, only to turn out it really wasn't the vast majority of the time.

Ok, two questions working on the notion that it is local:
- What could be causing it for TeamViewer and only TeamViewer?
- PMPC Support person Adam Cook says he replicated it on a fresh VM: what might his and mine have in common that could lead to that result?


To be clear, I didn't say I replicated the "issue". I said it installs in Program Files and I made a remark on an observation that the binary was also stored in AppData. I confirmed that software installed normally and correctly.

I just tested this on a fresh VM and TeamViewer is in Program Files and it seems TeamViewer also place a binary in your AppData, too, like you suggested.

Yesterday we updated in our catalogue and this update removed Adobe Digital Editions from the ConfigMgr Apps and Intune tabs - however this update is still supported as a WSUS/ConfigMgr software update. Yesterday we also improved the detection logic to cope with this nonsense by Adobe of updating their software but not the version number itself in the registry.

To receive this new detection logic, please republish the software update if you want it as a software update (I appreciate this post has been mostly discussing ConfigMgr Apps):

I'm not sure if you created this uservoice item or not, I believe you did, but if you didn't, please vote on this idea because I still believe we should be able to be more flexible in situations like this where vendors like Adobe completely deviate from 'standards':

To follow up regarding this exact issue: we will be removing the product from our catalogue from all tabs except the Updates tab, so you will still be able to create software update for it in WSUS/ConfigMgr - WSUS applicability rules gives us greater flexibility than our detection mechanisms do for Intune Apps/Updates and ConfigMgr Apps.

With that said, we won't be able to correct the detection for this product as a software update until the next update of the Publisher as we identified a bug while trying to publish updates to WSUS with custom success exit codes - this product exits with exit code 1223 and we need to configure WSUS to interpret that as a success.

Thanks - that make sense as the issue is with constant revision of the ConfigMgr App and not the software update in WSUS.

I've received what you sent, thanks for that. Hopefully I can follow up with you later today about what the issue might be or next steps.

Hey NenNewbie,

May you share PatchMyPC.log? It would also be good to get a copy of Package.xml from the source directory of XMind 8 Update 9 (3.7.9). Feel free to send these to [email protected] if you do not want to share these publicly on the forum.

Hi, this is now resolved - the vendor changed the display name format in the registry and we had to update the detection rules to account for this.

Hey Jared

The pre-scripts will run after managing conflicting processes functions.

Kofax has only ever been offered as an update, not as an application.

Unfortunately there's not enough information to go on here to troubleshoot. What platform is this for? Are the updates deployed? If so, could you share the below log files?

SCCM client log files:

%WinDir%\CCM\Logs\PatchMyPC-ScriptRunner.log (If exist)
You need to run Get-WindowsUpdateLog on Windows 8.1 and newer in PowerShell.

Intune client log files:


Hey all, I am seeing the same issue. it is same in the environment. I think I will have to submit a ticket but I don't think this will be resolved soon. Please can anyone let me know whether they got any response from the tickets they have created or should create a ticket.

Can you check the following key in the registry and let me know its value: "HKLM:\SOFTWARE\Dell\UpdateService\Clients\CommandUpdate\Preferences\Settings\AppCode"

There are 3 different versions of Dell Command Update a "Modern", "Classic" and "Universal". We only update the classic version at this time.

We recently improved detection of our app for the Dell Command Update to only evaluate as applicable for classical installs, not modern or universal. To receive this new improvement to applicability/detection, please delete the Dell Command Update in Intune or republish it in WSUS/SCCM, and re-sync to recreate with these new improvements.

We do intend to add support for the UWP modern / universal apps soon. If you have modern/universal install and would like us to support this type of Dell Command Update, kindly add votes to this uservoice to increase its attention for us: UWP Dell command update | Patch My PC Feature and Application Request

I think you should be clear of the issue if you use purely Win32 apps, regardless of whether they're .exe's or .msi's.

Hi Jack

From reading Microsoft docs on this issue, it does sound like mixing LOB and Win32 can cause issues during Autopilot:

We updated the applicability rules again today, please ensure you republish ASAP as there was a mistake in the logic causing Nextcloud update to be installed, even if the device did not have Nextcloud previously installed.

Pages: [1] 2 3 4 5