Messages

I would try and reboot affected machines, if the update still fails to apply then try to manually install any MSI package to see if Windows Installer is working correctly.

The download from:

https://www.bentley.com/software/connection-client/

Has now been updated to match what's in their release notes:

https://bentleysystems.service-now.com/community?id=kb_article_view&sysparm_article=KB0018714

If the download link does not get updated on the next release, we'll be monitoring the release notes page so that we can contact their support once again.

Supersedence with ConfigMgr kicks in if the superseded app is detected as installed. But with Intune, supersedence only kicks in if the specific superseded app was actually installed via Intune.

Deploying the app as required to devices running VLC, or even meddling with the requirement script of the EXE update, along with a pre-script to remove the MSI is the alternative.

But a recent comment from the devs suggests that we'll have an MSI with the next release, so we're not removing it from the catalog just yet!

Article relocated here:
https://dangough.github.io/packageology/msi/fixing-vlcs-msi-package/

But we have no indication what their issues are in getting an MSI together for 3.0.21 or if this would help. Plus the script would need to be run on a Windows box, which seemingly they don't have or they'd just run WiX on there to build it in the first place!

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.