SAP Kernel Update Automation

Updating SAP system kernel releases of your managed systems involves executing the SAP Kernel Update operation. This operation requires stopping the application server instances, resulting in system downtime.

The SAP Kernel Update automation provides a solution to relieve SAP administrators from performing time-consuming tasks, such as establishing connections to the SAP server(s) for patch deployment and the manual stopping and restarting of the SAP system. Automated kernel patching can result in a significant reduction in planned downtime for the maintenance window and increased security compliance with regular patching.

Kernel Patch Level

Initially, a kernel is internally released at patch level 1 and deployed to internal SAP systems. It undergoes patching as needed, incrementing the patch level (e.g., PL 1, 2, 3, and so on) with each new update.

A customer release occurs a few months later, featuring SAPEXE and SAPEXEDB executables at the running patch level (e.g., SAPEXE_15 and SAPEXEDB_15). Subsequently, patch levels continue to increase incrementally until the first SP Stack Kernel release. These SP Stack Kernels are easily recognizable by being numbered in hundreds (e.g., 100, 200, 300, and so on). For instance, PL 42 can be the last regular patch level, followed by the first SP Stack Kernel release at PL 100.

Regular kernel patches resume at PL 110 (PL 210, 310, and so on), increasing by one with each new patch (e.g., 110, 111, 112, 113, and so on) until the next SP Stack Kernel is introduced.

Patch numbers within the range of 101 to 109, 201 to 209, 301 to 309, and so on, are reserved for emergency corrections specific to the SP Stack Kernel. An emergency SP Stack Kernel at PL 101 includes select fixes on top of the SP Stack Kernel PL 100 and does not incorporate corrections delivered in the regular kernel patch levels (e.g., 110, 111, 112, and so on). Typically, this range remains empty as emergency corrections are infrequent.

The following figure shows a sample numeration within a kernel release:

72x Kernel

The 72x code line supports SAP Business Suite 6.0 (EhP ≤ 6) and is compatible with SAP NetWeaver releases 7.0 to 7.3 EhP1. This code line contains kernel 720, 721, and 722, including their respective variations: EXT and EX2 versions. The EXT and EX2 kernel versions are specifically designed to provide support for more recent operating systems (OS) and database (DB) platforms, as well as newer compiler/runtime environments.

For more details, see 1744209 - SAP Kernel 720, 721, and 722: Versions and Kernel Patch Levels.

74x and 75x Kernel

The 74x and 75x code lines offer support for both SAP Business Suite 6.0 (EhP7 and EhP8) and SAP S/4HANA releases 1511, 1610, and 1709. This compatibility extends to SAP NetWeaver releases 7.4 and 7.5 and SAP NetWeaver Application Server for ABAP 7.51 and 7.52. Within this code line, you'll find a range of kernel versions, from 740 up to the current version 753.

For more details, see 1969546 - Release Roadmap for Kernel 74x and 75x.

77x and 78k Kernel

The 77x and 78x code lines provide support for recent SAP S/4HANA releases from SAP S/4HANA 1809 onwards, including kernel version 773 and subsequent releases.

For more details, see 2907361 - Release Roadmap for Kernel 77x and 78x.

Naming Convention for Kernel Patches

Given a specific patch level, the name of the corresponding kernel patch in the SAP ONE Support portal's download section follows this pattern:



  • “<Package-name>” is the name of the corresponding kernel archive such as DW, SAPEXE,

SAPEXEDB, and R3trans.

  • “<Patch-level>” is the patch level.

  • “<SAP-internal-GUID-No>” is a unique ID, which is indicative of a specific kernel release and platform/database combination.

  • “<archext>” is the package format, typically SAR.

Pre-requisite Requirements

  • The system should be registered in IT-Conductor for monitoring.

  • A Robot User should be created and associated with the application/DB/OS users with assigned roles/privileges to execute the local action on the system to be stopped/started.

  • The ownership of the process definition should be assigned to the Robot User.

Demo Scenario

In this demo scenario, we used the lab system CR2 and the kernel 7.22EXT.

Note: The kernels, the IGS for the kernel, and the hostagent must be downloaded and mounted to the server prior to the execution of the automation.


