Skip to Content
Technical Articles
Author's profile photo Karl-Heinz Hochmuth

SAP clustered resources explained in detail

You are running NetWeaver-based SAP applications on a Windows Failover Cluster. This blog will explain the details of the cluster resources’ properties and how they work together.

We start with a screenshot of a common SAP cluster group (also known as cluster “role”):

You see two SAP related resources here:

  • The “Service” resource starts the SAP service (like you would start this service in Windows Service Control Manager).
  • The “Instance” resource starts the SAP instance (like you would start it with SAP MMC or sapcontrol.exe)

The instance resource depends on the service resource. Both resources have similar, but different properties.

SAP Service Resource:

Service Name: That’s the name of the SAP service (see Windows Service Manager). The Syntax is by default: SAP<SID>_<Instance-Number>

Trace: You can enable an extended trace with “1”. Then, you get much more information in cluster.log. This is only necessary in case you want to analyze the problem together with SAP support.

AcceptableOfflineTime: The default value is 30 seconds which should fit for all cluster configurations. If your SAP service needs longer than 30 seconds to start, you can increase the value here.

MaintenanceMode: “0” = off, which is the default. You can turn on MaintenanceMode with “1”. This mode will be automatically set by SAP SUM tool in case you upgrade an SAP system in a Failover Cluster.


With enabled maintenance mode, the cluster will no longer check if the SAP service is online, offline, or healthy. The condition of the service will be ignored completely!

SAP Instance Resource:

This resource has more properties.

ExecuteBeforeFailure: You can enter the patch to a batch script here.
For example: c:\scripts\alert.bat. In case the resource becomes “failed”, the cluster will execute your script. With this script, you can send emails, SMS, alerts, run applications … whatever you want to get alerted!

SAPSystem: The instance number of the SAP (A)SCS instance.

HAnotRelevantApps: You can enter applications here, which will be started by SAP start service (sapstartsrv.exe), but will be ignored by the cluster. In the example above, sapcpe.exe (SAP copy app) and SAP Web Dispatcher (sapwebdisp.exe) will be started but threaten as a not relevant application for the cluster. If sapwebdisp.exe crashes, the SAP cluster group will not be affected. You can also add own application here if they’re started by SAP start service (see instance profile).

ExecuteAfterOnline: Same as ExecuteBeforeFailure, but the cluster will run a script here only if the resource was started successfully.

Trace: Same as the trace parameter of the SAP service resource.

ServiceControl: default value 1, in case you do not use the SAP Service resource, but the old “Generic Service” resource, the value is 0 here. SAP does not recommend using the Generic Service resource anymore!

SAPSystemName: The SID of the SAP system.

ExecuteBeforeOffline: Same as ExecuteBeforeFailure, but the cluster will run a script here only if the resource was stopped successfully.

Maintenance Mode: default 0. Same as SAP service parameter.

AcceptableYellowTime: This is the default value in seconds which defines the maximum time the cluster will wait for an SAP instance to become “green”. The color here refers to the colors of the SAP MMC: Yellow means, the instance is starting. Green, it is fully started.

If your SAP instances need more than 60 seconds to start, you can increase this value.


One more thing …

If you see other parameters like those above, you’re using an older cluster configuration.

Here is an example:

API Version … IgnoreYellowState … EnableInterfaceCaching … they’re not used anymore.
Possible values there will be ignored.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Riccardo Cola
      Riccardo Cola

      Very useful documentation!

      Author's profile photo Isaias Freitas
      Isaias Freitas

      Very good!

      (small observation: the name of the Web Dispatcher executable is "sapwebdisp.exe" :-))


      Author's profile photo Karl-Heinz Hochmuth
      Karl-Heinz Hochmuth
      Blog Post Author

      Hello Isaias,

      wow - well done buddy! I am getting older ...

      I will exchange the screenshot tomorrow when I am back in the office ... shame on me! 🙂


      Best regards,



      Author's profile photo Evgeny Evgeny
      Evgeny Evgeny

      Hi Karl ,

      I have 2 resources Instance and Service in Maintenance mode and I want to switch them off.

      I would appreciate it if you could explain why when you switch off maintenance mode first on Instance, the Cluster initiates a failover to the second node, but when you switch the maintenance mode off on the service resource first and then switch it off on Instance resource, the cluster behaves as expected and does not failover to the second node.



      Author's profile photo Karl-Heinz Hochmuth
      Karl-Heinz Hochmuth
      Blog Post Author

      Hello Evgeny,

      if you switch off MM, the cluster will immediately start with the health check again.

      This means for the SAP Service resource:

      SAPRC.DLL communicates with Windows Service Control Manager (services.msc) to retrieve the REAL status of the service. The service can be either stopped or running. If you disable MM on the SAP Service resource, then nothing will happen. If the service is already running and you start it via Failover Cluster Manager, nothing will happen, because the service is already started.

      Regarding the SAP Instance resource:

      If you disable MM in the instance resource, SAPRC.DLL immediately starts to contact sapstartsrv.exe to retrieve the processes and their color (color state, as seen in SAP MMC or via sapcontrol.exe with -function GetProcessList).

      This can be a problem if the instance is already running, the service is running, but the cluster SAP Service resource is in an "undefined" state.

      Undefined means here:

      If you enable MM, then you can control the SAP service and the instance with Windows Service Control Manager and with SAP MMC (or sapcontrol.exe). Example: You have enabled the MM while both cluster resources were OFFLINE.

      Then you have stopped/started the service and/or the instance many times.

      Then you disable MM. Main question for the cluster:

      What is the current, valid state for both resources? The SAP Service cluster resources was in offline state (most likely) and you have disabled MM for the SAP instance, not for the SAP service. SAPRC.DLL detects a "failure" (service not started) and initiated a failover.

      Therefore, the safest method is to enable / disable MM with stopped instance and stopped service. That's a "defined" state.


      Best regards,


      Author's profile photo Evgeny Evgeny
      Evgeny Evgeny

      Hi Kalle,

      Thanks for replying, in my case the Role, Service, and Instance resources are green in the cluster, also all the SAP ASCS processes are green in SAP MMC

      Please see the pic attached

      I was only activating the MM to troubleshoot the cluster-related issues.

      Just trying to understand if the SAP ASCS instance is running and healthy, why it fails over to the second node if I deactivate MM first on Instance resource, as SAP ASCS Instance is in the healthy state and green.

      But when I deactivate MM First on Service Resource and then as the second step deactivate MM on Instance, it stays on the same node.

      We have SAP Standard Setup in 2 Node Cluster with standard parameters and config .

      Is that normal behavior?  Is that the sequence and the MM must be deactivated first on the Service Resource and then on Instance?


      Appreciate you advice.

      Best Regards,




      Author's profile photo Karl-Heinz Hochmuth
      Karl-Heinz Hochmuth
      Blog Post Author

      Hello Evgeny,

      you find the reason, why SAPRC.DLL initiated a failover when you have disabled MM for the SAP SMP 00 Instance resource, in the cluster.log.

      I can only guess:

      Even if everything was started and also the Cluster resources where "green" = running, the missing SAP Service resource caused the failure? (because it was not "really" running because of still enabled MM ...)

      I recommend to open a SAP case and have this investigated. Open the ticket to BC-OP-NT component.

      Best regards,