Skip to main content

September 1, 2026

Guided Root Cause Analysis (RCA)

Guided RCA (gRCA) in Omnissa Intelligence assists you with debugging widespread, application crashes, OS crash issues, and slow boot events. Use this feature in your Omnissa Workspace ONE Experience Management deployments where you notice large, abnormal increases in events on macOS and Windows apps and devices.

Requirements

  • The guided RCA (gRCA) feature works for macOS and Windows apps and devices.
    • For Windows devices that use Experience Management for Horizon, gRCA supports the following use cases.
      • The gRCA feature supports the Experience Management for Horizon use case Slow Logon Duration.
      • For this feature to work for Horizon use cases, for example your Horizon Slow Logon Duration use case, your deployment must have a minimum of 25 unique Horizon sessions during the selected time range.
      • For further details about this feature, see the section Explanation of the Slow Logon Duration gRCA.
  • The feature helps analyze application crashes, OS crashes (system crashes), and slow boot events.
  • For results to display after running the gRCA, the gRCA date range must include at least 100 app crashes, system crashes, or slow boot events. For details about what constitutes a qualifying event, see the Why can I see 100 events but get no gRCA results? section.
  • To work in production environments, this feature requires 100 or more devices.

Why can I see 100 events but get no gRCA results?

For gRCA to return results, the selected time window must include at least 100 unique, qualifying events for the metric being analyzed (for example, crashes or slow-logon sessions). However, the system registers only one unique, qualifying event for a device or session for a specific day.

Examples

  • If a device experiences 10 OS crashes in one day, then the gRCA system registers 1 OS crash event for that device for that day.
  • If a virtual session experiences 3 slow-logon sessions in one day, then the gRCA system registers 1 slow-logon event for that session for that day.

Let's look at a possible scenario where you can see 100 events but you get no gRCA results.

  • Scenario: You see 100 OS crashes so you run an Investigation and look at the gRCA tab. The system returns no results even though there are 100 events. Even after you expand the gRCA data range to include 7 days, you still see no results.
  • Explanation: The 100 OS crashes occurred on 10 devices in one day. The system lets each device register a unique, qualifying OS crash event for that day, so that is 10 unique, qualifying OS crash events for that day. If the 10 devices do not experience enough OS crashes to equal 100 events over the 7 days, then the gRCA system returns no results.

AI nutrition label

AI Nutrition FactsGuided Root Cause Analysis
Feature NameGuided root cause analysis
DescriptionFinds possible root causes for the user in the Experience Management solution
ProductsExperience Management
Model TypeLift analysis
Model ProviderInternal
Input DataTelemetry from Intelligence data lake
Input Data Available for Customer AuditNot applicable
Adheres to Data SovereigntyYes
Trained on Customer ContentNo
GuardrailsNot applicable
Update FrequencyModel is updated as needed
Data Retention DurationSee Intelligence data retention policy
OptionalityRequired as part of Experience Management solution

How can you use gRCA?

Use gRCA to help debug both widespread app crashes, system crashes, and slow booting devices. Guided RCA includes an algorithm that suggests statistically significant potential root causes. It is not guaranteed that the algorithm finds the root cause every time, however it should help you with knowing what to look for during the RCA process.

For information on how to create workflows that remediate your root cause findings, see the Freestyle Orchestrator topic.

Use advanced criteria to tune the RCA algorithm

You can use the Advanced Criteria to help the algorithm find possible causes for your investigations. Although selecting larger values of Lift Value or Support in the advanced criteria section can decrease the number of results in the analysis list view, it also can reduce the number of results that are not useful.

Tuning the advanced criteria parameters is optional but it is offered for those deployments that want to finely control the root cause analysis algorithm.

In the Advanced Criteria section, the UI lists the Features that your configured root cause analysis is checking for. Consider the features when you tune the advanced criteria parameters.

Find the features the algorithm looks for by expanding the advanced criteria section.

Advanced criteria parameter explanations

  • Lift Value: A lift value represents how statistically confident the algorithm must be in the specific feature (for example OS Version or Recently Installed Patches) to consider events as potential root causes.
    • If you raise the lift value, the algorithm might show less results because it has a higher confidence threshold that a result has to meet to be considered meaningful enough to show.
  • Pattern Length: The pattern length refers to the number of related features the algorithm identifies as possibly contributing to the root cause.
    • If you select 4, the algorithm displays up to 4 features (feature examples are Device Model, OS Version, App Version, and Recently Installed Patches) that when combined might be a root cause.
    • Using Patterns rather than just individual features, allows you to see complex patterns that might cause crashes like specific device models that only crash when they have had a specific patch installed and are running a certain app version.
  • Support: The support value is the required percentage of crashes that contain a specific feature for the algorithm to consider it significant and list it as a root cause.
    • If you select .05, this instructs the algorithm to consider a feature significant if it appears in 5% or more of the crashes.

Types of gRCA metrics

