Messages

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.)

I 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.

So 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.

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.

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.

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!

Yes, I'm sorry I forgot to reply here. Thanks for notifying us.

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.

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?

Hey JImmy_O,

May you fire an email to [email protected] and include "FAO Adam" in the subject? I have some queries regarding testing this update I'm hoping you can help answer.

Hi pmptrad,

I'm following up from Scott's reply.

Pulse Connect Secure (x86) is no longer in our catalogue. The software was bought and rebranded by Ivanti. At this time, the successor we have in our catalogue is Ivanti Secure Access Client, however, this software is only available in our catalogue as x64 and not x86.

Do you need x86? x64 is generally preferred in nearly all circumstances for our customers.

Can you send us some logs via the support portal so we can look through them to get the bigger picture and help you? You can upload them here https://patchmypc.com/technical-support

We will need the following please:-

Server
%PatchMyPCInstallDirectory%\PatchMyPC.log
%PatchMyPCInstallDirectory%\PatchMyPC*.lo_
%PatchMyPCInstallDirectory%\Settings.xml

Affected Client
%WinDir%\CCM\Logs\AppDiscovery*.log
%WinDir%\CCM\Logs\AppEnforce*.log
%WinDir%\CCM\Logs\AppIntentEval*.log
%WinDir%\CCM\Logs\CAS*.log
%WinDir%\CCM\Logs\CIAgent.*log
%WinDir%\CCM\Logs\DataTransferService*.log

Yeah, we originally added DDM 2.x to the catalogue where it would uninstall 1.x. However we found supporting documentation that Dell suggests DDM v1 and v2 are independent and v2 isn't always the best option for some monitors. Therefore we added it as a separate product and fence of detection/applicability between the major versions.

Word of mouth suggests Dell are releasing an update for DDM 2.x next month to include a newer version of .NET.