Troubleshooting

No sites appear in the Site(s) list

Issue: On the Fixlets step of the Create Fixlet Stream wizard, the Site(s) list is empty, and you cannot continue.

Cause: Your role has access to the Fixlet Streams application but not to any external patch content site. The list shows only external sites whose names begin with Patches for, Updates for, ESU Patching, or Known Exploited Vulnerabilities Content Pack for.

Resolution: Ask your administrator to edit your role and turn on access to at least one external patch content site on the Sites step, under External sites (read only access). See Editing a role.

Expected Fixlets are missing from the stream

Issue: Fixlets that match your criteria are not included in the stream.

Cause: The stream includes only Fixlets that have a default action and are not superseded. Tasks are never included.

Resolution: Confirm that the content meets the requirements in Create Fixlet Stream.

Edited Filter Results Do Not Appear

Issue: After you edit a filter on an existing Fixlet Stream and save the change, the Fixlets or Devices tab still lists the previous results. The counts on the stream card and on the details page also stay unchanged.

Cause: The page does not reload the results automatically after a filter change.

Resolution:

• Refresh the list: On the Fixlet Streams landing page, click the refresh icon in the top-right corner to reload the stream data. Your saved changes are not lost, only the displayed results are stale.
• Refresh the browser page: If the results are still stale, press F5, or use the browser reload button, to load the updated Fixlet and device lists.
• Confirm the new criteria: After the page reloads, check the Fixlet count and device count on the stream card to confirm that the edited filter produced the scope you expected.

Device Count and Relevant Fixlet Count Take Time to Update

Issue: The counts and compliance figures on a Fixlet Stream do not change as soon as you expect. For example:

• A new stream shows 0 Devices for several minutes, even though devices already match the subscription criteria.
• The Relevant Fixlets count stays unchanged after a deployment finishes, even when the deployment reports 100% successful.
• The Fixlets compliance ring chart continues to show the earlier percentage.

Cause: These metrics are derived from the state that devices report to the server. A Fixlet Stream does not recalculate them from the deployment result. Instead, it waits for each device to report its latest state in the next reporting cycle. Until that report arrives, the stream shows the values from the previous cycle.

What to expect: Reflecting correct metrics takes time. In a small environment, the first device count on a new stream can take about five minutes to appear. The relevant Fixlet count and the compliance percentage update after the affected devices report again, so the delay depends on your reporting interval and on how many devices the stream targets.

Resolutions:

• Allow time for the next report: Wait for the subscribed devices to report their state before you judge the counts. The stream is working as designed during this interval.
• Refresh the data: Click the refresh icon on the Fixlet Streams landing page, or reload the browser page, to pick up the latest reported values. A refresh does not force the devices to report.
• Confirm the deployment outcome: To check whether a Fixlet was applied, open the Deployments tab and review the deployment state instead of the relevant Fixlet count. A successful deployment with an unchanged count means the device has not reported yet.

Long Load Times for Complex Queries

Issue: A Fixlet Stream takes a long time to display results, or the page stops responding while it evaluates criteria. This is most common when a stream spans a large number of Fixlets, for example when you validate compliance across more than 100 Fixlets.

Cause: Complex relevance queries evaluate a large amount of content across many devices. Broad criteria, many sites, or many conditions increase the processing time.

What to expect: Loading can take more than one minute. In some cases the request stops before results appear.

Resolutions:

• Allow extra time: Wait for the query to finish before you retry. Repeated attempts add load and slow the result further.
• Narrow the criteria: Reduce the number of selected sites, or add conditions such as severity or category, so that the stream evaluates fewer Fixlets.
• Split the stream: Create several smaller Fixlet Streams instead of one broad stream. Smaller streams load faster and are easier to monitor.
• Run during off-peak hours: Schedule large evaluations when fewer operators are using the system.

Slow Response When Creating an Automation Right After Deactivating

Issue: You deactivate a Fixlet Stream and immediately click Create automation. The wizard is slow to open, or the automation is not created.

Cause: The system is still removing the previous automation when the new request arrives.

Resolutions:

• Wait before you retry: Allow the deactivation to finish, click the refresh icon, and confirm that the status shows Inactive and that the schedule panel reports no automation.
• Create the automation again: Start the wizard once the stream is confirmed inactive.
• Check for duplicates: Review the Automate remediation schedule panel to confirm that only the intended automation exists.

Error Fetching Devices

Issue: When attempting to apply dynamic filters, you may encounter the error message: "Error fetching devices. Please try again."

Causes:

• Incorrectly defined filter conditions.
• Attributes or values that do not exist in the device database.
• Network connectivity issues preventing the system from querying devices.

Resolutions:

• Validate Conditions: Review the conditions you set for the dynamic filters. Ensure that attributes, conditions, and values are correctly specified and applicable to your devices.
• Test with Simplified Filters: Temporarily simplify your conditions to isolate the problematic parameter. Start with broad filters and then narrow down to identify the issue.
• Check Network Connectivity: Ensure that the system has access to the necessary network resources to fetch device information.

Low Fixlet Compliance Percentage

Issue: The Fixlet compliance percentage is lower than expected after a deployment.

Causes:

• Devices may not meet the dynamic filter criteria.
• There may be compatibility issues preventing devices from applying the Fixlet.
• Some devices may be offline or not connected during deployment.
• The stream includes dynamic Fixlets. A dynamic Fixlet stays relevant after it is applied, so it does not raise the compliance percentage. See Monitoring.

Resolutions:

• Review Filter Conditions: Check if the dynamic filters are too restrictive. Adjust conditions to include more devices if necessary.
• Investigate Compatibility: Ensure that the Fixlet is compatible with the targeted devices (e.g., OS version, hardware requirements).
• Check Device Status: Confirm that all intended devices are online and connected. Consider scheduling the deployment during a time when devices are most likely to be active.

Deployment Progress Stalled

Issue: The deployment progress bar shows little to no movement over an extended period.

Causes:

• High network traffic or bandwidth limitations.
• Issues with the Fixlet itself, such as improper configuration.
• Large numbers of devices being targeted, causing slow processing.

Resolutions:

• Monitor Network Performance: Check network traffic and performance to ensure it can support the deployment. Consider deploying during off-peak hours.
• Verify Fixlet Configuration: Ensure that the Fixlet is configured correctly without any errors that could cause it to stall.
• Segment Deployments: If targeting a large group of devices, consider segmenting the deployment into smaller groups to expedite the process.