microsoft / teamsmsioverride Goto Github PK

The function GetInstallBitness in CheckMSIOverride.ps1 does not return Bitness if it is found.
The only return Value is $false in case of an error.

Due to this PowerShell 5.1 bug (which is not going to be fix/backported from 7) should the download lines utilizing Invoke-WebRequest be changed to either set $ProgressPreference = 'SilentlyContinue' or the following .NET web client instead?

$wc = New-Object System.Net.WebClient; $wc.DownloadFile("https://github.com/dotnet/corefx/archive/master.zip", "C:\Users\crispop\Desktop\master.zip") }

I'm having an issue with the path being null. I can confirm the client has Powershell 5.1

AllowMsiOverride policy is set to True
Current Teams Machine-Wide Installer version is 1.3.00.4461
Target Teams Machine-Wide Installer version is 1.4.00.26376
Using 32-bit MSI
This will be an override update
Join-Path : Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'ChildPath'. Specified
Copying .\\1.4.00.26376\Teams_windows.msi to ...method is not supported.
At C:\Windows\ccmcache\14n\CheckMsiOverride.ps1:514 char:30

+ $toMsi = Join-Path $TempPath $msiName
+                              ~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Join-Path], ParameterBinding
Exception
    + FullyQualifiedErrorId : CannotConvertArgument,Microsoft.PowerShell.Command
s.JoinPathCommand

New-Item : Cannot bind argument to parameter 'Path' because it is null.
At C:\Windows\ccmcache\14n\CheckMsiOverride.ps1:516 char:31
+ New-Item -ItemType File -Path $toMsi -Force | Out-Null
+                               ~~~~~~
    + CategoryInfo          : InvalidData: (:) [New-Item], ParameterBindingValid
ationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Mic
rosoft.PowerShell.Commands.NewItemComm
   and

About to perform deployment using this msiexec command:
 msiexec.exe /fav "" /quiet ALLUSERS=1 /l*v C:\WINDOWS\TEMP\msiOverrideCheck_msi
exec.log
ERROR: MsiExec failed with exit code 1619

Here's what the TeamsMsiOverrideTrace.txt shows:

Start Trace 10/20/2021 14:32:23
Script Version 1.0.2108.0604
Parameters AllowInstallOvertopExisting: False, OverwritePolicyKey: False
Environment IsSystemAccount: True, IsOS64Bit: True
Removing temp folder C:\WINDOWS\TEMP\TeamsMsiOverrideCheck
The policy key AllowMsiOverride is not set, setting HKLM:\Software\Policies\Microsoft\Office\16.0\Teams\AllowMsiOverride to 1...
AllowMsiOverride policy is set to True
Current Teams Machine-Wide Installer version is 1.3.00.4461
Target Teams Machine-Wide Installer version is 1.4.00.26376
UninstallReg1: {39AF0813-FA7B-4860-ADBE-93B9B214B914} {731F6BAA-A986-45A4-8936-7C3AAAAA760B}
UninstallReg2: {39AF0813-FA7B-4860-ADBE-93B9B214B914} {731F6BAA-A986-45A4-8936-7C3AAAAA760B}
ProductsRegLM: 3180FA93B7AF0684DAEB399B2B419B41 AAB6F137689A4A549863C7A3AAAA67B0
ProductsRegCU: 
PackageName: Teams.msi Teams_windows_x64.msi
Using 32-bit MSI
This will be an override update
Copying .\\1.4.00.26376\Teams_windows.msi to ...
About to perform deployment using this msiexec command:
 msiexec.exe /fav "" /quiet ALLUSERS=1 /l*v C:\WINDOWS\TEMP\msiOverrideCheck_msiexec.log
ERROR: MsiExec failed with exit code 1619
Removing temp folder C:\WINDOWS\TEMP\TeamsMsiOverrideCheck
End Trace 10/20/2021 14:32:25

With the EOL of IE and many companies disabling it, it's best to add the -UseBasicParsing flag on the Invoke-WebRequest calls so that they don't fail.

The function GetInstallBitness does not return Bitness if it is found.
The only return Value is $false in case of an error.

How to update the the Teams Machine-Wide Installer but not trigger any updates for per-user instances of Teams?

Hello:

I am trying to update the Teams wide installer with the script. I am using the following command:

Powershell.exe .\CheckMsiOverride.ps1 -Type Package -OverrideVersion 1.5.00.17656 -AllowInstallOverTopExisting -FixRunKey -OverwritePolicyKey -Uninstall32Bit

The issue I am seeing is machines where multiple users log into (profiles already cached and created) when a user logs in immediately after update, no issue. When a 2nd user logs in, that user is reporting teams is missing and its not auto installing. Wondering if anyone else has seen this issue before. Thanks

TeamsMSIOverride log below:

