Best Practice: Repairing a Failed SAP Instance (Part 1 – Restoring a Failed SAP Service)
There are many different scenarios that can lead to an SAP instance standstill and prevent the restart. In this blog post, I want to focus on the most common errors and provide instructions on how to solve them.
I use a clustered SAP system for reference and demonstrate what a standstill scenario can look like when the ASCS instance is in the failed state. On the following screenshots you can see an example of the SAP MMC and the Failover Cluster Manager when the SAP instance is offline and can’t be started.
In this blog post, I use a failed SAP instance as an example. However, the instructions for recovering a failed SAP service or instance can, except for some small differences, also be applied to an SAP dialog instance or an SAP enqueue replication server instance.
Action Plan: Where Do I Begin?
When an SAP instance of a productive SAP system is in the failed state, this mostly means a significant business impact. In this case, just keep calm and focus on the actual problem.
To recover the failed SAP instance, the SAP service must be operable. Therefore, this blog post covers common misconfigurations that can lead to a stopped or failed SAP service. If the SAP service is running but the SAP instance fails to start, read the follow-up blog post Best Practice: Repairing a Failed SAP Instance (Part 2 – Restoring a Failed SAP Instance).
To check whether the SAP service is running or not, use services.msc. First, check the instance number of the failed SAP instance. In our case, the SAP MMC reveals that mg4ascs with instance number 24 can’t be reached. Then, you can search the SAP<SID> service with the correct instance number in services.msc.
In this example, the SAP service is stopped because the status of SAPMG4_24 is empty and not Running.
The first logical step is to try to restart the SAP service. To do so, right-click on the corresponding service and choose Start. If the SAP service can’t be started, I will call its state “failed”.
If you have identified that the SAP service has failed, you need to find out why. Useful resources for determining why the SAP service has failed are the error message that appears when you try to start the service manually, the Windows application log, and the Windows system log.
Here, the error message suggests that the service can’t be started due to a logon failure. In the following, you find a selection of the most common problems that prevent an SAP service from starting and I want to show how you can identify and fix these problems.
Common Problem Scenarios
The credentials that were passed on to start the service are incorrect (logon failure)
This is a common error scenario that occurs, for example, when the password of the SAPServiceSID user is changed but the modification of the SAP service is forgotten.
To fix this problem, right-click on the corresponding service (in our case SAPMG4_24) and choose Properties. Then, go to the Log On tab and enter the correct credentials.
The correct user to start an SAP service for an SAP instance is the SAPServiceSID user.
In my example, as I installed this SAP system in a Windows domain, I start the SAPMG4_24 service as NT5\SAPServiceMG4. Here, “NT5” is the name of our domain. If I had installed a local SAP system and wanted to use the local SAPServiceSID user, I would have entered .\SAPServiceMG4.
The path to the executable sapstartsrv.exe is incorrect
The SAP instance is started by the executable sapstartsrv.exe. If the Windows operating system is not able to find this executable because the path in the SAP service has been configured in a wrong way, the SAP instance won’t start. Then, the following error message appears.
If you want to repair a clustered ASCS instance and use shared disks, make sure that the role of the SAP instance is on the node where you want to fix the SAP service. If this is not the case, you can move the role in the Failover Cluster Manager by clicking on Move and choosing Select Node. Then, you can specify onto which node you want to move the role. In my example, the SAP MG4 role is on the node wsivg030-01. That’s the node where I want to fix the SAP service, so I don’t move the role.
To check if the path to the sapstartsrv.exe is correct, right-click on the corresponding SAP service and choose Properties. Then, copy the path to the executable and paste it into a cmd.exe or PowerShell. If the output looks like below and the GUI of the sapstartsrv.exe doesn’t appear, the sapstartsrv.exe can’t be accessed via the path that’s been specified in the SAP service.
Every SAP instance has its own sapstartsrv.exe. The location of the sapstartsrv.exe depends on the SAP instance and the SAP system:
- ASCS instance: The path to the exe for an ASCS instance is:
In our example, the correct path is:
Note that in the file share configuration, each node has its own sapstartsrv.exe located on a local disk.
- Dialog instance: The path to the exe for a dialog instance is:
A valid path for a dialog instance in our SAP system landscape is:
- Enqueue replication server instance: The path to the exe for an enqueue replication server instance is:
A valid path for an ERS instance in our SAP system landscape is:
You can reinstall the SAP service by executing sapstartsrv.exe. Go to the corresponding directory, right-click on sapstartsrv.exe and choose Run as administrator. Then, specify the SID of your SAP system, the instance number, the network path to the profile, the user who should run the SAP service, the password for this user, the startup type, and the user environment that should be used.
The profiles for the different SAP instances are located in the central sapmnt network share. The network path should look like this: \\<hostname>\sapmnt\<SID>\SYS\profile\<profile_name>. Exceptions to this rule are the profiles for ERS instances in releases earlier than SAP NetWeaver 7.52. For this type of SAP instances, the profile is located in the local SAP directory <DriveLetter>:\usr\sap\<SID>\ERS<Instancenumber>\profile\<profile_name>. The ERS profile in my scenario is located in C:\usr\sap\MG4\ERS34\profile\MG4_ERS34_wsivg030-01.
As stated above, the SAPServiceSID user must be used to run the SAP service. However, use the environment of the SIDadm user! The environment of the SIDadm user contains additional environment variables that have been set by SAP.
A different approach to fixing the wrong path in the SAP service is to directly modify the corresponding registry entry. To do so, open regedit.exe and go to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SAP<SID>_<InstanceNumber>. The value ImagePath contains the path to the sapstartsrv.exe as well as the network path to the instance profile and can be modified by right-clicking on it. After the modification, you can start the SAP service in services.msc.
The network path to the instance profile is incorrect
The SAP service isn’t able to start if the network path to the instance profile is incorrect. When the SAP service is started manually within services.msc, the following error message appears.
To check if the profile is accessible via the specified path, simply execute notepad.exe <NetworkPath> in cmd.exe or PowerShell. In my example, I would use notepad.exe \\mg4ascs\sapmnt\MG4\SYS\profile\MG4_ASCS24_mg4ascs. If the profile is accessible, a Notepad window appears displaying the content of the profile. If the profile is not accessible, notepad.exe shows the error message that the “network name cannot be found”.
In this case, proceed as in the previous section “The path to the executable “sapstartsrv.exe” is incorrect” and reinstall the SAP service with the correct network path to the instance profile.
The SAPServiceSID user who runs the SAP service has inadequate permissions (Part 1 ACLs)
In this blog, we deal with two different kinds of user permissions that can prevent the SAP service from starting. First, we’ll take a look at misconfigurations of the user permissions on the file system (so called ACLs). Later, we’ll focus on permissions on network shares.
If the user who starts the SAP service doesn’t have adequate permission for the <DriveLetter>:\usr\sap directory or subdirectories, the SAP service isn’t able to start and the following error message appears.
To solve this issue, go to the parent directory <DriveLetter>:\usr where the instance resources were installed. In my example, this is E:\usr. Then, right-click on the sap folder and choose Properties and go to the Security tab. Check if the SAP_LocalAdmin group has full control of this folder, subfolders and files. In addition, it’s important that the SAP users <SID>adm, sapadm, SAPService<SID>, and any user group in which these users are included don’t have any denied permissions.
These two criteria, that the SAP_LocalAdmin group has full control and that the granted permissions are not denied, have to be met for all subdirectories and files in the <DriveLetter>:\usr directory. If a misconfiguration is found, click on Edit and set the correct permissions.
The SAPServiceSID user who runs the SAP service has inadequate permissions (Part 2 network shares)
The profiles of SAP instances are stored on a central network share, which I will call sapmnt share in the following. If the SAP service can’t access a profile located on the sapmnt share, it can’t be started.
The permissions for accessing the sapmnt share can be managed with the Computer Management tool. If your sapmnt network share is located on a different host, right-click on Computer Management (Local) and choose Connect to another computer. Then, specify the name of the host on which the sapmnt share is located.
Go to System Tools -> Shared Folders -> Shares. Then, right-click on sapmnt, choose Properties and go to the Share Permissions tab. Here, the share permissions are listed and it’s important that the SAP_SID_GlobalAdmin has full control of the sapmnt share and has no denied permissions.
After you’ve checked that the permissions have been set correctly, go to the Security tab and check whether the ACLs for the sapmnt share have been set correctly. As in the previous section, the SAP_LocalAdmin group must be granted full control of the file system. In this example, the permissions have been set correctly.
In section 2 „The path to the executable sapstartsrv.exe is incorrect“, I showed that you can reinstall the SAP service by executing the corresponding sapstartsrv.exe. I also stated that the correct environment to run the service is the user environment of the <SID>adm user. Here, the following question can arise: How can I check whether or not the SAP service has been configured with the correct environment?
To check the environment, start regedit.exe and go to the key HKEY_LOCAL_MACHINE\SOFTWARE\SAP\<SID>. If the used environment is correct, this key contains the value AdmUser with the <SID>adm user of the SAP system and the key Environment is not empty.
To demonstrate what the registry might look like when the wrong user environment is used, I deleted the value AdmUser and renamed the key “environment” into “environment_”. Then, I reinstalled the SAP service that starts the ASCS instance with the sapstartsrv.exe, as shown in section 2.
After the installation of the SAP service, the key Environment was recreated. However, the value AdmUser is missing and Environment is empty.
This concludes the first part of my blog post on “Repairing a Failed SAP Instance”. Now that you know the most common misconfigurations that prevent an SAP service from starting, hopefully your SAP service is operational. If your SAP service is running but the SAP instance can’t start, read my follow-up blog post Best Practice: Repairing a Failed SAP Instance (Part 2 – Restoring a Failed SAP Instance).
Feel free to leave questions or comments.