Currently, gRCA helps to analyze app crashes, system crashes, and slow boot events. Each device can register one app crash per unique app, one system crash per day, and one slow boot per day. To run the algorithm, your deployment must experience over 100 of these unique crashes or slow boot events during the time range you selected when you configured gRCA.

Configure notifications for Insights

Use Notification Settings to send yourself an in app or email notification (or both) concerning Insights.

  1. Select the bell icon in the Intelligence header.
  2. In the Notifications panel, select the gear icon to access the Notification Settings page.
  3. Expand the Intelligence section and select In App or Email for the type of notification you want to receive for the listed services.
    • App Insights: Notifies you about anomalies in apps on physical macOS and Windows machines.
    • Device Insights: Notifies you about anomalies on physical macOS and Windows devices.
    • User Insights: Notifies you about SSO login anomalies related to the Omnissa Access product.
    • Virtual Insights: Notifies you about anomalies detected in your Experience Management for Horizon deployment.
    • Programmatic Guided RCA: Notifies you when the system automatically runs a gRCA for an Insight.

Example gRCA configurations

This example outlines how to configure gRCA for a fictitious app called Acme Analytics to try to discover why the app is crashing. We'll work from creating the investigation to analyzing the root causes in a custom dashboard.

  1. Create an investigation in Intelligence.
    You don't have to create an investigation. You can select an investigation in the list as explained in the next section of the example.
    1. Go to Workspace > Experience Management > Experience Score > Desktop Apps > View.
    2. Select + Investigation.
    3. Enter the name of the app as the name of the investigation, Acme Analytics.
    4. Search for the name of the app (type Acme), and select the app to add it as an object to the investigation.
    5. Select Create Investigation.
  2. Check the performance indicators in the investigation after some time has passed.
    1. Go to Workspace > Experience Management > Investigations and select the Acme Analytics investigation from the list.
    2. Select the Overview tab and go to the Performance Indicators section. You find the App Crash and App Crash Count events show increases in app crashes.
  3. Work in the RCA tab of the investigation. Using gRCA, you create an app crash diagnosis for the system to use to find possible causes of the increase in crashes.
    1. Go to Workspace > Experience Management > Investigations and select the Acme Analytics investigation from the list.
    2. Select the RCA tab and enter the values in the Root Cause Analysis area.
      • Metric: Select App Crash.
      • Range: Add the dates Jun 17, 2025 - Jun 24, 2025.
      • Application: Enter Acme to search for the app and select the Acme Analytics app from the results list.
    3. Select Run Analysis.
    4. After the analysis completes, select the option to View Full Report.
    5. Go to the Results Summary to see a list of results that identify possible reasons for the spike in crashes of the Acme Analytics app.
      • Find root causes you want to study further. Look for Useful root causes that have high numbers of crashes. The system ranks root causes differently, depending on the gRCA configurations and the data available.
      • In this example, you work with two Types in the root cause list, App Version and Patch. Although these root causes do not display in the top three of Useful root causes, they have the highest number of crashes in the list.
      • The example app version is Acme Analytics-1.234.432.0 (11.01).
        • It is number 4 in the root cause list.
        • The system reports that it has 229 crashes.
        • This is the highest number of crashes in the root cause list.
      • The example patch number is 1ABCD23EFG4H-Acme.Analytics.
        • It is number 12 in the root cause list.
        • The system reports that it has 68 crashes.
        • This is the second highest number of crashes in the root cause list.
      • You can select the root cause item in the list to find Related Results.
      • Use the Not useful check box for a root cause item in the list that you know did not cause the crashes. This check box removes the item from the list.
  4. Create a custom dashboard to analyze if these events caused the spike in app crashes.
    1. Go to Workspace > Experience Management > Investigations and select the Acme Analytics investigation.
    2. Select the Overview tab and go to the Related Dashboards section.
    3. Select Create Custom Dashboard.
    4. In the dashboard, select the ellipses (...) and choose Add Widget.
    5. Select Add Custom Widget.
      Add three widgets to your custom dashboard. Create two of the widgets from the Employee Experience > Apps category and create the other widget from the Employee Experience > OS Updates category.
    6. Create widgets one and two using the Category options in Employee Experience > Apps.
      1. Create the first widget with the Name > Application Start and Application Foreground. Your widget configurations for the Data Visualization and Filter sections.
        • Chart Type: Select Vertical.
        • Measure: Select Count of Others > Event ID.
        • Group by: Select Others > App Version.
        • Results per group: Enter 10.
        • Date Range: Select Custom with the range of Jun 17, 2025 12:00 AM - Jun 24, 2025 11:59 PM.
        • Frequency: Select 1 day.
        • Filter: Add two rules.
          1. Others > App Name includes Acme Analytics
          2. Others > Event Name includes Application Start and Application Foreground
      2. Create the second widget with the Name > App Crashes by App Version. Your widget configurations for the Data Visualization and Filter sections.
        • Chart Type: Select Vertical.
        • Measure: Select Count of Others > Event ID.
        • Group by: Select Others > App Version.
        • Results per group: Enter 10.
        • Date Range: Select Custom with a range of Jun 17, 2025 12:00 AM - Jun 24, 2025 11:59 PM.
        • Frequency: Select 1 day.
        • Filter: Add three rules.
          1. Others > App Name includes Acme Analytics
          2. Others > Event Name includes Application Crash
          3. Others > Event Status includes complete
      3. Create the third widget using the Category options in Employee Experience > OS Updates.
        • Name: Enter Problem Patch. Your widget configurations for the Data Visualization and Filter sections.
        • Chart Type: Select Vertical.
        • Measure: Select Distinct Count of Others > Event ID.
        • Group by: Select Device > Device Model.
        • Results per group: Enter 10.
        • Date Range: Select Custom with a range of Jun 17, 2025 12:00 AM - Jun 24, 2025 11:59 PM.
        • Frequency: Select 1 day.
        • Filter: Add two rules.
          1. Others > Title includes the name of the patch, 1ABCD23EFG4H-Acme.Analytics
          2. Others > Event Status includes complete
    7. Filter and view the widgets in your custom dashboard to further analyze why the Acme Analytics app crashed.
      • Filter the Application Start and Application Foreground widget by the app version Acme Analytics-1.234.432.0 (11.01).
        You note that users started using this version of the app on September 14th.
      • Filter the App Crashes by App Version widget to display only the app version Acme Analytics-1.234.432.0 (11.01).
        You note that this app version reports the highest number of crash events.
      • Check the Problem Patch widget which identifies those devices that got the 1ABCD23EFG4H-Acme.Analytics patch.
        You note that many devices received this patch around September 14th. This date is the date that the app version Acme Analytics-1.234.432.0 (11.01) began to crash as reported by the Application Start and Application Foreground widget.
      • Consider a possible remediation of rolling this version of the app back removing the patched version from devices.
    8. Remediate the results found in the gRCA using workflows and use an action to remove the patched version of the app.

