• Welcome to Support Forum: Get Support for Patch My PC Products and Services.

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.

Show posts Menu

Messages - Adam Cook (Patch My PC)

Quote from: Bram_MECM on May 17, 2024, 12:42:41 AMHi team,

Running through an OS Deployment review in my environment, I've noticed that the PMPC package for Ms edge MSI-X64 with the detection script version 3.5 didn't notice that msedge version 127.0.2478.109 is installed. The PMPC version that is being pushed atm is 127.0.2478.105.

The detection script might need a tweak.

May you share some logs?


Also share all of the smsts*.log files aswell. Feel free to upload to https://patchmypc.com/share for privacy, or email [email protected].
There is an ongoing issue with Adobe's CDN where the following URL downloads a different file in some parts of the world:


Analyzing the files downloaded in the US compared with the UK seems to suggest both files are identical, however, the non-US .msp file has an invalid digital signature.

They're both signed with the same code signing certificate by Adobe, so we don't believe there is cause for concern and it is likely a mistake in Adobe's release pipeline. It's unclear why the digital signature is invalid in the non-US file, however, in any case the SHA256 value is different between the two files.

As part of our security validation process built into the Patch My PC Publisher, all packages published must pass hash validation before publishing the package into your environment/tenant. As Adobe's CDN is distributing a different file globally, some customers may experience a failure publishing the product "Adobe Acrobat DC Continuous (x64)" with the below error in PatchMyPC.log, or email or webhook alerts:

QuoteThe hash of file downloaded is different than the file hash in our catalog. Hash errors happen when vendors release updates that aren't available in our catalog yet. This error should be resolved in the next catalog update. It could also have been induced by a firewall issue. Additional details:Hash from catalog [qQ6Ki1uw6vUAK6JNlZb3y30QrA0=] doesn't match downloaded update hash of [o7ffhYWlMXvpYoPklinPQbYLiMk=]

We have notified Adobe of the issue in a support thread on their forum a few releases back (it was related to a previous release, but they have the same issue again and again): Invalid digital signature on AcrobatDCx64Upd230082... - Adobe Community - 14457702 - kindly upvote, comment, or if you have the means to, escalate this thread to an Adobe contact.

In the meantime, you can work around this by downloading the correct AcrobatDCx64Upd2400220759.msp (with the valid digital signature) using the below link hosted on our OneDrive and publishing it using your local content repository. Please make sure you have the option enabled to "Check the local content repository for content files before attempting to download content files from the Internet."

Thank you. It looks like the hash of the .msi for Google Chrome's enterprise installer has changed, indicating a new version has been released. We will get this updated in the next catalogue release (more than likely today.)
Quote from: henrybullock on May 12, 2024, 10:47:59 PMHello, I want to remove my catalog products inside SCCM SUP settings. How can I do this?
Please guide me. Thanks in advance!

Hi henrybullock,

