RFCs not working after Refresh, is this SecureStore issue?

[Former Member]

In our landscape we do frequent system refreshes (DB copy). we use to take out RFC table export and then import them back after refresh. every thing was fine till we upgraded to Netweaver 6.0. Now after refresh most of rfc donesn't work (one which have user ID/ Password in them).

Here is my findings till now:

When we goto SM59 and RFC maintenance screen it give below message:

bold "User Password invalid for identifier /RFC/CCMS (see Long text)"

============================

This is what long message is"

Message no. SR128

Diagnosis

Changes to the global key or system data have invalidated the passwords in secure storage.

Procedure

Enter the user password again.

Procedure for System Administration

You can find detailed error messages for the specified ID in transaction SECSTORE.

======================================

In secstore transaction I found this message for entry:

"System-dependent data for entry /RFC/CCMS changed: TRS / WTH"

Long text for this is:

System-dependent data for entry /RFC/CCMS changed: TRS / WTH

Message no. SECSTORE031

Diagnosis

When accessing the secure storage, the system detected that system-dependent data (installation number or system ID) had been changed.

Entry data: TRS

Current system data: WTH

If you receive this message during a migration process, the "Current system data" field contains the old specified system data instead of the current system data.

The content of both fields can also be empty, if the system cannot determine the data in the current context.

System Response

It is no longer possible to access entries that were created with the previous data.

Procedure

Contact your system administrator.

Procedure for System Administration

For more information, see SAP Note 816861.

========================================================

When I check the note it talk about the system copy and migration key, release key. I don't think this is valid in our case.

Now I tried to find out the tables where secstore stores its data:

RSECACHK Table for Controlling ABAP Programs

RSECACTB Table for ABAP Access Authorization for Secure Memory

RSECTAB Secure Memory: Memory for Encrypted Data

At present we backup following tables:

rfcattrib

rfcdes

rfcdoc

rfcsysacl

Please advise if anybody faces the same issue? does anybody have any solution any notes?

Edited by: Madhusudan Bansal on Oct 22, 2008 9:46 AM

Edited by: Juan Reyes on Oct 22, 2008 1:24 PM

[Former Member]

I could able to find the tables which I need to backup before refresh and it's working now.

[mubarakshabna_asmi]

Can you please list the tables.

Thanks

Shabna

[Former Member]

I am putting all the tables related to RFC which we Export/Import.. also please note you have to clean-up all the tables before importing the data back.. otherwise the secstore thing will never fix...

RFCATTRIB

RFCDES

RFCDOC

RFCSYSACL

RSECACHK

RSECACTB

RSECTAB

[mubarakshabna_asmi]

Thanks for your time.

Thanks

Shabna

[Former Member]

We tried this approach of exporting all the below tables and imported them back after refresh. We are still facing the same password inconsistent issue. Please advise.

RFCATTRIB

RFCDES

RFCDOC

RFCSYSACL

RFCTRUST

RSECACHK

RSECACTB

RSECTAB

[raoul_serra2]

Hello Rajesh.... as mention before by Madhusudan, you may need to 'truncate' (clean-up) those tables before importing back the data

[Former Member]

I too have a similar problem. Any solutions ??

Thanks

[former_member200234]

We do also an export from table RFCDES, and after the systemcopy an import.

In all R/3 connections with password the password is "Invalid" and we need to edit it manually.

So also we want a solutions for this issue.

Marco Krijt

[Former Member]

This is new function of abap kernel.

Solution is in note 816861

you need to get migration key for secure store migration from service marketplace.

Then run secure store migration thru TCODE SECSTORE.

All users/rfc are valid after that

[Former Member]

Hi,

We are also facing the same issue with RFC destination passwords after refresh.

Please let us know if you have any solution fo this.

Thanks,

Tanuj

[debasissahoo]

Hi Madhusudan,

I don't think its something with the secure store issue. This might be something related to the lower case or upper case of the password which happens in some release and kernel patch level. Try to search for notes, there are some notes which specifically tells about this thing related to RFC.

hope this helps

Regards,

Debasis.

[Former Member]

Thanks for reply, at least someone put some suggestion in this.

we already took care of this while we did upgrade and make all RFC passwords in Upper case. Another question to ask if this is case issue then why were these working before refresh.

and moreover in the message I posted it was clearly mention that Securestore data has changed with invalidate the password. reentring and saving password resolve this. but why is it coming at first place?

[debasissahoo]

Hello,

if it was working before refresh and you took an user export of the system and imported it back after refresh then it should have worked... was the user import done back to the system?

Regards,

Debasis.

[Former Member]

Hi Madhusudan,

Your log is saying , your system data has been changed.

Please check the note 522536 and 520039.

If you are confirm that the above is not your senario then you can check the note 521295 also.

.

Hope this will help you.

Thanks & Regards,

Satyabrat

[Former Member]

I checked all the notes and tables. every thing is correct.

What I think wrong is when we do refresh at that time. SS (secure store) tables from source system come here! we just export and import RFCs but not SS.

All I wanted to know is If we export and import SS tables will this resolve our issue?

can you tell me have you ever did refresh for netweaver? did you face this issue?

appreciate your help

[Former Member]

Hi Madhusudan,

I didn't face this type of problem still now.Have you check the note 828529,and also refer the note 1016348 for an idea on use of secure storage.

Thanks & Regards,

Satyabrat