Upgrade 46C to ECC 6 0 STEP BY STEP ---Developing

[Former Member]

Now the upgrade has reached the "POST Upgrade Steps" which means Its open to the SECURITY ( Authorizations ) to come in.

1. First I have doing the SU25.

Question -->Do I need to run (1) on SU25 .

Answer:NO this is only for IInstallation of PFCG. for upgrading to higher releases only Steps 2 down are needed.

Please correct me if I am wrong or have additional information which you want to share

[Former Member]

Here 2A was executed...no problem. went well

Now In 2B I get a framed screen

On the right its the status colored red against the TCD ..any idea what needs to be done here ?

On double clicking the status I get on the right frame the status and the object --> The Check Indicator.

What needs to be done here ? Any expericences??

Edited by: george G on Aug 27, 2008 9:03 PM

[Former Member]

Hi George,

For security upgrade u need to do following steps :-

First run the SU25 2A, 2B ,2C, 2D steps successfully.

2A and 2B steps just compares the old system tcodes and new system tcodes.

Step 2C - shows the list of roles that are affected in upgrading.

Step 2D - shows the new tcodes introduced in new systems.

First complete the 2C step, click on one by one role it will get the screen of authorization objects , where as u can see the new authorizations that are got addeded.

There are three types of new authorization objects get introduced while upgrading :-

Standard New - it is the standard authorization objects introduced for corresponding new tcodes.

Manually new - It shows the authorization objects which were manually added in old system. Some of the values got updated for this also.

Standard Updated - Updated means , in old system if you have kept the standard values as it is, SAP has updated these standard values( u can check this one in SU24 check indicators).

After maintaining all new authorization objects , you can save it and generate the profile.The back to SU25 2C step shows it as green signal.

SU25, 2C step also contains the new SAP roles introduced.

After generating all profiles in SU25 2C step, you can jump to 2D step.

SU25 2D step-

If you execute these step, it will show the list of roles and old tcode and corresponding new tcode.

If business wants to use new tcode , then u can replace old tcodes by new one by clicking on automatically adjust menu. Otherwise go to manually adjust menu and generate the profile.

The new tcodes are introduced in 2D step , this doesn't means the old tcodes are no longer exists in new system. We have to check manually for each and every tcode.Some tcode does not exists in new systems. FOr e.g. RZ02 is replaced by RZ20 in ECC6. RZ02 no longer existss in ECC6.

[Former Member]

Sneha !!

Dont know if must congratulate you or Thank you - but here is both !

I have finished 2A & 2B --> Fundamentally I had ' Nothing to do " here !!

I am now maintianing the roles in 2C.

My question is once I maintian the roles each one by one in 2C, I dont have an option to transport the roles.

Are these transports done on step 3 ??will all my green colored roles go ??

Or Do I do this in PFCG ??

I searched the WEB/ Posted many questions but you are the first one to give an indepth reply. When none was replying I wanted to create a complete auth up grade document and give it to Julus ( may be he could learn too!!) This contribution of yours I will include !

Thanks again !

[Former Member]

Hi,

In any upgrade you should check the contents of the table PRGN_CORR2 that "drives" the SU25 process.

I have done upgrades before and then found that PRGN_CORR2 was actually missing values, so roles and transactions that need to be upgraded are not shown when you run step 2.d

OSS note 991377 contains two "must read" files of transactions that might not be in PRGN_CORR2 or have been replaced, sometimes without a replacement transaction.

Checking the contents of this table before you do much more on your role upgrades could save a lot of pain during the regression testing of your revised roles.

If you are on a fairly up to date support package level you might be ok.

[Former Member]

Good ! We are up to date on the support packs but the info was unique and supportive glad that this posting itself is developing itnto a total security upgrade.

T

[Former Member]

Hi George,

To transport the roles , I have done it through PFCG only.

Step -3 transport the initial customer tables. If you tranport through PFCG , then it will be better.

Many thanks,

Sneha

[Former Member]

Sneha,

After 2C, I do the following :

1> Go into PFCG and and maintain the roles there.

2> Put the role in the transport

My question at this point are the follwoing:

A>Do I need to maintian it in step 2c itself or what I am doing in PFCG is right ?

B> Once I complete the maintaining in PFCG and putting it in Transport, when the Next Box is upgraded Do i need to again go through the whole su 25 again -- I guess not

C> Do I need to do the step 3 ?- Its again a trnasport but I f I am doing it on PFCG then I cando away with this ??

Thanks

[Former Member]

Hi George - I am on the same page as you are, however I completed this task few days back - want to add what I analysed to answer your questions:

A> You will meet your task either way, for instance if you click the role with red light in Step:2C...it will take you to Maintain 'Authorization' tab- Change Mode within PFCG. So either way you can Edit and Generate role, but I would suggest you to dowload to local file and work 1by1 in PFCG so that you can keep track of work and make some notes.

B>It depends on how your Basis defined Transport Route between clients, In our scenario role transport from PFCG will move roles from DEV-QA-PRD..net..net..what I think is there is no need to run SU25 again.

C>If you follow above steps than I would suggest you to skip this step as PFCG role transport will take care...However if you decide to Generate roles under Step:2C, its wise to perform step 3.

All the Very Best.

Thanks!

[Former Member]

Hi,

From an " Audit " perspective how did you all handle this upgrade , scope of this discussion limited to the security part ?

What did the auditors want to see ? how did you keep yourself safe ..etc

[Former Member]

all the posts in this thread seems to be referring to some document. can you please tell me where this document is located. this thread is very interesting and I definitly want to know more about it.

thanks all

[Former Member]

The "documentation" being refered to is the "Information" button in transaction SU25 and the application help for the same transaction.

For a major release upgrade, and depending on how your legacy roles were built, such a change is also an opportunity to start over again... as the SU25 steps will only upgrade "intact" roles and there are many days, lessons learnt and some program errors between 46C and 7.00.

Cheers,

Julius

[Former Member]

Hi George,

To keep yourself safe , and from audit perspective , it is always good to perform upgrade on Dev and test system. While transporting any role changes to production follow the same change management procedure. We have taken proper approvals for all the role changes we have made during upgrade.

Regards,

Sneha

[Former Member]

Yeah I agree there is lot of Info on SU25 this pertains to "actual upgrade" also the auditors are very particular on the "risk " as in SoD/ GRC. We can take an " before " and "after" snap shot and then adress that.

I am doing it on dev ( two of them ) and others on lansscape

I am also developing the documentation from Audit perspective-- shall share it here - If Juluis agrees

Glad that so many are being benefitted by this post !

[Former Member]

> If Juluis agrees

No necessity for me to agree. I only maintain a negative list of things not to do...

I would recommend using a wiki for this. That way we can collaborate in building it further.

Cheers,

Julius

[Former Member]

On the lighter note-- we will need to put Juluis on the wiki too ! infact we can do away with all the entries on the wiki and place julu there !

[Former Member]

Julius, George and all, I have one issue that would be a part of this discussion.

My client is going from 3.1H to ECC6.

I have gone through most of the above steps successfully and have the following issues.

The profiles from 3.1H have been converted to roles. The conversion process has created profiles for each role and I can go in and examine the authorizations and generate the roles. However ...

1. The role names are not very useful. In order to make them useful, I need to align them with a role naming convention. Some of the roles have / in them, which PFCG complains about and I can't rename or otherwise edit or view these roles.

2. For the remaining roles, when I copy them into a new name, and go into the authorizations tab, all the objects have been inactivated and I can't activate them. In the converted role, they are green or yellow, whereas in the copy from the converted role, they are inactive.

My colleague suggested that I attach the original profile from the converted role to the new role. However I haven't had to do that before so I don't know how I would go about it.

Any suggestions?

Thanks,

Santosh

[Former Member]

> 1. The role names are not very useful. In order to make them useful, I need to align them with a role naming convention. Some of the roles have / in them, which PFCG complains about and I can't rename or otherwise edit or view these roles.

You cannot rename roles.

Either copy them into a permitted namespace without the special characters or maintain an entry in table PRGN_CUST ID = 'PFCG_NAMESPACE_CHECK' and PATH = 'NO' to relax the check.

