Troubleshooting your Microsoft Sentinel solution for SAP applications deployment

This article includes troubleshooting steps to help you ensure accurate and timely data ingestion and monitoring for your SAP environment with Microsoft Sentinel.

When working with the agentless data connector, most troubleshooting is done directly in the SAP Integration Suite, where the message log displays errors indicating the nature of the issue encountered.

Start by examining the message processing logs. For more information, see the SAP documentation. The error messages there can help you diagnose issues with missing permissions, connectivity errors, and other misconfigurations.

If you don't see a related error to your issue, turn on trace logging for more in-depth troubleshooting. For more information, see the SAP documentation.

Check for prerequisites

The agentless data connector package, deployed while performing the initial connector configuration, includes a tool to help SAP admins diagnose and fix issues related to the SAP environment configuration.

To configure and deploy the tool:

1. Open the integration package, navigate to the Artifacts tab, and select the Prerequisite checker iflow > Configure.
2. Set the target destination name for the remote function call (RFC) to the SAP system you want to check. For example, A4H-100-Sentinel-RFC.
3. Deploy the iflow as you would otherwise for your SAP systems.
4. For best results run the checker for 24 hours with 1min frequency to catch any anomalies like rogue overnight batch jobs, or any unknown usage spikes.

To review the check status:

1. In SAP Cloud Integration, open Monitor > Integrations and locate the runs of the Prerequisite checker iflow as per your watch period (e.g. 24h). Confirm that the runs completed with status Completed (HTTP 200) and that the response payload doesn't contain warnings or errors. The scheduler may produce messages with state "Discarded" due to internal workings of SAP Cloud Integration. These messages can be ignored and contain text like "Message processing has been discarded because the triggering timer event was already handled by another process."
2. Inspect the message processing log (MPL) Attachments and properties for the per-check results. Open the file attached to the MPL entry.

Use the following table to interpret the results:

If any findings remain, consult the response details for guidance on remediation steps. Legacy SAP systems often require extra SAP notes. Furthermore, see the troubleshooting section for common issues and resolutions.

After completion:

Undeploy the scheduled Prerequisite checker iflow once SAP system check was completed successfully. Repeat this sequence for every new SAP system that shall be onboarded.

Missing functionality in legacy SAP systems

Some legacy SAP systems may be missing required functionality for the RFC_READ_TABLE function module. Make sure that your SAP admin has reviewed SAP notes 3390051 and 382318, and has patched the system accordingly.

For more information, see Configure SAP Cloud Connector settings.

"Deploy required Azure resources" error when setting up the data connector

When you set up the Microsoft Sentinel for SAP - agentless data connector, under the Initial connector configuration > Step 1: Trigger automatic deployment of required Azure resources / SOC Engineer, after you select Deploy required resources, you might see the "Deploy required Azure resources" error or similar (errors may vary). This error might indicate that you're missing the required permissions for the Entra ID app registration.

If you don't have the Entra ID Application Developer role or higher, you need to work with a colleague that has this permission to finish setting up the Azure resources. For more information, follow the procedure in the agentless data connector connection step.

Missing "Last address routed"

If you see an error in the security audit log that you're missing the last address routed (an IP address), follow the guidance in the SAP note 3566290.

Incomplete SAP user master data

If you see an error that you have incomplete SAP user master data or no data in the ABAPAuthorizationDetails Microsoft Sentinel table, do the following:

1. Confirm that the SIAG_ROLE_GET_AUTH SAP function module exists in the SAP source system.
2. Follow the guidance in SAP note 3088309 for the relevant solution.

Status code 500 on SAP system connect on Sentinel

If you see an error with status code 500 during the connect process from Sentinel to SAP Cloud Integration, contact your SAP colleague monitoring the integration flow "Data Collector" on SAP Cloud Integration. By nature the error message details are only available on SAP's Message Processing Log.

Long message processing times or message volume anomalies on SAP Cloud Integration

If you see sudden spikes in message volumes and processing times on SAP Cloud Integration, consider filtering responsible sources on the NetWeaver side. There are two options available.

1. Use transaction SM19 and SAP's best practices to apply filter settings on Users and message classes causing the spike
2. Use the filter capabilities of the Sentinel package on SAP Cloud Integration to apply filtering on log read. The parameter max-rows are pre-populated to protect the integration flow from message flooding by design.

