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

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)

#1
Yes, this Rev 1 update contains improved detection logic. Moving forward, it is recommended you consider using the Patch My PC Publisher software.
#2
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.
#3
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?
#4
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.
#5
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.
#6
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.)
#7
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.
#8
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.
#9
I don't think that's the issue, but let me know what you find.
#10
Is it possible one user has Postman installed, but the other user on the device doesn't? That would explain this behaviour. Detection is fine.
#11
Would you say you're seeing this on devices where there might be more than one user profile on the machine? Postman is a user-based app so the detection/requirement scripts would loop HKCU, which is only loaded for the currently logged on user.
#12
We have updated our monitoring to ensure this shouldn't happen again, and we also added the update to our catalogue last night. If you haven't already, kindly sync the Publisher to get the update. Thank you for letting us know about this!
#13
Yes, I'm sorry I forgot to reply here. Thanks for notifying us.
#14
Hey ekraus,
Yes I can see this was on our radar in monitoring/alerting since the tail end of last week. I'm unsure why it's not yet in the catalogue. I will investigate.
#15
I just installed Postman for both ConfigMgr and Intune and it detected fine. May you share more details about what you think is specifically wrong with the detection?