Skip to main content

We use Tenable.io for vulnerability scanning and it has flagged a number of Windows endpoints that have old versions of Teams installed. I was puzzled by this as Automox patches Teams, and it turns out that because we’re using the machine wide installer, the Teams application is being installed into the user’s Appdata directory. This will only get updated if the user logs in but we don’t regularly log in with some accounts.

I’ve read suggested fixes including:

  1. Create a GPO that deletes old accounts from the machines. This is problematic for us IT admins.
  2. Remove the machine wide installer so that Teams is not automatically installed when a user first logs in.

Has anyone found a way to resolve this using Automox? I’d be interested to learn how others have resolved this.

 

TIA

Good morning @sparrowhawk ! 

 

This is quite an interesting dilemma! I did some reading to brush up on the particulars of the Teams machine-wide installer behavior. While I don’t know that we can directly solve for keeping the user-level installs current, a potential remedy that occurs to me is through Worklets we could:

  1. Ascertain the version of the installed machine-wide Teams package
  2. Enumerate all users that have logged into the device and:
    • Discern the last time the account logged in
    • Identify the version of the user-level ( AppData-installed ) Teams package
  3. IF the user has not logged in for a certain amount of time ( e.g. 14-days ), AND IF the user-level Teams client is behind the machine-wide installer’s version THEN we uninstall the user-level Teams package for the non-compliant account.

 

While not a perfect solution, it should resolve orphaned/vulnerable Teams installations and clean up your reporting.

 

If this is something you’d like to dive further into, just let me know and we can cook up some Worklet scripts for this.

 

Hope this helps, and thanks for the question!

 

- Anthony M.

 


Hi Anthony, thanks very much for your reply. You’re right, this is a tricky one.

What you suggest sounds reasonable, but as you say, it’s not perfect. It does seem a bit inelegant to reinstall and uninstall Teams for infrequently used accounts e.g. admin accounts.

But then I’m not sure what the impact of moving away from the machine wide installer might be either.

I’m just discussing your proposal with my team and will let you know what we decide.

Thanks again!


As an additional point I didn’t touch on originally: we could also leverage the PreventInstallFromMsi registry value to prevent installation from the machine-wide package for things like dedicated “admin” accounts and similar.


Ah, that’s a great idea. Ok, then I’m interested in helping you put this Worklet together. Let me know what you need from me.

Cheers


Ah, that’s a great idea. Ok, then I’m interested in helping you put this Worklet together. Let me know what you need from me.

Cheers

 

I’m going to continue this thread over private message to facilitate a time to discuss more in-depth, if possible.

 

Look forward to getting this buttoned up!

 

- Anthony M.

 


Hi @AnthonyM-Automox , I can’t reply to your PM?

“This member can only receive messages from members they are following.”


Hi @AnthonyM-Automox , I can’t reply to your PM?

“This member can only receive messages from members they are following.”

Whoops, fixed!


Hi @AnthonyM-Automox 

Was a worklet for this eventually created?

thanks!


@sparrowhawk and @Sven_van_Dongen  That challenge came across my desk too. Right now my worklet is focused on a specific version that I’ve planned to update as the vulnerability scanners tell me about it.


I’m not fully through tuning this to perfection. Currently on my initial phase where I let the script below cleanup all the easy ones. For context that phase dropped my count from 352 devices down to 24. Now I’m at the part it’s time to break out the scalpel and find ways to button this up some :-)

 

There is a step to check if that process is running as to not disrupt a user legit on an older version. I’d be shocked if they where, but hey, user experience first right!

 

# Evaluation Code

eversion]$vulnver = "1.6.0.18681"
$uPaths = Get-ChildItem C:\Users\
foreach ($path in $uPaths)
{
$exe = "$($path.FullName)\AppData\Local\Microsoft\Teams\current\teams.exe"
IF(Test-Path $exe){
IF($ver -le $vulnver){
$i++
}
}
}
IF($i){exit 1}else{exit 0}

# Remediation Code

eversion]$vulnver = "1.6.0.18681"
$procs = (Get-Process ms-teams,teams -erroraction silentlycontinue).Path

function unInstallTeams($path) {
$clientInstaller = "$($path)\Update.exe"
try{
$process = Start-Process -FilePath "$clientInstaller" -ArgumentList "--uninstall /s" -PassThru -Wait -ErrorAction STOP
if ($process.ExitCode -notin 0,-1)
{
Write-Output "UnInstallation failed with exit code $($process.ExitCode)."
}
}catch{
Write-Output $_.Exception.Message
}
}

$actions = @()
$uPaths = Get-ChildItem C:\Users\
foreach ($path in $uPaths)
{

$exe = "$($path.FullName)\AppData\Local\Microsoft\Teams\current\teams.exe"

# See if path exists
IF(Test-Path $exe){

# Make sure teams.exe is not in use
IF($exe -notin $procs){

# Get current file version
/version]$ver = (Get-ChildItem $exe).VersionInfo.FileVersion

# If the version is outdated, add to actions obj
$actions += IF($ver -le $vulnver){
pscustomobject]@{
Path = $exe.Replace('current\teams.exe','')
Version = $ver.ToString()
'Vulnerable Version' = $vulnver.ToString()
}
}
}

}
}

# Remove teams where it was found not in use and vulnerable
foreach ($finding in $actions){
Write-Output "Uninstall $($finding.Path) || version $($finding.Version)"
unInstallTeams $($finding.Path)
}

 


@jack.smith Thanks Jack, we appreciate that. We’ll give that a go. 


Reply