Note that log filters on NetWeaver impact what is written to the audit log on the source while a filter on SAP Cloud Integration only chooses not to read the problematic entries.

Intermittent failures in the SAP logging pipeline

Brief network interruptions, SAP system downtime, or temporary resource constraints can cause a collection request to fail. The agentless data connector automatically retries failed collection windows, so a failed request doesn't immediately mean that logs are permanently lost.

Automatic retries and checkpoints

The Microsoft Sentinel poller uses the Codeless Connector Framework (CCF) to request logs for collection windows bounded by startTimeUTC and endTimeUTC. When a window fails:

• The poller retries the same startTimeUTC and endTimeUTC window according to the configured request retry count. If those retries fail, the poller waits before attempting the same window again. This delay is called backoff.
• Checkpoint advancement occurs only after successful ingestion. A failed window isn't marked as successfully ingested.
• Later collection windows continue without waiting for the failed window to succeed. The failed window remains eligible for retries, even when newer logs are arriving.

For example, if collection fails for the five-minute window from 10:00 to 10:05 UTC and the configured retry count is three, the poller retries that window three times. If all three retries fail, the poller waits before attempting the same window again. Meanwhile, later collection windows can continue. When a retry succeeds, logs from 10:00 to 10:05 UTC are ingested later. The next scheduled collection doesn't replace the retry for the failed interval.

For background on CCF query windows and request-level retry settings, see the RestApiPoller data connector reference. Request-level retry settings aren't the same as the failed-window recovery limit described next.

Seven-day automatic recovery limit

The poller retries a failed collection window for up to seven days. If the window can't complete successfully within that period, automatic retries no longer recover it, and a permanent ingestion gap can remain unless you recover the missing logs manually.

Investigate and recover a failed window

To check recovery and address persistent failures:

1. Review the SAP Cloud Integration message processing logs. Identify the affected SAP system (SID), the failed UTC collection window, and the reported error.
2. Resolve the underlying connectivity, permissions, or resource issue with your SAP Basis team. For connection interruptions, see Connection reset or Connection broken on handle errors. For requests that repeatedly exceed the polling timeout, follow the timeout guidance.
3. Allow automatic retries to recover the failed window, and verify that the expected records for that SID and original event-time interval arrive in the relevant SAP log table. Don't check only the most recent records. See Monitor the health and role of your SAP systems for connectivity and ingestion checks.
4. If you need to selectively recover previously failed windows, call the Data Collector iFlow from a REST client or script, specifying the affected startTimeUTC and endTimeUTC values. This manual recovery is separate from the automatic retry policy and requires the source logs to remain available in SAP. For an optional sample PowerShell REST client, see the SAP time-slice backfill tool on GitHub. Test it in a nonproduction environment first, and follow its sizing and load-protection guidance to avoid overloading SAP components or disrupting live collection. Reload only confirmed missing windows: overlapping previously ingested windows creates duplicate records.

Timeouts during connector registration or log polling

The Microsoft Sentinel agentless poller enforces two timeouts when calling the SAP Cloud Integration Data Collector iflow. Exceeding either limit causes incomplete ingestion or repeated retries. Error messages on SAP Cloud Integration may vary based on which part of the data extraction pipeline fails first.

Initial connect (45-second limit) – partial data and failed connector registration

When you connect a new SAP system in Microsoft Sentinel, the initial handshake to the Data Collector iflow must complete within 45 seconds. If the SAP integration takes longer to respond, the connector ingests partial data and the connector registration fails.

To remediate:

1. Run the Prerequisite checker iflow and review its runtime measurements to identify the slow downstream call (RFC destination, audit log read, user master read).
2. Tune the SAP integration downstream of SAP Cloud Integration to bring the response time below 45 seconds. Common levers include audit log filter settings (SM19/RSAU best practices), data connector parameter overrides such as max-rows and offset-in-seconds (see Customize data connector behavior), and SAP Cloud Connector / RFC sizing.
3. If the response time still can't be reduced, switch to the SAP CPI–internal scheduler approach by deploying the Data Collector Scheduler iflow from the Microsoft Sentinel for SAP community repository. With the scheduler iflow, Microsoft Sentinel doesn't poll or register the connector; it only receives data pushed by SAP Cloud Integration. This approach trades real-time threat protection for higher tolerance to long-running SAP responses.

