Deploying the SAP 7.20 EXT Kernel Note 1553301

SAP KERNEL 7.20

Symptom

I wanted to run the SAP 7.20 EXT kernel in my system landscape as an alternative to the standard 7.20 kernel. The EXT kernel is designed to be downward compatible and offers extended support options.

Reason & Prerequisites

From my experience, the EXT kernel is supported across all NetWeaver releases that already support the 7.20 kernel, including:

• SAP NetWeaver 7.0 (and EhP1, EhP2, EhP3)

• SAP NetWeaver 7.1 (and EhP1, CE 7.1, EhP1 for CE)

• SAP NetWeaver 7.2

• SAP NetWeaver 7.3 (and EhP1)

For general background, SAP Note 1553300 provides the foundation, while Notes 1629598 and 1636252 explain downward compatibility in detail.

Key Considerations Before Implementation

• The EXT kernel is only available in 64‑bit.

• You may need to upgrade your operating system or database release. Always check the Product Availability Matrix (PAM) to confirm compatibility.

• If you’re installing a new system or performing a system copy on NetWeaver 7.0 or higher, use Software Provisioning Manager (SWPM), which supports EXT kernel deployment (see Note 1680045).

Implementation Steps I Followed

1. Replace kernels on all application servers in the affected system.

2. Exchange the Internet Graphics Server (IGS) with the SAP IGS 7.20 EXT version.

3. After updating, I confirmed that SAP GUI did not require an update — it worked seamlessly with the EXT kernel.

4. Since the EXT kernel is a binary‑only release, I didn’t need to upgrade the SAP system itself.

5. Post‑installation, I continued importing support packages for the SAP release as usual.

6. For kernel corrections, I only applied 7.20 EXT patches — mixing with standard 7.20 patches is not supported.

Advantages I Observed

• Extended support lifecycle compared to the standard kernel.

• Ability to run newer kernel features without a full system upgrade.

• Simplified maintenance since the EXT kernel is downward compatible.

Lessons Learned

• Plan OS/DB upgrades early: PAM checks are essential before rollout.

• Consistency across servers: All application servers must be updated together to avoid mismatches.

• IGS replacement is mandatory: Skipping this step can cause rendering issues.

• Transport discipline: Even though the kernel is binary‑only, repository objects still rely on regular support package imports.

Microsoft Windows

When I deployed the 7.20 EXT kernel on Windows, I learned that it requires a specific C runtime. Fortunately, this runtime is bundled inside the SAPEXE.SAR archive. SAP Note 1553465 explains how to apply it, and I always made sure to install it before starting the kernel exchange.

AIX

On AIX systems, I had to check the minimum OS release and C/C++ runtime requirements. SAP Note 1780629 was my reference here. Without meeting these prerequisites, the kernel wouldn’t start properly.

IBM i

Interestingly, IBM i required no special activities. The EXT kernel worked out of the box.

Linux

Before installing the EXT kernel on Linux, I reviewed SAP Note 1563102. This note outlines the OS and runtime requirements. Skipping this step can cause runtime errors during startup.

Oracle Database

• On IBM Power Linux and Linux IA64 (Itanium), only Oracle 10g is supported. No changes to the database client were needed.

• On all other platforms, I had to ensure:

  • The database server was running Oracle 11.2.0.2 or higher.

  • The latest SAP Bundle Patch was applied.

  • The Oracle 11g Instant Client was installed on all application servers and the DB server (SAP Note 1431794).

  • After installation, I carefully updated the library path (LIBPATH, SHLIB_PATH, LD_LIBRARY_PATH) for <sid>adm to remove references to the old Oracle 10g client.

Other Platforms

For other platforms, I relied on the Product Availability Matrix (PAM) to confirm compatibility.

My Steps for Manual Kernel Exchange

Preparation

1. Stop the SAP system (no need to stop the database).

2. Terminate SAProuter if running.

3. Download the latest EXT kernel stack (SAPEXE.SAR, SAPEXEDB.SAR) and IGS archives (IGSEXE.SAR, IGSHELPER.SAR).

4. If using Oracle, also download DBATOOLS.SAR.

5. Save the old kernel by creating a tar archive of the kernel directory.

Deployment on UNIX/Linux

1. Log in as <SID>adm on the first installation host.

2. Copy the archives to a temporary directory (e.g., /tmp).

3. Navigate to the kernel directory:

   • /usr/sap/<SAPSID>/SYS/exe/run (NetWeaver 7.0 EhP2)

   • /usr/sap/<SAPSID>/SYS/exe/<codepage>/<platform> (NetWeaver 7.30)

4. Change ownership of files to <SID>adm using chown.

5. Use SAPCAR to unpack the archives:

   bash

   SAPCAR -xvf SAPEXE.SAR
   SAPCAR -xvf SAPEXEDB.SAR
   SAPCAR -xvf DBATOOLS.SAR   # if Oracle
   SAPCAR -xvf IGSEXE.SAR
   SAPCAR -xvf IGSHELPER.SAR
   

