Microsoft 365 Office Software Normalization

[ian_starr]

I'm surprised I couldn't find anything on this already.

Has anyone not noticed that the 365 Office components such as Excel and Word are automatically normalizing to 2019 Versions rather than 365 ? Its clear from the discovered version that its 365, the version also matches the 365 Apps for Enterprise which does normalize correctly.

I seem to be drawing a blank so far as to why they are not normalizing correctly or even why they don't normalize as child elements of the 365 Apps for Enterprise.

I know I could amend these manually but for a major product in use by millions of people you would think it would be correct or is it me ?

[dreinhardt]

Hi @ian_starr,

could you please add more details as screenshots etc. to this post, based on the text it’s hard to answer your question.

would be good to share the software install record, discovery model and maybe linked software models.

Best, Dennis

[ian_starr]

Attached might help. As you can see, all these Products Discovered Versions are the same - 365 Version numbers - but only the 365 Apps for Enterprise normalises as 365.

We could manually fix this but you would think based on the Version that ServiceNow Product Catalogue would recognise its not 2019 which is what the automated Normalization has done.

[dylanhollor]

I run Office 365 for our licnese subscriptions and looking at our SW Install CMDB table my current version of Outlook on a Mac is being discovered as 2024 without being recognized as Apps for Enterprise. I think it has to do with how Apps for Enterprise is a specific installable package with that naming convention somewhere in the installer/app discovery. 

I am struggling with the Suite Child/Parent relationships breaking out individual apps from the O365/M365 suite as well and dont have good answers. As I learn more about it i wonder if the individual applications being discovered outside of the parent suite is due to selective or alternative installations? 
For example I see stand alone versions of Excel 2021, Excel 2010, and Excel Windows (what ever that is) but all the other installs of Excel get covered in the o365 E3 suite. 

[ian_starr]

Its to do with the release numbers now matching, there is no clear separation between 365 and the other products. This is what I got back;

Following our DEV team's analysis, here are the key findings and next steps:

Multiple M365 App Installs

Previously, only one entry for "M365 Apps for Enterprise" was visible.
Now, individual installs for Word, Excel, PowerPoint are appearing due to an update in the osquery tool (v5.14.1) used by ACC-F (May release).
This change is confirmed by ACC DEV team as expected behaviour with the new version.

M365 Integration Impact:
Use Case 1: If a user has a subscription, individual installs will roll up under the M365 license.
Use Case 2: Without a subscription, installs will appear as separate unlicensed software models.

Normalization Challenge
The individual install for Word, Excel, Powerpoint cannot be differentiated from perpetual office installs as build versions for office perpetual and M365 are same. Hence, system cannot determine difference between perpetual office from M365 just from installs- subscription is also required. However, after our analysis we found another field release id that can help differentiate between office and M365 installs. Dependency created to ACC: DEP0048716

Next Steps:
Proceed with M365 integration to enable correct license roll-up behaviour and thereby see the behaviour as mentioned above.
Please analyse integration feasibility which is critical for the solution to work. In terms of licensing the behaviour will work as mentioned in Use Case 1 and 2

Hope that helps. Its far too much to manually work it all out so we are moving on with the integration