Skip to main content
Solved

Outlook Profile Size EA

  • September 14, 2017
  • 5 replies
  • 17 views
S
Forum|alt.badge.img+9

I put this together and tested it, thought I would share. It should work, but I suspect it could use some refinement. Maybe others will find it useful.
We need to know the profile size of Outlook 2016. This EA will pull in the Outlook Profile size, in case you needed to know. 

currentUser=`who | grep console | awk '{print $1}' | grep -v -i '_mbsetupuser' `
result=`sudo du -shc /Users/$currentUser/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/`
echo "<result>$result</result>"

Best answer by mm2270

Unfortunately, du is kind of it for folder size calculation. I have also looked for better/faster tools to find directory sizes and there really isn't one that I can see. There might be some 3rd party custom binaries that can do it, but then that would involve deploying something to your Macs just to pull an EA value, which doesn't make a lot of sense.
I had hoped that things like Spotlight (mdls or mdfind) could see that info, but it doesn't capture it. You can't rely on ls either. It's not recommended to use it in scripts as the output can be unreliable.

What I might recommend is crafting and deploying a LaunchDaemon and companion script very much like what you have that would run every x hours. Instead of having it work as an EA, take the same data and pipe it into a local file or a plist of some sort. Then have your EA look for that file/plist and scan for the value. This will make your inventory collections much faster since it's just picking up a previously recorded value, and will still keep it relatively current if you have the LaunchDaemon run, say, once every 2 or 3 hours to update that locally stored info. The LD will run independently and automatically and therefore not be tied to machines checking in/running policies from Jamf Pro.

    5 replies

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • September 14, 2017

    Ok, sure, but you will greatly (and I mean greatly) lengthen the time of your inventory submissions. If you only ever have a single recon happening in a day, it might be fine, but if you have policies installing or configuring stuff a few times a day that also collect inventory, you're adding a lot of overhead to those inventory scans. du is a pig and can take several minutes to calculate directory sizes.

    Also keep in mind, inventory collection can happen when someone isn't logged into the Mac since it gets called by a LaunchDaemon. Your script looks for current user, but doesn't validate if the user it returned with is root or an actual logged in user. You could end up occasionally blanking out that EA value. Just something to keep in mind in case you planned on using it for Smart Group calculations.

    Lastly, if you insist on doing this, drop the sudo. It's not needed for EAs, or most anything else running from a Jamf Pro process.

    S
    Forum|alt.badge.img+9
    • steve_summers
    • Author
    • Valued Contributor
    • September 14, 2017

    Thanks @mm2270. These things are good to know. Didn't know that about du, is there another/better way to do this? If you wanted to know the size of a particular directory, how would you script it? I appreciate the assistance, might I add.

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • Answer
    • September 14, 2017

    Unfortunately, du is kind of it for folder size calculation. I have also looked for better/faster tools to find directory sizes and there really isn't one that I can see. There might be some 3rd party custom binaries that can do it, but then that would involve deploying something to your Macs just to pull an EA value, which doesn't make a lot of sense.
    I had hoped that things like Spotlight (mdls or mdfind) could see that info, but it doesn't capture it. You can't rely on ls either. It's not recommended to use it in scripts as the output can be unreliable.

    What I might recommend is crafting and deploying a LaunchDaemon and companion script very much like what you have that would run every x hours. Instead of having it work as an EA, take the same data and pipe it into a local file or a plist of some sort. Then have your EA look for that file/plist and scan for the value. This will make your inventory collections much faster since it's just picking up a previously recorded value, and will still keep it relatively current if you have the LaunchDaemon run, say, once every 2 or 3 hours to update that locally stored info. The LD will run independently and automatically and therefore not be tied to machines checking in/running policies from Jamf Pro.

    jhbush
    Forum|alt.badge.img+27
    • jhbush
    • Esteemed Contributor
    • September 15, 2017

    Well while we're at here is the resource hog I've used for the last few years. I can't recall who wrote it but it has served me well.

    #!/bin/bash

# Displays the size of Office for Mac 2011 and 2016 Outlook identities

echo "<result>"

UserList=$(dscl . list /Users UniqueID | awk '$2 > 1000 { print $1 }') 

for u in $UserList; 
do
if [ -d /Users/"$u"'/Library/Group Containers/UBF8T346G9.Office' ]; then
results=$(du -sh /Users/"$u"'/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/Main Profile' | grep -v "[Back" | grep -v ".plist" | awk '{print $1}')
else continue
fi
echo "$u" "$results" "2016"

done

for u in $UserList; 
do
if [ -d /Users/"$u"/Documents/Microsoft User Data/Office 2011 Identities/ ]; then
results=$(du -sh /Users/"$u"/Documents/Microsoft User Data/Office 2011 Identities/ | grep -v "[Back" | grep -v ".plist" | awk '{print $1}')
else continue
fi
echo "$u" "$results" "2011"

done

echo "</result>"
exit 0
    anniwayy
    Forum|alt.badge.img+9
    • anniwayy
    • Contributor
    • January 2, 2018

    @jhbush1973 are you using this as an EA?

    we are looking into something similar to find out the identity size.

    thanks anniwayy

    Terms & ConditionsCookie settingsAccessibility statement