Explanation of the Slow Logon Duration gRCA

For those who want to know how Omnissa develops Guided Root Cause Analyses (gRCAs) for events, let’s look at how the gRCA works for the Slow Logon Duration scenario for Experience Management for Horizon. Other gRCAs follow a similar approach, including relevant data attributes to identify patterns.

Note: This explanation does not cover the attributes used for the Horizon First-Gen product. Although the attributes and calculations used are similar, they are not exact matches.

What does the Slow Logon Duration gRCA do?

Guided RCA uses an algorithm to look for patterns in the Horizon session data that may indicate root causes for logon duration issues. An example pattern would be the attributes Pool and Other Service Load Time.

Example: Slow Logon Duration Pattern = Pool attribute + Other Service Load Time attribute

The system identifies patterns that are important. A pattern is considered important when the number of occurrences of the pattern is statistically significant in affected sessions when compared to normal sessions.

Importance relates to the Lift Value

The Lift Value, an Advanced Criteria, controls the statistical confidence the gRCA engine requires to consider a pattern important. A lower Lift Value increases the probability the engine finds important patterns. A higher Lift Value decreases the probability the engine finds important patterns.

For example, if you set a lower Lift Value threshold for a Slow Logon Duration gRCA, you configure the gRCA engine to require less statistical confidence when identifying important patterns. With the lower statistical threshold, the engine might find more potentially important patterns.

Attributes for Slow Logon Duration

The gRCA for Slow Logon Duration uses the listed data attributes from your Experience Management for Horizon deployment.

Raw AttributeFriendly NameDefinition
edge_idEdge IDA value identifying the Horizon Edge deployment where the user initiated the session. Often, this value is the same value as the Edge Name.
edge_nameEdge NameThe name of the Horizon Edge deployment where the user initiated the session. Often, this value is the same value as the Edge ID.
event_timestampEvent TimeThe time the event occurred during the session.
horizon_session_userUser NameThe friendly name of the session's user.
s_da_logon_t_sLogon DurationThis is the total logon duration value and it aids with the selection of the underlying data used in analysis.
s_logon_timestampLogin TimeThe time the user logged in to the session.
s_others_load_t_sOther Service Load TimeThe duration to complete the other-service-load-phase of the logon duration value.
s_prof_load_t_sProfile Load TimeThe duration to complete the profile load phase.
s_shl_st_t_sShell Start TimeThe time to complete the start of the Shell application.
s_statusSession StatusThe status of the session as reported at the time of initiation.
s_typeSession TypeThe nature of a session. For example. the session can be an application or desktop session.
session_uuidSession UUIDA uniquely generated value that tracks a user's activity for a session.
template_idPool IDA value identifying the pool in which the session initiated.
template_namePoolThe name of the pool in which the session initiated.
template_typePool TypeThe type of pool in which the session initiated.
view_client_protocolClient ProtocolThe protocol associated with the session. Examples include BLAST, PCOIP, and RDP.
vm_idVM IDThe uniquely generated value that identifies and tracks the session.
vm_osversionOS VersionThe OS version of the virtual machine initiating the session.

Was this page helpful?

Provide feedback for this topic

Was this topic helpful?

Please do not include any personal or confidential information.

Generating link…