It's frustrating the installer _reinstalls_ if the same version is already installed. Most installers just bail if it detects the same version is installed. That coupled, with our broken detection logic when we mislabelled .55, is what has caused the issue.
Definitely reach out to [email protected] and indicate you're impacted by this. It'll be an easier means for us to update you with progress with our remediation actions.
We released .55 on Sunday, but it was mislabelled, it should have been .52. Therefore we rereleased it with .52 on Monday.
This sequence of events causes the installer to initiate a reinstall. If software is running which depends on webview2, the reinstall would fail and leave webview2 in a partially installed state. This in turn leaves other software that depends on webview2 in a broken state.
We have repro steps but still trying to work out the best way to coordinate remediation actions for customers.
Hi Mark, may you share the below logs please? Feel free to email to [email protected] and we can
C:\Windows\temp\msedge_installer.log %WinDir%\CCM\Logs\CAS*.log %WinDir%\CCM\Logs\DeltaDownload*.log %WinDir%\CCM\Logs\DataTransferService*.log %WinDir%\CCM\Logs\PatchMyPC-ScriptRunner.log (If exist) This may be found in the %ProgramData%\PatchMyPC\ if the Install was initiated by the user from Software Center. %WinDir%\CCM\Logs\ScanAgent*.log %WinDir%\CCM\Logs\StateMessage.log %WinDir%\CCM\Logs\UpdatesDeployment*.log %WinDir%\CCM\Logs\UpdatesHandler*.log %WinDir%\CCM\Logs\UpdatesStore*.log %WinDir%\CCM\Logs\WUAHandler*.log %WinDir%\WindowsUpdate.log You need to run Get-WindowsUpdateLog on Windows 8.1 and newer in PowerShell. %ProgramData%\PatchMyPC\PatchMyPC-UserNotification.log %ProgramData%\PatchMyPC\UISettings\UINotificationSettings.xml
Your post did spark a conversation internally about supporting MSI detection to look at DisplayName and DisplayVersion, and not just the product code.
Today, if a product in our catalogue is an .msi, we default to always looking for the product code.
Since the Teams installer product code doesn't change, this is largely the reason I believe we don't support it as an update.
However, hopefully if can we add support for MSIs to check DisplayVersion, then we might be able to better support this product as an update. I know a couple of installers in our catalogue behave like Microsoft Teams.
Unfortunately I can not provide an ETA or even if we will do this.
I agree with your sentiment, though, that Microsoft recommendations are sometimes a million miles away from reality. This I think is one of them. Beyond the installer using the same product code, I can't think of any reason why anybody _wouldn't_ or _shouldn't_ patch the system-wide install of it.
I think I've seen instances before where if the Teams client is so old, it won't start. I think if it's so old, it can't update either due to the same check. A real chicken and egg problem. I'm not sure if this is a problem in the latest versions, maybe they fixed it, but I've definitely seen it before. Maybe a year ago.
Patch My PC utilizes the Machine-Wide installer for Microsoft Teams. The Machine-Wide installer uses the same MSI Product Code for all versions. This causes multiple issues concerning updates to the product as well as detection of new versions. Microsoft does not recommend updating the Teams MSI once installed (Microsoft Docs)
This will be in today's catalogue release. I appreciate your patience here.
We added a pre-script to remove 1.x if it exists and also updated the icon.
As an FYI, the new Dell Display Manager 2 has a dependency on .NET Core Desktop Runtime version 5. When you install it, and this isn't installed, the user is prompted to download and install it (see attached). Clicking 'yes' takes the user to this link to download.
The installer does not have any option to suppress this dialogue to the user if .NET Core Desktop Runtime is not installed. It also does not have an option to automatically install the dependency, either. I recommend you install .NET Core Desktop Runtime 5 before deploying this update of Dell Display Manager v2 to avoid this confusion for users.
To verify I understand the request correctly, the request is to make Adobe Acrobat Reader DC evaluate as installed if the superior Adobe Acrobat Pro is installed?
Hmm. I can understand both sides.
To implement such detection into the Adobe Acrobat Reader DC would break convention in our catalogue; we install an app, and detect if _that_ software is installed - this is the premise for all products in our catalogue. This suggestion is to support an alternative logic of: install an app, but if it a superior edition of the same software is installed, return as detected.
That is the correct procedure, yes. Or, you can delete the Application in-console, and the source folder, and re-sync to recreate it which should pull down the script into the package. This is a result of a bug in the Publisher that can't add Patch My PC Recommend or Defined scripts after the fact the product has been added to the catalogue.
This was fixed in 188.8.131.52. However, unfortunately a republish doesn't work either so I've raised another bug report internally to fix this.