What exactly do you want to remove and why? A screenshot might help illustrate accurately what it is you want to remove.
    Quote from: PaulKlerkx on April 21, 2024, 10:44:08 PMHi, I am going through the initial setup of our PMPC apps. 
    I need to install SoapUI using the answer file method as we need to put the tutorials in a custom location. 

    Our current command line is "SoapUI-x64-5.7.0.exe -q -overwrite -varfile response.varfile" and the varfile contains the info instructing the tutorials to be redirected to another drive. 

    question is, how do I configure PMPC to target that varfile. 

    I'm guessing I drop it in a set / never changing network location and use the full path to it.  Is that how it is done or is there a different preferred method?  I have another app with a similar setup as well.  VSCode - requires this addition" /LOADINF="VSCode.inf"


    Using the Patch My PC Publisher you can add your own arguments and include additional files within the packages. I'll show you how to do this below. Once you include the .varfile file as an additional file, you'll just need to reference the file relatively as it will be in the same directory as the .exe itself when it is stored server -side (and also in the cache folder when downloaded by the client, too.)

    • Right-click on SoapUI in the Patch My PC Publisher
    • Choose Modify command line and enter: -overwrite -varfile response.varfile (note I have omitted the -q parameter as this is applied by default, in this window we're supplying additional custom parameters.)
    • Right-click on the product again and choose Add custom pre/post script
    • Within the Additional files section, browse out and choose your response.varfile and click OK
    • If this is for an Intune package, I recommend deleting the package in Intune and syncing the Patch My PC Publisher (via the Sync Schedule tab > Run Publishing Service Sync). For anything else (i.e. SCCM or WSUS), I recommend right-clicking on the product again, before synchronising, and select Republish during next sync schedule

    Here are a couple of useful reference articles relevant to my suggestions:

    I hope this helps![/list]
    Hi Julian,

    Thank you for making us aware of this. Have you contacted VMWare for support and notified them of a potential bug?
    Yes, this Rev 1 update contains improved detection logic. Moving forward, it is recommended you consider using the Patch My PC Publisher software.
    Out of curiosity, why are you using the in-console publishing? It's inferior with fewer customisation and automation benefits compared to the Patch My PC Publisher software.
    May you right click on the product in the Patch My PC Publisher, and choose the option to 'Recreate detection script' then sync the Patch My PC Publisher - once sync is complete, is the detection logic now correct?
    Hi ctqui6891

    Do you still see an application with the name "Google Chrome 119.0.6045.106 (x64)" in your environment? If so, kindly delete it and retry. From the log snippet, it looks like the source content folder was deleted but the object in console wasn't.
    We're currently not tracking any issues with Postman in our catalogue. May you reach out to us [email protected]? We will likely want to pick apart what you're seeing to understand more.
    Thanks, cdnk3v.

    We plan to support it by adjusting our detection scripts to ignore product code (when told to do so, for edge cases like this) and explicitly look at DisplayName and DisplayVersion (which is how EXE detection works.)
    Quote from: cdnk3v on September 05, 2023, 07:57:24 PMI really think there should be some way to maybe add a prestart script in the PMPC deployment for Teams to remove and older version... or just remove the current version regardless.

    The challenge with having an old version of the System-Wide Installer installed on a machine is any new user that logs in, will get that initial version, then when it launches, it will get an update (at some point).

    Security scan software will pick up the System-Wide Installer that is out of date, and need to have it updated.

    So if the PatchMyPC deployment of Teams did do a remove first then an install, that I think may solve the issue.

    I also thought that the deployment would remove and install (not upgrade) the latest version, as we still have version 1.5 on our workstations, so a technician may log into a desktop for the first time, and it will install version 1.5, then they log out and never to log back into that machine, security scan software will detect this as out of date, and need it remediated, which means we have to rip it out of peoples profiles.

    the PatchMyPC Teams installer would not solve that issue, but keeping the System-Wide Installer up to date may help a bit in those use case scenarios... the ones Microsoft doesn't bother thinking of or testing.

    The Teams installer functions like most machine-wide installers; it installs its bits in Program Files or ProgramData, and creates a Run key or a scheduled task (triggered via user logon.)

    As you've described in your post, when someone logs in, the user then gets Teams installed in their AppData (launched from the scheduled task). If the user doesn't login again, ever, then that AppData installation will never get updated and will show up on your security scans.

    Microsoft don't provide a user-based Teams installer to patch the AppData bits. Their software is driven by this machine-wide installation and Run key / scheduled task methodology.

    Quote from: cdnk3v on September 05, 2023, 07:57:24 PMSo I vote for PMPC to look into this as part of the Teams installer.

    As much as I would love to solve this problem with the user-based installations, we don't create third party software installers. Vendors of their own software do - in this case, Microsoft. We automate the 'packaging' of them into ConfigMgr/Intune/WSUS.

    On the topic of this thread (of being unable to make updates for Teams, and only base install apps), we have made good progress on adding support to detection scripts for software which do not change MSI product code with each update.
    Hi vbate, thank you for letting us know. I have fixed the monitoring to hopefully avoid this happening again. These updates will be in our next catalogue release later today.
    I don't think that's the issue, but let me know what you find.