If you have any old profiles with the character '*' in their name somewhere, then you must be very carefull.... please check!

> 2. For the remaining roles, when I copy them into a new name, and go into the authorizations tab, all the objects have been inactivated and I can't activate them. In the converted role, they are green or yellow, whereas in the copy from the converted role, they are inactive.

This indicates that the manual authorizations are in a really bad state and converting profiles which use them to roles is not a natural candidate, if ever...

The profiles are successfully generated when ALL fields to be maintained and org. levels are complete. Try completing this step in the converted role before copying it.

> My colleague suggested that I attach the original profile from the converted role to the new role. However I haven't had to do that before so I don't know how I would go about it.

Your colleague is talking nonsense and does not understand roles. Possibly your colleague is the same one who created the individual Z-authorization objects for each transaction code?

Anyway... steer well clear of that colleague as far as authorization managment advice is concerned...

Just being honest,

Julius

[Former Member]

Julius,

As usual, you are invaluable.

First, I use the term rename loosely - I did copy them. Let me clarify.

I copied the converted role to a new role, and in the new role, I experienced the issued I had narrated. As of my posting, here's where I have arrived. Keep in mind, there is a time constraint imposed by my client and so there isn't enough time to do even the minimum except to replicate the old 3.1H authorizations into their ECC system - meaning that they haven't given me time to even do any sanitary changes to the roles.

1. Copying the roles resulted in all the auth objects being inactivated. To resolve this, I created new roles, and then imported the profiles of the old roles into them. This seems to work so that the authorizations are available under the new role name. Note that I can't add many of the authorization objects into a newly created role since they are obsolete and SAP won't let me add them.

2. As far as the role names that have a / in it, I will use the same step as above.

3. Julius, no, this colleague didn't create these horrible authorizations, though his poor mind has been exposed to many of these "radioactive" implementations that have clients who have unrealistic deadlines.

Santosh

[Former Member]

Sorry about the comment regarding your colleague, I guess he had learnt to become "street wise" under such conditions...

I thought he wanted to "hack" the profile name in as a "swap" - that would create a huge mess between the AGR* data and the UST* data in the tables. Importing the profiles is okay, but I guess the roles will be ugly (this is "by design" using the SU25 step 6 route...)

I was curious so tried to replicate this in my system (7.01 SP 6) but could not so I suspect that it has something to do with these z-objects and their definitions. Particularly data elements used and the non-existance of them are likely candidates. Are other standard auth objects modified?

As I already mentioned, "big jump" release upgrades are an ideal opportunity to start over. They are probably doing the same in other areas classed as "workbench objects" and "customizing" so should do the same for the authorizations aspect.

Worste comes worse (which might be better in this case....) is to use the SAP standard roles and copy them.

Cheers and good luck,

Julius

[Former Member]

Now from the Audit stand point.

1. SU25 Gives us both the roles that are affected as well as the Transactions that effected.

Now here is the question from the Auditors:

" Please show us the evidence of what you did which each of the role ?" - I am certian you folks will agree with me that there are innumerable objects that are maintained. All the same I want to do this in a collabrative manner with auditors as they are doing their job.And to them their question is right.

Now my question here is are there any place where I can show the objects " before " the after ? some table etc ?/

Also I dont know if we ought to move this to anotehr topic termed " audit something ??" or post security upgrade processes " -- if so Julkuius please go ahead.

Thanks

[Former Member]

Show them how to use tx RSSCD100_PFCG and let them get on with it.....

[Former Member]

Alex- thanks for your Suggestion, however I doubt if that would sell with the auditors !

Do we have a table which says the objects assocoted with each role ? My idea is I can take a " before " & " After " back up of this -- how does this sound to my collegues ?

[Former Member]

Hi George,

It works if you sell it right......I would give them the tools and let them get on with it. (Something I prefer to do when auditing).

You could have a look at USOBX_CD and USOBT_CD which show the change docs for the SU24 tables. It may show change indicator changes which are a precursor to the updating each of the roles. As there is inevitably some changes you need to do to the roles, they are far better off review the upgrade related changes in their entirety in the context of the roles which have been changed.

[Former Member]

