We currently have many versions of Office: 2024, 2021, 2019, 2016, 2013 and even a couple of 2010. Yes, I know about EOL dates and the need to upgrade, etc. This is why I’m working on this problem.
The problem with various relevance statements is that they look at the registry for uninstall information. 2024, for example, doesn’t do a clean uninstall of 2016, for example, when it installs. 2016 executables are removed and 2024 executables are installed, but there’s a lot of leftover cruft in the registry.
This means that BigFix sees 2016 and 2024 as both installed when this is not the case.
There may be a couple of ways of doing this, but Microsoft’s tendency to use different program folders for different versions is not consistent, and simply looking for an executable in a given folder is not reliable either.
My thought was to query winword.exe, wherever it might be located in C:\Program Files<name of Office folder>\ and check that against file versions.
However, I lack the relevance writing skills, and I suspect that I’m not the only one with this problem.
Has someone already solved this? Can you post what you’ve done?
We also don’t have Inventory, have a mixture of Office, but we are in a strange internal circle of who is responsible for Office
Right now, we use a combination the following Analyses
“(Deprecated) Microsoft Office Suite Information (Windows)” - BES Inv & License site
“Application Information for Office 365 - Office 2016” - Patches for Windows site
“Application Information for Office 2016 - Office 2016” - Patches for Windows site
“Application Information for Office 2019 - Office 2019” - Patches for Windows site
“Application Information for Office 2021 - Office 2021” - Patches for Windows site
I also created a various custom properties in a custom analysis with similar type of info or specifics we need.
I also have a BigFix group that tries to include endpoints with Office installed. It doesn’t care about versions, it just wants to get any device with Office.
exists (it as string) whose(it contains “Microsoft Office”) of values “DisplayName” of keys of keys “HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall” of (x64 registries; x32 registries) OR exists (it as string) whose(it contains “SharePoint”) of values “DisplayName” of keys of keys “HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall” of (x64 registries; x32 registries) OR exists (it as string) whose(it contains “Microsoft Access database engine”) of values “DisplayName” of keys of keys “HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall” of (x64 registries; x32 registries)
I looked at Application Information in Analyses, and it gives very different information than the relevance I have in place. Using 2016 as my example, known to be widespread, shows just 21 endpoints in Application Information. A relevance which checks the registry gets about 800. Reality is closer to 800, but a small number of them are known to have had 2016 uninstalled by the 2024 installer, leaving registry cruft behind.
Prior to Office 365 this was a fairly easy by looking at the major version of a regapp.
if (exists regapp "outlook.exe") then (preceding text of first ";" of following text of first ((preceding text of first "." of (version of regapp "outlook.exe" as string)) & ":") of "8:Office 97;9:Office 2000;10:Office XP;11:Office 2003;12:Office 2007;14:Office 2010;15:Office 2013;16:Office 2016;") else "NotInstalled"
With O365 versions sharing the same major version number (I believe), this is probably a bit more complicated. I haven’t looked into the version tables for the various O365 but maybe the major.minor.build could allow some differentiation between 2016, 2019, 2021 & 2024 versions.
