Messages

I have added the pre-script and deployed it to a system with the MSI install of VLC 3.0.20.0 and the app deployment is showing 3.0.21 as installed, but the installed version is still the MSI version 3.0.20.0. Should it not see the 3.0.20, uninstall MSI, and install EXE, because it's not.

Was the script added to the EXE variant and the application re-published? Also check the ScriptRunner log to verify that the script actually ran.

Yes that's right - sorry about the confusion, we'll get that corrected.

It does state:

"The script is intended to be used a pre-script for the latest EXE variant of VLC Media Player. It will silently uninstall the MSI variant of VLC Media Player."

But then confuses matters by talking about applying it to the MSI.

We also need to get VLC updated to satisfy our security audits.

Is there a reason why setting the MSI installer to uninstall for all devices, and then setting the exe to install for all devices wouldn't work?

It would be better to use supersedence or an uninstallation pre-script here, in case the EXE installs first, then the MSI gets removed after, as that could result in a broken installation.

Also, we have now added a script to our GitHub to remove the MSI version. This can be added as a pre-install script to the Patch My PC package for the EXE variant:

https://github.com/PatchMyPCTeam/Community-Scripts/tree/main/Uninstall/Pre-Uninstall/Uninstall%20VLC%20Media%20Player%20MSI

Yes that would also work, with a few caveats:

- With ConfigMgr, the latest Application would resolve as being installed even if it was installed manually outside of ConfigMgr. Using supersedence here would work, and the option should be selected to uninstall the superseded product. You should also be able to set the EXE deployment settings to automatically upgrade any superseded products.

- Intune will not automatically evaluate the detection script of every available app to determine if it's installed, unless installation has been attempted at least once. Therefore you should supersede both the Application and Update - and if somebody installed it manually themselves, the published apps won't be recognised as installed, and so the supersedence rule may not apply.

No, you would not want to launch the processes directly as System, I was suggesting you call the Outlook/Teams exe directly with Execute-ProcessAsUser. But I can appreciate your method allows you to not have to supply the full path to the exe.

PSADT's Execute-Process supports -UseShellExecute $true, which will allow you to run outlook/ms-teams with just the name - but unfortunately Execute-ProcessAsUser does not support this setting!

I'm not sure what would be different as a result of using a custom app, but I don't see a need to execute PowerShell here as the user when you could just start the Outlook/Teams exe directly? Also there should be no need to add a -Wait there.

If your Publisher is trying to download an older version than 7.0.0, then something's not quite right - please could you open a support case via https://patchmypc.com/technical-support?

[DuoDesktop-7.0.0.msi]

https://dl.duosecurity.com/DuoDesktop-latest.msi is still returning DuoDesktop-7.0.0.msi with a SHA1 of 1938379ef543367c892b8e7cca84fd3274e862c2 here, which matches the one in our catalog.

Are you seeing a different file with a manual download of the same URL?

PMPC custom apps can be an alternative to using PSADT + ServiceUI to prompt the user to close running apps. You would not need to combine both, but you could of course upload a PSADT script purely for its installation logic - I would not try to mix and match UI elements from both.

Also, if just using PSADT + ServiceUI, PSADT now has an example launcher script that solves the original problem you describe (where running serviceui.exe with no users logged on results in an error):

https://github.com/PSAppDeployToolkit/PSAppDeployToolkit/tree/main/Examples/ServiceUI

I will discuss this internally - but normally we only configure updates to be able to detect and migrate from a different package type (e.g. EXE->MSI or x86->x64) when the vendor just offers a single installer type and they changed it.

There are a few options at your disposal to migrate users over - for example you can create a pre-script that will allow the EXE variant to uninstall the MSI (this script can help), then push this out to a collection of all devices that have the MSI variant installed.

We are going to add this property to the uninstall command, it should be changed in today's catalog update.

You can also overcome this issue by allowing PatchMyPC to prompt the user to close Outlook instead by managing conflicting processes.

We will review this and add it to the standard uninstall arguments if found to resolve the issue.

There is another post here where the developers have stated they ran into issues but still intend to get an MSI working:

https://code.videolan.org/videolan/vlc/-/issues/28677

It may be that your MST is applying successfully, but updating the ProductLanguage of the MSI is simply having no effect. There does not appear to be anything within the MSI setup to take advantage of this property.

Since you are already comfortable making an MST, your best option is to use Master Packager (the free version will do) to create an action to apply HKCU to all users:

https://www.masterpackager.com/master-packager

The catalog apps will only work with files that match the hashes:

Product: TeamViewer Latest (MSI-x64)
Version: 15.54.6.0
URL: https://dl.teamviewer.com/download/version_15x/TeamViewer_MSI64.zip
FileName: TeamViewer_Full.msi
SHA1: 5f71b9fbd1a0f22e4ec1df9bcf037f263bd0cd1f
SHA256: 25ea46e19981a7e3dad88dd8d2c9a5f245f9a056239521dd656e708641711e7a

Product: TeamViewer Latest (MSI-x86)
Version: 15.54.6.0
URL: https://dl.teamviewer.com/download/version_15x/TeamViewer_MSI32.zip
FileName: TeamViewer_Full.msi
SHA1: 0c2f9bfb025a00919a980b5d7f84064f6b8f5026
SHA256: e438e4345a9656bd19bc1893a2689c66543c1dbbb5d550c1815a70b252292641

If you are customising the MSI in the portal, then does it supply you with a self-contained MSI, or an MST file? I cannot test myself without the appropriate license.

If it generates you a custom MSI, with a new hash value, then your only option would be to deploy this via Custom Apps. You would then have to manually upload each new version however.

If it generates an MST, or some other config file that can be placed next to the same base MSI - then this could be added along with a custom command line to the base catalog app. However this feature is only currently supported in the Patch My PC Publisher and is not yet available in the new cloud portal.