Messages

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.

[every]

There are a few ways to go about this - some of these examples can be made easier by using PSAppDeployToolkit / PSADT.

- Run the uninstall as the logged in user - if you're in System account context, this can be launched in as the user by leveraging Scheduled Tasks. PSADT has an Execute-ProcessAsUser function to make this easy. If the uninstall process needs admin rights though, users may get a UAC prompt unless you have a privilege management system in place to auto-elevate certain processes.

- Set up a Run key or Active Setup to run the uninstall per user. Can be used in conjunction with the above to cater for users not logged on during deployment. PSADT has a function Set-ActiveSetup that can be used to set this up, and it will also automatically trigger it to run as the logged in user much like the above.

- Surgical mop-up of files/reg for every user - for this you will need to know every file, folder, shortcut and reg key that needs to be removed. PowerShell's Remove-Item accepts wildcards (e.g. Remove-Item -Path 'C: \Users\*\AppData\Local\AppName' -Recurse -Force). Registry is harder is it required mounting each user registry hive - again PSADT can help here with the Invoke-HKCURegistrySettingsForAllUsers function.

We are monitoring their site for a new MSI:
https://get.videolan.org/vlc/3.0.21/win64/

Here is a thread on the vendor forum about it that is now locked:
https://forum.videolan.org/viewtopic.php?t=164735

Their MSI was problematic due to being compiled on Linux rather than Windows, so they may have run into some build issues:
https://code.videolan.org/videolan/vlc/-/issues/18985

If we decide to pull this from our catalog, we can add a pre-script to the EXE release to remove the MSI version.

Thankyou for pointing this out, we'll revert this change - it was only supposed to be applied to the .MSI variants.

FYI they have stopped serving up the latest MSI packages on these URLs:

https://downloads.poly.com/headsets/PlantronicsHubInstaller_x86.msi
https://downloads.poly.com/headsets/PlantronicsHubInstaller_x64.msi

Those versions are now out of date (3.25.54065.37203) whereas the EXE version is 3.25.54307.37251:

https://downloads.poly.com/headsets/PlantronicsHubInstaller.exe

According to this forum post, they are now expecting customers to get the latest MSIs from the portal:
https://h30434.www3.hp.com/t5/Poly-Software/Plantronics-Hub-x64-msi-installer/td-p/9070652

However both the links posted there, as well as the URLs that the built-in auto updater grabs from the API, point to .zip files, which Patch My PC doesn't yet support extraction of, hence the requirement for the local content repo!

I have done some further testing around this - if the original source MSI (where it was installed from) and the cached MSI (from C:\Windows\Installer) are no longer available, then trying to uninstall it with just the filename will not work and you'll get a 1612 error.

I have just found a much simpler way, which is to add REINSTALLMODE=v to the command line when uninstalling. Any of these will recache the MSI:

msiexec /i app.msi /qn REINSTALLMODE=v
msiexec /fv app.msi /qn

Or you can also add it to the uninstall:

msiexec /x app.msi /qn REINSTALLMODE=v


If you are using PSADT, then you can run:

Execute-MSI -Action Install -Path 'app.msi' -SkipMSIAlreadyInstalledCheck -AddParameters 'REINSTALLMODE=v'
Execute-MSI -Action Repair -Path 'app.msi' -RepairFromSource $true
Execute-MSI -Action Uninstall -Path 'app.msi' -AddParameters 'REINSTALLMODE=v'

There is a HKCU equivalent of that key also in case it was a per-user MSI:

HKEY_CURRENT_USER\Software\Microsoft\Installer\Products

Windows Installer also caches MSIs under C:\Windows\Installer with a random filename, check out the LocalPackage value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\$CompressedGuid\InstallProperties.

If all else fails and you need to take the nuclear option to remove the record of an MSI from the system (which may leave some of its contents behind), there is MsiZap.exe from Microsoft; and there is a community PSADT extension for it here:

https://discourse.psappdeploytoolkit.com/t/psadt-msizap-extension/4431

Although I should point out this extension replaces an existing toolkit function Execute-Msi, which is not good practice.

