Messages

[Modify command line]

Hi, 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"

Hello

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:

• Modify command line
• Add custom pre/post scripts

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

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.