Posted on 02-25-2019 01:00 PM
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.
Posted on 02-25-2019 02:21 PM
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?
Posted on 02-25-2019 05:08 PM
@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>"'
Posted on 02-26-2019 02:45 AM
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.
Posted on 02-26-2019 07:20 AM
@swhps This is what i get
Posted on 02-26-2019 07:22 AM
@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.
Posted on 02-26-2019 07:25 AM
@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.
Posted on 02-26-2019 07:26 AM
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?
Posted on 02-26-2019 07:27 AM
@mack525 You're welcome. Hopefully it helps.
Posted on 02-26-2019 07:35 AM
@swhps It most certainly responded :) Appreciate the guidance.
Posted on 02-26-2019 10:57 AM
@mack525 glad to hear. Now lets hope the location were the version is detected does not put the . back in with a future update.