For an end-to-end discussion of the tradeoffs, see the blog post Run agentless SAP connector cost-efficiently.

Long-running iflow (180-second limit) – PROCESSING/ABANDONED states and retry snowball

If an HTTP connection times out and the poller doesn't receive a successful response, the poller retries the same collection window using the request retry count and backoff described in Automatic retries and checkpoints. Review SAP Cloud Integration message processing logs to diagnose the failure. States such as PROCESSING or ABANDONED don't by themselves establish that the HTTP connection timed out. Repeated failed requests can contribute to overlapping iflow runs and increased SAP system load.

To recover and prevent recurrence:

1. Delete the connector from Microsoft Sentinel and wait for the scheduled Sentinel requests to calm down. This breaks the retry snowball.
2. Run the Prerequisite checker iflow to identify the root cause of the slow audit log read response times on SAP (for example, missing indexes, oversized audit log, expensive user master reads on legacy releases).
3. Apply the relevant remediation — audit log filter tuning (SM19/RSAU best practices), Data Collector parameter overrides such as max-rows, offset-in-seconds, and force-sal-filesystem (see Customize data connector behavior) — before reconnecting the data connector in Microsoft Sentinel.
4. If HTTP connections continue to reach the 180-second timeout, deploy the Data Collector Scheduler iflow from the Microsoft Sentinel for SAP community repository. Switching to the SAP CPI–internal scheduler compromises real-time threat protection but avoids the retry pattern enforced by the Microsoft Sentinel poller.

"Connection reset" or "Connection broken on handle" errors

The Data Collector iFlow might report java.lang.Exception: Connection reset when a connection to the SAP backend closes unexpectedly before processing completes. The Connection broken on handle error similarly indicates an upstream interruption in the log data pipeline when Microsoft Sentinel requests SAP logs.

These errors are typically caused by network interruptions, downtime, resource saturation, configuration changes, or misconfigurations in the connection path between SAP Cloud Integration, SAP Cloud Connector, and the SAP backend. If multiple SAP systems stop sending logs to Microsoft Sentinel at the same time, the shared SAP Cloud Connector or SAP Cloud Integration component is a likely cause.

To resolve these errors:

1. Engage your SAP Basis team to verify the operational state and connectivity of the affected SAP backend, SAP Cloud Connector, and SAP Cloud Integration.
2. Use SAP's application health monitors to verify connectivity between SAP Cloud Integration, SAP Cloud Connector, and the SAP system.
3. Enable SAP Cloud Connector runtime monitoring.
4. Confirm the sizing of the SAP Cloud Connector master instance.
5. Review SAP Cloud Connector connection limits, and use SAP note 3403815 to tune the limits.
6. Isolate the affected SID log data flow, and review the other timeout-related guidance in this section.

The Microsoft Sentinel log poller retries failed collection windows for up to seven days, using the configured request retry count and delaying further attempts if those retries fail. Later windows continue independently. Verify recovery of the affected interval, not just the arrival of newer logs. For the recovery limit and selective manual recovery, see Intermittent failures in the SAP logging pipeline.

"Memory Exhaustions" reported by SAP Cloud Integration

The System > Memory > Usage tile in SAP Cloud Integration may report memory exhaustions with the Data collector iflow as major contributor across several intervals. A considerable based-load allocation on its own is expected for a log-reading integration flow for multiple SIDs and isn't an error by default. Investigate when memory exhaustions are counted alongside it, when message processing times increase, a new system onboarding attempt, or recent SAP upgrade is happening.

Two patterns typically cause this:

• Growing request backlog for a single SAP system (SID). The SAP system responds more slowly than the requested log time slice, so requests accumulate and each subsequent poll adds load on top of the unfinished one. This is commonly a downstream effect of the retry pattern described in the Timeouts during connector registration or log polling section or too large polling interval configurations. It is recommended to keep the 1 min default setting for heavily used SAP systems.
• Resource saturation on a shared tenant. High parallel loads from other integration flows or SAP systems on the same SAP Cloud Integration tenant reduce the resources available to the Data Collector iflow, extending processing times across all flows.

