SU25 Upgrade Step

[Former Member]

Hello Experts - We just upgrade BW sytem from NW Enhancement Pack 7.0, SP-7 to NW EHP 7.1, SP Stack 7.

1)My question is do we need to do SU25- Upgrade step? I was in a impression that we do this step only for release upgrades.

2) Last time when we did R/3 4.6 to ECC 6.0 upgrade, I saw Yellow lights turned on many of our business and IS roles. Is this normal ?

I performed all steps per SU25, and had to fix all roles to turn off yellow lights.

Anyways back to my question 1, will you please let me know your thoughts?

Thanks Much.

[Former Member]

Though upgrade at that level I have not done.

Your analysis authorizations are migrated by running

program RSEC_MIGRATION for BI.

Please look at the documentation for the correct steps

SU25 ugrade steps ( please search the forum very good postings are available)

[Former Member]

Hi Franklin - Was reading old articles and postings, seems like pretty much I have to run SU25 steps.

About 'RSEC_MIGRATION', will you let me know little more on this? Completely new to this term, mean while I would do some checks on the system.

Thanks.

[Former Member]

If you look at the BI documentation/Security guide it will give you very good step by step information:

For BI upgrades :

Execute the program RSEC_MIGRATION in transaction SA38 , you should be able to get a table which lists the "reporting authorization Objects for migration".

Please read the BI security guide , there is a lot of steps involved in doing this you have to be very careful, analyze, understand and perform the steps.

If remember correctly this step should have been performed before upgrade, I am not very sure for the Netweaver EHP upgrades/installs

[Former Member]

AJ,

You may need to run SU25 after the upgrade immediately or anytime later

RSEC_MIGRATIOn

it migrates the old reporting authorization concept to the new analysis authorization concept in BI 7.0

As you said you are already in EHP 7.0 moving to EHP 7.1 (We just upgrade BW sytem from NW Enhancement Pack 7.0, SP-7 to NW EHP 7.1, SP Stack 7)

Thanks,

Sri

[Former Member]

Thanks Guys, appreciate your helpful answers.

[Former Member]

Quick Qustion Guys - We never changed any default SAP proposals in SU24 on BW system, when performed step 2B i got message which said 'Comparison is not Necessary' which I understand.

I am planning to make changes/generate all roles which got affected with SU25 step, and transport them to further systems QAS and Production (As we dont cutomize SU24 checks, do I still need to perform step 3?)

Thanks in Advance.

After reading the help document, I think I dont need to perform Step: 3 (PLEASE CORRECT ME IF I AM WRONG). I am sayint this because:

Step 1: I did not do this step as we already used PFCG

Step 2A and 2B: This was not required as we did not customized auth checks, we use SAP proposals.

Your Thoughts?

Thanks

Edited by: AJ on Jul 28, 2010 5:37 PM

[Former Member]

AJ,

Abundant posts for SU25 is available in the forum.

just use the keyword SU25.

[former_member275658]

Hey AJ,

To make it consistant, we need to execute Step 3 ( best practice ) and move it to QAS.

But I dont know, if there is any dependency between the transports. If step 3 transport need to move first before moving the mass transport of roles.

Thanks,

[Former Member]

Roles generally only add authorizations for objects in checks.

SU24 (with upgrade and SP data via step 3) generally only add documentation (check indicators) and proposals (check/maintain) so the development system is "leading" in that respect and you have already done this in the step 2 tasks.

But... there is a special case for collisions: namely when SAP proposes a "no check" indicator for an object.

My advise: Create a transport request and collect the proposals in them until a "no check" appears. Have one central transport for it and release it after correcting the roles which are impacted by the context specific check. Good luck with that in your custom developments...

In the rare case that you want to activate the check again for that transaction or SAP did, you must ensure that the role transports go through first.

For other scenarios of accepting all SAP's proposals it makes no difference so you can send the transports through afterwards, as long as you are not opening roles in PROD etc and have not maintained SU22 (a big "no no") nor SU24 in PROD directly.

Your friends here are the USOB_CD* tables and another obscure one - the name of which I cannot remember at the moment.

Cheers and good luck with the upgrade,

Julius

[Former Member]

Hi Julius - Its been a while, I did not bug you with my quetions

Back to Discussion:

SAP Help says:

Step 3: This step transports the changes made in steps 1, 2A and 2B

My Landscape:

Step 1: I did not perform, as we are using PFCG in earlier version.

Step 2A: i performed it, for comparison.

Step 2B: Comparison is not requirded as we did not change SAP proposals in earlier version

My Question:

1) Do I need to perform step 3?

2) Is there any step that I should do on QAS and PRD, apart from transporting corrected roles?

I referred back earlier posts did not find any, my case is bit unique as we use SAP proposals and never changes Su24 checks before.

Thanks Again.

[Former Member]

The difference with step 1 is only that it "resets" everything (SU22 --> SU24). If SU24 is empty then running step 2A for the first time basically does step 1, except that the system does not know it.

Yes, you should perform step 3 for the special reasons I already mentioned.

It can even happen that some sets of roles are not created or maintained in DEV - particularly so if customizing has drifted ahead into non-DEV systems. In QAS and PROD it is always usefull (and suprising) to check that no roles have been created or profiles generated. This can happen from time to time and you should check the number ranges from time to time. Upgrades are an opportunity for this. The ranges are defined in table AGR_NUM_2 and a search on this will show you what to do and take care of.

Cheers,

Julius