Start Trace 08/03/2022 22:47:09
Script Version 1.0.2110.2101
Parameters Type: Package, PreviewRing: False, BaseShare: , OverrideVersion: 1.5.00.17656, MsiFileName: , AllowInstallOvertopExisting: True, OverwritePolicyKey: False, FixRunKey: True
Environment IsSystemAccount: True, IsOS64Bit: True
Removing temp folder C:\WINDOWS\TEMP\TeamsMsiOverrideCheck
The policy key AllowMsiOverride is not set, setting HKLM:\Software\Policies\Microsoft\Office\16.0\Teams\AllowMsiOverride to 1...
AllowMsiOverride policy is set to True
ProductsRegLM: 3180FA93B7AF0684DAEB399B2B419B41 AAB6F137689A4A549863C7A3AAAA67B0
ProductsRegCU:
About to uninstall 32-bit MSI using this msiexec command:
msiexec.exe /X {39AF0813-FA7B-4860-ADBE-93B9B214B914} /quiet /lv C:\WINDOWS\TEMP\msiOverrideCheck_msiexecUninstall.log
MsiExec completed successfully.
Teams Machine-Wide Installer was not found.
UninstallReg1: {731F6BAA-A986-45A4-8936-7C3AAAAA760B}
UninstallReg2:
ProductsRegLM: AAB6F137689A4A549863C7A3AAAA67B0
ProductsRegCU:
PackageName: Teams_windows_x64.msi
Using working directory to aquire the new MSI...
Working Directory: C:\WINDOWS\ccmcache\70
Using 64-bit MSI from working directory
Target Teams Machine-Wide Installer version is 1.5.00.17656
This will be an override update
Copying C:\WINDOWS\ccmcache\70\Teams_windows_x64.msi to C:\WINDOWS\TEMP\TeamsMsiOverrideCheck\Teams_windows_x64.msi...
About to perform deployment using this msiexec command:
msiexec.exe /fav "C:\WINDOWS\TEMP\TeamsMsiOverrideCheck\Teams_windows_x64.msi" /quiet ALLUSERS=1 /lv C:\WINDOWS\TEMP\msiOverrideCheck_msiexec.log
MsiExec completed successfully.
Rewriting the HKLM Run key with "C:\Program Files (x86)\Teams Installer\Teams.exe" --checkInstall --source=default
New Teams Machine Installer version is 1.5.00.17656
Deployment successful, installer is now at target version!
Removing temp folder C:\WINDOWS\TEMP\TeamsMsiOverrideCheck
End Trace 08/03/2022 22:47:13

Hello

The current script does not support the noAutoStart parameters.

I tried to edit the line https://github.com/microsoft/TeamsMsiOverride/blob/main/src/CheckMsiOverride.ps1#L859C54-L859C54 to
$msiExecArgs = "$msiExecFlags "$toMsi" /quiet OPTIONS='noAutoStart=true ALLUSERS=1' /l*v $env:TEMP\msiOverrideCheck_msiexec.log"
but this did not work as I expected. The file C:\Program Files (x86)\Teams Installer\setup.json was modified but noAutoStart was added two times.
{"noAutoStart":false,"'noAutoStart":"true"}

Fails partly on Powershell 7.2.1. Still all appears to work correctly though. Need to replace with New-WinEvent for both creation and writing it appears.

New-EventLog: C:\Users\user\OneDrive\Main\SoftwareMisc\TeamsMsiOverride\CheckMsiOverride.ps1:623
Line |
 623 |  New-EventLog -LogName Application -Source $EventLogSource -ErrorActio …
     |  ~~~~~~~~~~~~
     | The term 'New-EventLog' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a
     | path was included, verify that the path is correct and try again.

Write-EventLog: C:\Users\user\OneDrive\Main\SoftwareMisc\TeamsMsiOverride\CheckMsiOverride.ps1:814
Line |
 814 |      Write-EventLog -LogName Application -Source $EventLogSource -Cate …
     |      ~~~~~~~~~~~~~~
     | The term 'Write-EventLog' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a
     | path was included, verify that the path is correct and try again.

The Uninstall32Bit option only seems to work if the 64-bit version is also already installed. If I don't misunderstand, the function GetProductsKey only returns an array if both versions are installed?!

$productsKey = GetProductsKey
if($productsKey -is [array])
{
    # If switch is passed, uninstall the 32 bit MSI before we perform the upgrade on 64 bit.
    if($Uninstall32Bit)
    {

Could this be changed so that the script could be used to switch from 32-bit to 64-bit?

Sometimes when i run this i get error 1603. When running manually it seemingly runs fine. Sometimes running by GPO power shell script works fine. Only sometimes i get error 1603 in the log and its not able to upgrade it.

Any explanation? I have just been running it manually on those machines.

Is there a way to get this script to run via intune? It requires parameter so cannot use the “scripts” functionality.