Skip to main content

We are having some smart/not so smart group issues. Currently, we have MS Teams updated to version 1.00.23961 on a few machines within our environment.



Smart group settings are as follows:





The machines with most updated version are still in the group even though we've ran an updated inventory or Jamf Recon.



Any help would be appreciated.

Going into your inventory page and changing the search to application, what comes back for your Teams app? Is the computer group in the same Site as the computers?


@mack525 , I would normally use Extension Attributes for things like this. Try creating a smart group from this, and see if you have better results



#!/bin/bash

###############################################################################################
# Extension Attribute checks to display Microsoft Teams Version with Release number #
# Uses CFBundleShortVersionString because this is the "release version number of the bundle #
###############################################################################################

#Set the variables
applicationPath="/Applications/Microsoft Teams.app"
CurrentVersion="1.00.23961"

#########################
# Define functions #
#########################

# Compare_versions function
# - has no restriction on number of parts in version string
# - can compare version strings with different number of parts
# Returns:
# 0 if versions are equal (btw: 1.2 == 1.2.0)
# 1 if the 1st version is bigger / newer
# 2 if the 2nd version is bigger / newer
compare_versions()
{
local v1=( $(echo "$1" | tr '.' ' ') )
local v2=( $(echo "$2" | tr '.' ' ') )
local len="$(max "${#v1
  • }" "${#v2
  • }")"
    for ((i=0; i<len; i++))
    do
    [ "${v1[i]:-0}" -gt "${v2[i]:-0}" ] && return 1
    [ "${v1[i]:-0}" -lt "${v2[i]:-0}" ] && return 2
    done
    return 0
    }

    # Used by compare version function
    max()
    {
    local m="$1"
    for n in "$@"
    do
    [ "$n" -gt "$m" ] && m="$n"
    done
    echo "$m"
    }

    #########################################
    # Check application and version #
    #########################################
    if [ -d "$applicationPath" ]; then
    appVersion=$(mdls -raw -name kMDItemVersion "$applicationPath")
    if [ $appVersion = "(null)" ]; then
    appVersion=$(defaults read "${applicationPath}"/Contents/Info.plist CFBundleShortVersionString)
    fi
    compare_versions $appVersion $CurrentVersion
    versionState=$?
    if [ $versionState = 0 ]; then
    RESULT="Current-$appVersion"
    else
    if [ $versionState = 1 ]; then
    RESULT="Newer-$appVersion"
    else
    if [ $versionState = 2 ]; then
    RESULT="Older-$appVersion"
    fi
    fi
    fi
    else
    RESULT="Not Installed"
    fi

    echo "<result>$RESULT</result>"'

  • There really is no outdated version of the Teams app, the app updates itself when it is started (it is the same with OneDrive standalone). The problem is actually that the update process does not change the Info.plist file, just the electron app contents. Therefore, Jamf Pro cannot see the correct version. My version is listed as 1.00.21761 in Finder (and per Extension attributte), but the app itself reports that it is 1.2.00.1761. So there seems to be no way to figure out the correct version from Jamf, but since it auto-updates without user interaction we just check that it is installed.


    @swhps This is what i get




    @JustDeWon We normally use Extension Attributes as well but i could not find anything for MS Teams. It's clear i was not searching hard enough. Thank you sir! i will definitely give it a try.


    @eirikw ahh yes, I did notice that it updates on its own. I just wanted to figure out who has the latest and if needed, push out an updated version.


    looks like the reported version # does not have the . in them from that result. Perhaps try the smart group with out the . and see if it responds better?


    @mack525 You're welcome. Hopefully it helps.


    @swhps It most certainly responded 🙂 Appreciate the guidance.


    @mack525 glad to hear. Now lets hope the location were the version is detected does not put the . back in with a future update.


    Reply