Reporting on apps - averages

[trolito]

Looking at the "Slowest apps" list under "Fleet Health", I am wondering how the average installation times are calculated.

Example
App: M365 Apps for Enterprise
14 installs
6 min avg
max 30m

The average seems very low when the reported max is 30m. Normally, this exact app install finishes in roughly 10 minutes time. I guess the low average comes from factory images already having M365 Apps pre-installed = no installation duration.

Example from session 90335ea4-640e-4682-96ed-5ffef34e8b57
When I look at the "Install Progress" I see M365 apps have no install duration listed. It's empty while all other apps are timed. I guess that is what brings down the average.

Related (possibly dumb) question :)
I see another listing of "Microsoft 365 Apps" in all my session reports (picture below). It correctly shows a "Pre-installed"-tag if that is the case while, on devices installing M365 Apps, it's just listed without the tag, making it seem like two M365 Apps packages were installed simultaneously.

Is this a kind of built-in gather rule for notification purposes that just shows up as an app installation instead of in the Analysis Results section? It's a very nice notification to have; I'm just confused about the way it's presented.

[trolito]

Since I wrote this issue, I noticed some further details.
The session reports include apps that are assigned to the device, but won't be installed. They're filtered out by assignment filters or app requirement rules.

Example session fcb44595-1e69-44ea-b874-33599446ab83
5 apps are listed with "null" install duration, and it makes sense because of a mix of assignment filters and requirement rules for those specific apps. The question is if they should even be listed at all?

[okieselbach]

Yes, the Office/M365 Apps package is a bit special. I have to deal with several situations there. An Office can be preinstalled. an Office can be installed via native integration CSP which pushes the XML and then kicks off ODT. of someone could package up the ODT with XML by themself or even someone packs everything incl. the binary sources in one Win32 package. Or also people kick of PS scripts to call ODT with XML and install Office. In all cases I need to identify everything correctly. My main detection for Win32 apps is based on IME logs. this would get just one way mentioned above. So, this is why I have written the OfficeInstallDetector (agent component) which looks for evidence of Office packages, running installs, DO downloads etc. to detect what's going on. As it is not always coming from IME as a Win32 package. In fact, most of the time people use the built in M365 Intune deploy which is the CSP pushing the XML (no Win32 app at all). Due to all the fact it can happen that I show just the Office Install Detector (what you see above in your screenshot) as I observed the DO download and install progress directly on the device). But for others it may look like they have 2 office packages. Why? Because one package (they have built as Win32 App by their own with the ODT and XML file) this one is pushed down and detected regularly as every other IME Win32 App and shown in install progress. but due to the fact that the real install on the device is still monitored via the OfficeInstallDetector you will see the entry of the OfficeInstallDetector as well. Maybe I label it with an extra (Office Install Detector) in addition to clarify this a bit and write also a docs article to shed some light on this.

regarding your skipped apps and counting etc. my latest changes regarding apps calculation etc. will bring here advancements. I hope to have addressed all these inconsistencies already. But this change is not pushed at the moment to production, will be later today

[okieselbach]

marked the Click-to-Run (office install detector) now better incl. a tooltip