6. Run the saproot.sh script in the kernel directory as root.

Lessons Learned

• Always back up the old kernel before deploying EXT.

• Check PAM and OS/DB notes carefully — missing prerequisites cause startup failures.

• Consistency across servers is critical: update all application servers together.

• Library paths matter: forgetting to clean up old Oracle client references can break the system.

• IGS replacement is mandatory: skipping it leads to rendering issues in applications.

Additional Deployment of IGSHELPER

One lesson I learned is that the IGSHELPER.SAR archive must be deployed not only in the installation directory but also in the instance directory of the primary application server and every additional application server.

Steps I followed:

1. Log in as <SID>adm.

2. Copy IGSHELPER.SAR to a temporary directory (e.g., /tmp or c:\temp).

3. Switch to the instance directory:

   • /usr/sap/<SAPSID>/DVEBMGS → primary instance

   • /usr/sap/<SAPSID>/D<No> → additional instances

4. Unpack using SAPCAR:

   bash

   ./exe/SAPCAR -xvf <TEMPDIR>/IGSHELPER.SAR
   

Windows Deployment

On Windows, the process was slightly different:

• Copy all archives (SAPEXE.SAR, SAPEXEDB.SAR, IGSEXE.SAR, IGSHELPER.SAR, and DBATOOLS.SAR for Oracle) to a staging directory.

• Determine the DIR_CT_RUN profile parameter (SAP Note 997848).

• Log in as <SID>adm, open cmd.exe as administrator, and set the working directory to DIR_CT_RUN.

• Place sapcar.exe in the parent directory of DIR_CT_RUN.

• Backup old kernel executables using copy, not rename (SAP Note 142100).

• Unpack archives in sequence:

  cmd

  ..\sapcar.exe -xvf <TEMPDIR>\SAPEXE.SAR
  ..\sapcar.exe -xvf <TEMPDIR>\SAPEXEDB.SAR
  ..\sapcar.exe -xvf <TEMPDIR>\DBATOOLS.SAR   (Oracle only)
  ..\sapcar.exe -xvf <TEMPDIR>\IGSEXE.SAR
  ..\sapcar.exe -xvf <TEMPDIR>\IGSHELPER.SAR
  

• Install the C runtime library (vcredist_<platform>.msi) on each node before starting the system.

• For MSCS clusters, update files in Windows\SAPCLUSTER across all nodes.

IBM i Deployment

On IBM i, the process was streamlined:

1. Log in as <SID>adm.

2. Copy archives (SAPEXE.SAR, SAPEXEDB.SAR, IGSEXE.SAR, IGSHELPER.SAR) to /tmp.

3. Run the APYSIDKRN command:

   Code

   APYSIDKRN SID(<SAPSID>)  
             ARCHIVES('<TEMPDIR>/SAPEXE.SAR'  
                      '<TEMPDIR>/SAPEXEDB.SAR'  
                      '<TEMPDIR>/IGSEXE.SAR'  
                      '<TEMPDIR>/IGSHELPER.SAR')  
             MODE(*FULLY) CARPATH(*BUILTIN)  
   

SAPCRYPTOLIB

If using SAPCRYPTOLIB, I reinstalled it according to SAP Note 510007. The procedure is documented in the SAP Help Portal for both ABAP and Java stacks.

Java‑Only Stack

For Java‑only systems, I followed SAP Knowledge Base Article 1505299. The key was selecting the correct EXT kernel archives (DB/OS combination, 64‑bit, Unicode) and replacing IGS archives as described for ABAP/dual stack systems.

Applying the EXT Kernel During Upgrades & Updates

SP Stack Definition

When defining the Support Package Stack (SP Stack) in the SAP Maintenance Optimizer (MOPZ) or on the SAP Service Marketplace, I always selected the 7.20 EXT kernel instead of the standard kernel. For IGS, I chose SAP IGS 7.20 EXT.

This ensured the correct archives were automatically added to the download basket. The rest of the upgrade/update procedure remained unchanged.

Applying the EXT Kernel Within SP Stacks

Before installation, I confirmed OS and DB prerequisites. During stack definition, I selected the correct EXT kernel (64‑bit, Unicode/Non‑Unicode, DB/OS specific). This streamlined the update process since the right archives were automatically included.

Updating SAP NetWeaver CE with Update Management Service

For SAP NetWeaver CE, I used the Update Management Service (UMS). Two methods were available:

• Locally downloaded SP stack → supported for upgrades, updates, and lifecycle operations if already using EXT kernel.

• SMP Automatic Update → automated update from SAP Service Marketplace.

In both cases, I selected the EXT kernel and IGS 7.20 EXT during stack definition.

Lessons Learned

• Deploy IGSHELPER everywhere: both installation and instance directories.

• Windows requires careful path handling: avoid blanks unless wrapped in quotes.

• Backup old kernels properly: always copy, never rename.

• Cluster environments need extra care: update all nodes consistently.

• SP stack definition is critical: selecting EXT kernel ensures smooth upgrades.