To recover, first apply the remediation in the timeouts section to break the retry pattern and reduce the volume returned per message. If memory exhaustions continue, use SAP Cloud Integration monitoring to determine whether the pressure originates from one SAP system or from overall tenant load. Sustained saturation may require additional SAP Cloud Integration capacity, or distributing SAP systems across multiple Cloud Integration instances.

Timeouts when SAP security audit logs are filesystem-backed

If Microsoft Sentinel integration requests time out during connector onboarding or ongoing log reads, review how your SAP Security Audit Log is recorded and retrieved, especially when recording is configured as Filesystem and database.

Selecting audit logs from SAP HANA database often provides the best performance. Other databases and filesystem-backed selection might require tuning.

To remediate:

1. Confirm with your SAP administrator whether Security Audit Log recording targets include filesystem storage.
2. Implement following SAP notes by using SNOTE or by importing the referenced support package (applies to SAP_BASIS 750+):
   • 3726943 - RSAU_API_GET_LOG_DATA | Dataselection only from Filesystem details
   • 3407647 - RSAU_READ_LOG | Optimization of reading audit log files
3. After implementing the correction, use filesystem-only selection with required parameters ID_FILESYSTEM_SEL_ONLY and ID_FILE_SEL_SIMPLE for faster retrieval. For behavior details and explanation, see SAP note 3500090.
4. Re-run connector validation.

Applying these SAP notes often improves retrieval performance significantly. If delays continue, they're typically related to SAP-side factors such as log shipping between application servers and network latency.

SAP Cloud Connector sizing, throughput, and isolation guidance

If timeout or throughput issues persist, validate SAP Cloud Connector sizing and runtime health by using Optimize SAP Cloud Connector sizing, throughput, and isolation.

Use the following symptom-to-SAP-note mapping for incident triage:

Invalid Credential or cannot get credential for example OAuth2 access token

Besides normal misconfigurations of credentials during registration of the SAP RFC destination on the data connector pane on Microsoft Sentinel, this could be a symptom of attempting integration with unsupported SAP Cloud Platform Integration in the NEO environment. See SAP note 3351844 for details the end-of-life of services in the NEO environment. Microsoft Sentinel Solution for SAP officially supports SAP Cloud Integration in the Cloud Foundry environment. See the reference on the SAP preparation guide.

Customers that want to protect their SAP landscape using Cloud Platform Integration in the NEO environment ahead of their migration to SAP Cloud Integration on the Cloud Foundry environment (Integration Suite), can do so by adopting the provided "Data Collector Scheduler" iflow.

It uses a simplified scheduler. The SAP threat protection scope remains the same. The Sentinel hosted Scheduler is dropped from the setup to avoid the mentioned handshake error with the downside of the Sentinel team having no insight on the healthiness of the Cloud Integration endpoints other than the SAP log data arrival. Often this is no concern, since the scope of monitoring resides with the SAP Cloud Platform Integration team anyways.

CL_SAL_HELPER=>TT_R_CLIENT type not found

This error can occur for various reasons in a variety of SAP Support Package levels that require import of SAP notes to fix the underlying bugs in the SAP standard code. Ensure the function module RSAU_API_GET_LOG_DATA is remote enabled, trigger a manual run from the SAP transaction code SE37, and inspect the output. The response must show at least one entry in ET_LOG export parameters table.

The connector prerequisites section lists typical SAP support notes that helped customers in such situations before. The list is not considered complete and only serves as entry point into a customer's individual path to fix SAP's standard functions, which may vary based on their current support package level and associated upgrade journey.

Does ISOC in Microsoft Defender affect my existing SAP security content?

No, Integrated Security Operations Center (ISOC) in Microsoft Defender doesn't affect your existing security content for the Microsoft Sentinel solution for SAP applications. Your existing analytics rules, workbooks, and playbooks continue to work.

For more information about the offering, see ISOC in Microsoft Defender.

Related content

Learn more about the Microsoft Sentinel solution for SAP applications:

• Deploy Microsoft Sentinel solution for SAP applications
• Prerequisites for deploying Microsoft Sentinel solution for SAP applications
• Configure your SAP system for the Microsoft Sentinel solution
• Deploy the solution content from the content hub

Reference files:

• Microsoft Sentinel solution for SAP applications solution data reference
• Microsoft Sentinel solution for SAP applications solution: security content reference

For more information, see Microsoft Sentinel solutions.