Furthermore; it looks like you were getting an error uninstalling an MSI because Windows Installer was looking for the cached MSI in order to perform the uninstall. So it wasn't a matter of where the PSADT Remove-MsiApplications function was looking for the MSI, it's more that Windows Installer itself was looking for it. When this happens, you can update the sourcelist for the app as above.

[$ProductCode = (Get-InstalledApplication -Name 'Acrobat').ProductCode]

Hi,

Firstly, if this is an SCCM application, then SCCM has native functionality to manage the sourcelist; just browse to the MSI file via the bottom of the Programs tab of the Deployment Type properties. The Patch My PC Publisher does not fill this in, which is something I will raise.

If you want to add/replace the SourceList via PSADT though, there is a community extension for it here that you might find useful:

https://discourse.psappdeploytoolkit.com/t/msi-sourcelist-and-psadt/879

Otherwise, for a more manual approach using the registry, you can get the ProductCode of an MSI application via PSADT (which looks at the uninstall keys like HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall):

$ProductCode = (Get-InstalledApplication -Name 'Acrobat').ProductCode

Or native PowerShell:

$ProductCode = (Get-Package -Provider MSI | Where Name -match 'Acrobat').FastPackageReference

Then you will need to convert that GUID to a new format:

$CompressedGuid = -join (($ProductCode | Select-String -Pattern '^\{?(.{8})-(.{4})-(.{4})-(.{2})(.{2})-(.{2})(.{2})(.{2})(.{2})(.{2})(.{2})\}?$' -AllMatches).Matches.Groups[1..11].Value | ForEach-Object { $CharArray = $_.ToCharArray(); [System.Array]::Reverse($CharArray); -join $CharArray })

Then you can look up the reg key "HKLM\SOFTWARE\Classes\Installer\Products\$CompressedGuid\SourceList".

There is a script in our community scripts repo that handles the user group:

https://github.com/PatchMyPCTeam/Community-Scripts/tree/567278ecbeac16dab77282a89dc5db5e20a55027/Install/Post-Install/Docker%20Users%20Local%20Group

As for WSL, perhaps try a pre-script to run "wsl --install"?

https://learn.microsoft.com/en-us/windows/wsl/install

Hi - the parameters you supply will be appended to the default parameters that we supply (install --quiet), so you just need to add:

--accept-license --backend=hyper-v

Per-user MSIs are problematic for us at this point in time. Our custom apps functionality will look for the Uninstall key under HKCU for a per-user app (which is where setup.exes will write to), however per-user MSIs still register themselves under the HKLM Uninstall key (along with a per-user entry under HKCU\Software\Microsoft\Installer\Products).

However, our detection rules are Powershell scripts built by rules that will look for the display name under the HKLM Uninstall key for per-system apps and the HKCU Uninstall key for per-user apps.

This is something we are looking to improve upon, although unfortunately I can't give you a timeline right now.



My recommendation would be to try and resolve the issues that make it fail when running it as a per-system installation. There are a few ways to solve the issues you mentioned:

- Intune cache: If you copy the MSI to a location such as C:\ProgramData\PackageCache\{GUID} before installing it, it will be cached. Don't forget to remove the folder upon uninstall. PSAppDeployToolkit has native functions for this - Copy-ContentToCache and Remove-ContentFromCache.

- You can also avoid the whole MSI self-heal scenario by pre-supplying what it is looking for. It is usually a HKCU registry marker, but the repair could be being utilised to supply user files also. Again PSAppDeployToolkit has native functions (Copy-FileToUserProfiles and Invoke-HKCURegistrySettingsForAllUsers) to make this easy.

Using PSADT within Custom Apps is currently not a great experience however due to the fact a workaround is needed to add folder content:

https://docs.patchmypc.com/installation-guides/patch-my-pc-cloud/custom-apps/helpful-hints#workaround-for-applications-that-require-folders-to-be-uploaded

There is another simple solution however, and that is to use Master Packager to create an MST file that uses their predefined custom actions to provide the user files and registry:

https://www.masterpackager.com/support/predefined-custom-actions



What is the app in question? If it's not already listed, add an entry under https://ideas.patchmypc.com!