Hi Alex,

You providing with the tools - That approach varies from corp to corp But not all corporations have that approach.

The approach you have suggested looks very interesting however,, I could not browse this table thats mentioned.

I did it over SE16 but not sucessful

Thx

[Former Member]

OK, lets go back to the original question from the auditors:

" Please show us the evidence of what you did which each of the role ?"

The only way they are going to see what changes have been made is from the change logs for the roles. You can look at tables which show differences in the proposal values but they are worthless unless they map 100% to the only changes shown in the roles.

Now, you can either run the change logs or they can, either way it will give the best indication of what changed over the period of the date range.

If your company want you to provide that info then fine, most companies give auditors the access to do it themselves (otherwise how can they prove that the data was not changed?). Insisting on security administrators providing this info is a waste of time in my opinion

A potential alternative would be to set up an RFC connection to the system which your pre-upgrade roles were backed up to and then run a comparison between each role in the backup and the current system. I've not tried this but it is a possibility.

[Former Member]

> The only way they are going to see what changes have been made is from the change logs for the roles. You can look at tables which show differences in the proposal values but they are worthless unless they map 100% to the only changes shown in the roles.

I think this is what GG is looking for, but as you mention there are both system and audit skill pre-requisites.

The auditor needs to know and have confidendence in the before concept if roles are to be upgraded via SU25.

The auditor needs to have knowledge about the release being upgraded to, and which changes would be required (and opportunities made use of to use new features... potentially also redesigning existing roles in new ones...)

And then map the expected changes (that is their job) to the actual ones (the tools which Alex has mentioned).

My recommendation would be to use the "you navigate, I drive" approach before giving the auditor access to do a comparison and get lost on their own, potentially.

That way you know what the auditor is capable of, and the auditor has a better understanding of your upgrade strategy.

For major release upgrades, redesigning role concepts are an opportunity which should not be missed, and I think a reasonable and skilled auditor should understand that.

> A potential alternative would be to set up an RFC connection to the system which your pre-upgrade roles were backed up to and then run a comparison between each role in the backup and the current system.

That could be usefull as well for a snapshot of expected changes between the "real roles" and the upgraded roles in a sandbox, all else (and coding) assumed the same between the release upgrades (which is of course not the case...) It would be helpfull to find transactions for which the coding has officially changed or are now officially the leading transactions for the proposal indicators.

I have not tried that either - but I think it would be usefull information for the functional folks and developers (including role developers).

Cheers,

Julius

[Former Member]

Hey Juluis & Alex-- The post you folks have done has so much for me to think that I am unable to reply as now..but I am really not reading them but studying them - indepth.

Both contains great contents to deal with !

[Former Member]

What I think would be really usefull for everyone would be a list of tasks to do (or check):

- Before the upgrade.

- During the upgrade.

- After the updrade.

... assuming that it is an upgrade from anything less than release 7.00 (including 46C) to 7.00 or higher.

The list should be based on the assumption of a semi-intact authorization concept with some legacy confif and design errors --> with the intention of correcting them conceptually.

I would be very happy to learn from and contribute to such a wiki.

Anyone else interested?

Cheers,

Julius

[Former Member]

Yes Juluis --> This is also what the auditors would love to see !

[Former Member]

Sounds like a good idea.

I will find out who the main SDN Wiki "gardener" is, and ask for a page to be created for the content.

Cheers,

Julius

[Former Member]

I have noticed a strange - (at least to me )- picture..

Backgroud:

During the upgrade from 46C to ECC60 I have not yet maintained this box ie SU25 ..and I see all my roles as " affected due to which its all "red"

However If I go to SU01 and view a user -- the roles are " green "!! More than that the user can perform the task in this condition.

My inference is that - this is made possible by the exsisting " profile " of 46C..and when we go through the SU25 only then the profiles are ECC6.0 ..Am I right ?? or ..any more information is a great discovery !

[Former Member]

> I have noticed a strange - (at least to me )- picture..

Sounds okay to me...

> During the upgrade from 46C to ECC60 I have not yet maintained this box ie SU25 ..

Okay. So the role data is unaffected at this point in time and the profiles are as before anyway.