Capture the kernel information as shown in the image below. Use this information for comparison when validating the results of the patching activity.

In IT-Conductor, you can capture baselines directly from the Service Grid.


The file resources are mounted to the server via NFS.

The following is the directory for SAPEXE and SAPEXEDB:

The following is the directory for SAPIGS:

Path Environment Variables

#Variable Path for SAPCAR,Kernel,IGS
patch_backup=/sybase/Kernel/Backup_Kernel_$(date +"%Y-%m-%d").SAR

Execution Config

The following is the ExecutionConfig template for the Form.SAP-Linux-KernelUpdate:

Process Definition

The following is a sample process definition for the SAP Kernel Update:

In the Input Parameters, select the following:

  • SAP SID - to be updated/patched

  • SAP Linux System - to be updated/patched

Then, define the following:

  • SAP Kernel Patch Level

  • SAP IGS Kernel Patch Level

Upon starting the process, you can see the status in real-time. Keep clicking the refresh button to update the status.

Once the status has changed to "Succeeded", click Finish.

Alternatively, you can view the status when you click the SAP Kernel Update job.

Execution Log

Another way to view the status of the automation in real-time is by using the execution log.


To further validate the results of the patching activity, you can check the SAP system directly and compare it to the generated baseline before executing the patching/update automation.

Bash Script

The following bash script executes the SAP Kernel Update operation:

#Variable from IT-Conductor
#Variable Path for SAPCAR, Kernel, IGS
patch_backup=/sybase/Kernel/Backup_Kernel_$(date +"%Y-%m-%d").SAR
#Variable Kernel name
#Vaiable IGS Kernrl OS
#Check DB for Kernel
if [ "$dbtype" = "SYBASE" ]; then lin_db=$lin_ase; fi
if [ "$dbtype" = "ORACLE" ]; then lin_db=$lin_oracle; fi
if [ "$dbtype" = "HDB" ]; then lin_db=$lin_hana; fi
if [ "$dbtype" = "DB6" ]; then lin_db=$lin_db2; fi
if [ -f $file_name1 ]; then count1=$((count1+1)); else echo "$file_name1 does not exist."; fi
#Check File Database independ
if [ -f $file_name2 ]; then count1=$((count1+1)); else echo "$file_name2 does not exist."; fi
#Check File Database depend
if [ -f $file_name3 ]; then count1=$((count1+1)); else echo "$file_name3 does not exist."; fi
#Check File IGS
if [ -f $file_name4 ]; then count1=$((count1+1)); else  echo "$file_name4 does not exist."; fi
#Check if All files Present
if [ "$count1" -ne "4" ]; then exit 1; fi 
#For Debug
#echo $file_name4
#echo $count1
# Stop SAP & Host Agent
sapcontrol -nr $sysnr+0 -function StopSystem 
sapcontrol -nr $sysnr+1 -function StopSystem
sapcontrol -nr $sysnr+0 -function StopService
sapcontrol -nr $sysnr+1 -function StopService
#Backup Old Kernel
echo "Starting Backup Old Kernel...."
echo "$file_name1 -cf $patch_backup -R $run_kernel*"
$file_name1 -cf $patch_backup -R $run_kernel*
#cd /usr/sap/$sapsid/SYS/exe/run/
#echo $(pwd)
#echo rm -rf *
rm -rf /usr/sap/$sapsid/SYS/exe/run/*
#Start patch Kernel
echo "Starting Path Kernel...."
#echo "$file_name1 -xf $file_name2 -R $run_kernel"
#echo "$file_name1 -xf $file_name3 -R $run_kernel"
#echo "$file_name1 -xf $file_name4 -R $run_kernel"
$file_name1 -xf $file_name2 -R $run_kernel
$file_name1 -xf $file_name3 -R $run_kernel
$file_name1 -xf $file_name4 -R $run_kernel
# Start Host Agent & SAP
sapcontrol -nr $sysnr+0 -function StartService $sapsid
sapcontrol -nr $sysnr+1 -function StartService $sapsid
sapcontrol -nr $sysnr+0 -function StartSystem
sapcontrol -nr $sysnr+1 -function StartSystem

Last updated