There is already a post in this blog which talks about the SU25 transaction. However while recently working on a upgrade, it occurred to me that the information presented was too broad and might not answer a lot of the doubts that a security analyst might face when actually tasked to complete the full post SU25 execution. I do not claim that this post will answer all the question but it does go into more depth about the thinking that should go into the post upgrade activities. This is all the more important as when done wrong, the SU25 activity has potential to reduce the check indicators and roles for a SAP system to junk!
A service pack upgrade is a recurring event in any SAP project. Typically SAP introduces new applications as part of service packs. It is also possible that SAP re-writes the code around existing SAP applications. Any of these changes can introduce new security checks in the code and which need to be added into the security roles. The SAP provided tools for security upgrades are accessed by using the SU25 transaction.
Going into SU25 after an upgrade will reveal a screen similar to the one below
We never run Step 1 after an upgrade. Step 1 is only meant to be run after a new SAP installation and will copy all data from the SAP tables to the customer tables and overwrite everything.
For an upgrade, we start the SU25 activities by running step 2A. This compares the data in USOBT and USOBX with USOBT_C and USOBX_C. If SAP determines that there is no conflict between the SAP proposed values with the values maintained by the customer, it goes ahead and copies the data to the customer tables. For the transactions where it determines that SAP proposed values conflict with customer values, it proposes that we compare and manually adjust the values in Step 2B.
After 2A, we now run Step 2B and manually compare the list of transactions where the list of SAP proposed check indicator and default values is different from the values maintained by us. We go through all affected transactions one by one and either accept SAP proposed values or keep the values maintained by us.
In most cases, we would keep the customer values unless there is an overwhelming need to change it to the proposed values. The most important case would be to look for cases where SAP is proposing more security than what we have in the system (for example SAP proposal is for check whereas customer proposal is for do not check). Once we are through with the entire list of affected transactions we are ready to go into the next step 2C to look at the roles affected by the changes to SU24 data. At this point it is advisable to take a backup of the USOBT_CD and USOBX_C change log tables so that we have an idea of the values changed as part of SU25 activity.
In Step 2C, SAP provides us a list of all roles which have transactions in their menu which have SU24 data updated as part of the SU25 activity.
The Step 2D is optional and mainly meant to check if SAP has introduced new transactions in place of any existing transactions.
The last mandatory step in the SU25 process is to run Step 3 and transport the customer tables. This was the latest customer tables are transported into all the successive environments in the landscape. The transport of the tables should be followed by a transport for all the roles which were generated as part of Step 2C
Downloading/Uploading SU25 Data
As already discussed , the SU25 transaction over-writes the customer tables with SU24 data, USOBX_C and USOBT_C with the SAP provided data in USOBX and USOBT. As a precaution we would like to take a backup of the customer tables and also a backup of the SU24 data using the RSU22DOWN. The downloaded file from RSU22DOWN can be later re-uploaded into the SAP system to go back to the earlier customer defaults.