Messages

Unable to reproduce any problem here in the lab with the latest version 213.4.4597 - Win10/Win11, SCCM/Intune all working, clean installs or upgrades (although the app was not signed in).

The application is relaunching post-install, we'll discuss internally to see if we should add /NOLAUNCH setting to the catalog command line.

Have you retried with the latest version 213.4.4597?

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