> and I see all my roles as " affected due to which its all "red"

This is in SU25, right?

> However If I go to SU01 and view a user -- the roles are " green "!!

So you double-click on a role in SU01, in this case you are now in PFCG. The role data, if all maintained - regardless how - is as before...

> More than that the user can perform the task in this condition.

And the profiles as before as well. No reason to stop a running system...

> My inference is that - this is made possible by the exsisting " profile " of 46C..and when we go through the SU25 only then the profiles are ECC6.0.

When you go through the steps of SU25 to complete the upgrade steps for the roles (new check indicators and new transactions...) or when you do a "Read old and merge new" in PFCG to bring in the new SU24 data (and possibly the old data again as well if you have not used SU24 as intended)... then the role data turns red - but the profiles if not generated will still be unaffected, as will the access of the user (unless newer coding is making new checks in the upgraded system where the old profile is still being used).

This might also shed some light on why SAP_NEW was invented, and why it should be deleted completely after each upgrade / support pack.

Think of SU25 as a tool, ontop of a tool (pfcg), ontop of a profile. That is how I try to think of it, to remind me where I am in the system.

Have a good weekend,

Julius

[Former Member]

Here is our wiki => [Upgrade Steps for Security - A quick reference|https://wiki.sdn.sap.com/wiki/display/Security/UpgradeStepsforSecurity-quickreference]

Feel free to add more content to it - I made a bit of a start already.

Cheers,

Julius

[Former Member]

Note to self: no one else contributed to the wiki since 2 years now...

If there is no further interest I will delete it.

Cheers,

Julius

[Former Member]

Hi Julius

Note to self: no one else contributed to the wiki since 2 years now...
If there is no further interest I will delete it

I am stilll new to SDN having been a SAP(deleted) subscriber and also too busy with work to have contributed/viewed much prior to June 2010. I can't say that I have visited the wiki yet but (to me at least) it does seems to be a shame to possibly delete information that may be useful?

Anyhoo...

Just my opinion

Cheers

David

[Former Member]

The problem is that no one has put any useful information into the wiki, bar some structure to it and some search terms which I added when creating it way back then.

I performed a few upgrades last year so will add some more tips&tricks, but would like to see more imput into it - that is the whole purpose of a wiki... otherwise we might as well each write our own notes and keep them to ourselves (without anyone correcting mistakes or improving the process).

Cheers,

Julius

[Former Member]

I've read and re-read this thread and can see my client having a nightmare if they go ahead with the upgrade (now in doubt due to recent events). The steps and actions listed give a good incite into SU25 which I've not used so far - either from luck or bad luck.

I can see what you mean about the wiki - there's not a heck of a lot on that page which is a shame but I don't have the experience to contribute as yet to avoid its deletion but maybe you could hold off deleting a little longer ?

Cheers

david

[Former Member]

Hi David,

Of course I was only refering to the "almost empty" wiki and not this thread.

Anyway, you are correct - we should not delete it but rather encourage use of it and be patient for a few more years (like the www.wikipedia.com folks were

Cheers,

Julius

[Former Member]

Thanks for this thread AND your decision to keep this Wiki up. I am just in the beginning phase of a 4.7 to ECC6 upgrade and this is the kind of information I am looking for. There's a lot of information all over the web but unfortunately there doesn't seem to be a source which would has detailed information available.

In my case, I just inherited the system a couple of months ago. Fortunately it isn't that big, but I'm not liking a lot of what I see.

1 - Systematic use of composites (I know that some of you are OK with this but I just don't see the rewards vs the costs)

2 - Very little maintenance in SU24. (shivers)

3 - A lot of custom transactions / programs, but only about 10% of the programs include Authority_check statements. Haven't found a Tcode with an Auth Object directly assigned to it in SE93 yet.

4 - A majority of the single roles have manually inserted Auth Objects. (Cold sweats)

On the other hand, the role design is pretty much straight forward with regards to Org Level values (we use derived and the separation is done on Company code) and, as I said, it's not a big system so not that many roles.

Regardless, given the situation I'd appreciate any comments you might have to help me prepare and execute the upgrade.

Thanks!