IBM Support

QRadar on Cloud: Patching common questions

Question & Answer


What do I need to know when my QRadar on Cloud (QRoC) environment is patched?


Expand each section to review the contents. If you are unsure of a process or need clarification, QRadar on Cloud users can search QRadar Support Assistance 101, or open a support case for more assistance.

How frequently are QRadar on Cloud environments updated?

QRadar on Cloud uses QA approved SFS files to update deployments. The goal is to patch all QRoC environments within 30 days of a new software release. Release schedules for QRadar on Cloud depend on core QRadar SIEM software approvals and in general, QRadar on Cloud is released approximately every 3 months**.

**Note: As software builds are approved by the QRadar Quality Assessment (QA) team, exact dates cannot be provided by support or DevOps. It is typical for support and DevOps team to talk to users based on when a release is expected, but dates might fluctuate based on testing and validation requirements.

Do I receive notifications on progress during the upgrade?

The QRadar on Cloud team sends notifications:

  1. Seven business days before maintenance begin.
  2. One business day before maintenance begins.
  3. One hour before maintenance begins.
  4. One after the maintenance is complete.

Note: If extra time is needed, we communicate any potential delay as soon as possible, as well as communicate more maintenance window needs.

I received an email about patch schedule but the release notes link included is not accessible, why?

The QRadar on Cloud team starts sending email to schedule patch maintenance seven days before the release date. However, the release notes are only made available once the patch is officially released on Fix Central. Once the patch is released, the release notes link inside the mail is accessible.

How can I get the email communication distribution list updated?

Customers can request for the email distribution list to be updated by replying to the patch maintenance email or open a support case.

If I have further questions or concerns about this upgrade maintenance window, what can I do?

If the maintenance window provided is not suitable, the maintenance window can be negotiated. You can reply to the patch maintenance email with the preferred maintenance window or open a support case. However, keep in mind that we might not be able to accommodate all requests.

Are there any prerequisite required before QRadar on Cloud team can patch the environment?

  • Check that all data gateways, and QNI, are in active status, online, and have proper specification. If any Data Gateways, or QNIs, are no longer in use and need to be removed from the deployment, notify the QRadar on Cloud team by replying to the patch maintenance email or open a support case.
  • Customers are required to update their applications to make sure they are running the latest version. If the applications are not up to date, they might stop functioning after updates. Customers can see which applications need to update from the QRadar Assistant Apps Applications page.
  • If you are using DLC, Customers are also required to update any DLC client to the latest version.

What is the upgrade process performed by the QRadar on Cloud team?

The console is patched first and all the managed hosts are then patched in parallel for the most efficient way to patch an environment.

Are the upgrades tested by the QRadar on Cloud team?

Yes, every upgrade is fully tested and goes through an intensive set of test cases.

Are config backups taken before start of patch?

Yes, config backups are generated daily and stored in a secure location separate from the QRadar Console. As well as Ariel data is backed up in accordance with the retention period in your entitlement agreement.

What new functionality, features, fixes, or vulnerabilities are in this upgrade?

To improve upgrade successfulness, what are the pre-validation steps performed by the QRadar on Cloud team?

A few days before the patch maintenance window, the QRadar on Cloud team performs a series of patch pre-tests on the environment in effort to have a successful patch. If any issues are found, they are addressed before the start of patch. These tests do not affect the environment and include the following:

  • Check for known defects, or APARs, related to the upgrade
  • Check any hosts that are not active
  • Check disk space
  • Run Cliniq pretests
  • Check iptables rules
  • Check memory requirements
  • Check RPM Database
  • Validate hostname
  • Check that proxy environment variable is not set, which would prevent patch from installing
  • Check certificate for valid fully qualified domain names (FQDNs)
  • If applicable, check HA status
  • If applicable, unmount any previous patch mount point

What is the rollback plan?

Upgrades don't have rollback functionality.  If any issues arise during the upgrade, the issue is addressed to allow the patch to complete.  

Note: Previous three months of data, before the upgrade, are backed up. Data buffered during the upgrade is not backed up. 

Information:  As a worse case scenario, we would need to rebuild the system and restore from a config backup used before the patch. However, system rebuilds are a rare occurrence.

How many other upgraded environments were before ours?

Depends on when your environment is scheduled for the upgrade. Patching is tentatively scheduled within 30 days of patch release date.

How many hours does patching take?

Patching time is different for each environment and dependent on the size and speed of the environment.  However, most of our patch upgrades are completed within overall average of 5 hours per environment.

Is the QRadar User Interface (UI) still accessible during the upgrade?

No, during the upgrade, the UI is not available until the upgrade completes, by design.

What are the impacts on QRadar services?

All services except for ecs-ec-ingress are shut down during the upgrade.  All log collection is buffered and the UI is not available.
Log collection is affected.  While the console is being patched, the data gateways continue to buffer events, no events are lost during this time. Once the Data Gateway is able to communicate with the console, events are sent to the console. Once console is patched all hosts start patching, during that time the hosts continue to buffer events until patch is completed.  Once the environment completed patching, buffered events are processed. 

Information: If there's a spike in events greater than the allowed EPS, some events might be stored on disk for a short period.

Note: Events sent during the time the host reboot, after patch, are lost. This reboot outage, and loss of events, applies to all hosts including Data Gateways and QNI.

Are offenses still generated?

Offenses are not triggered and created during the upgrade.  However, once the environment completes patching, log collection resumes and offenses trigger.

Does patching affect auto updates?

Before IBM patches, auto updates are turned off, and will be turned on again after patch is completed.  

Note: Auto updates might start running and might cause deploy changes depending on DSM or protocol updates, and what auto update settings are configured on your system.

What happens with offline, or unknown, data gateways?

A few days before the scheduled patch window, the QRadar on Cloud team communicates any hosts that are not available allowing your team time to address the issue before start of patch.  

Note: If the host is still offline, or unknown, during the patch maintenance window, the host is not patched. Customers are responsible to patch their own offline data gateway, or offline QRadar Network Insights (QNI), system once it is brought back online per steps found in the release notes or upgrade documentation. For example, searching for QRadar 7.5.0 Update Package 4 release provides the upgrade procedure. If you require more assistance, QRadar on Cloud users can open a support case.

What happens when a patch is taking longer to complete than the allocated maintenance window?

The QRadar on Cloud team does everything possible to stay within allocated maintenance window.  However, there might be an occasion when more maintenance window is required.  In this case, the QRadar on Cloud team communicates any delays and adjusts the maintenance window.

To make sure everything is still working after the upgrade, what post-validation is IBM performing?

Once the patch is completed, the QRadar on Cloud team performs the following steps to insure the system is functional:

  • Confirm all hosts are active and patched to the correct level
  • Confirm all applications are in running state and working correctly
  • Confirm all tabs in UI open with no visible issues

Why was a post-upgrade issue not addressed by the QRadar on Cloud team, and what are the next steps?

The QRadar on Cloud team performs a series of post-patch validation to make sure that the system is operational after the upgrade.  However, it is possible that some issues arise after the upgrade, which the customer can open a support case for.

[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSKMKU","label":"IBM QRadar on Cloud"},"ARM Category":[{"code":"a8m0z000000cwtdAAA","label":"Upgrade"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
15 March 2023