The general procedure is to delete the CUA before performing any client copies/system copies within a CUA landscape.
This is not necessary in every case. Here is a suggestion, of how to proceed. Please don't count on any support by SAP if you proceed like suggested. You do this on your own risk.
Scenario:
Copy one client of a CUA child system to another client within the CUA landscape (CUA child) keeping the original users in the target of the copy.
In this example PRD is the source and SBX the target of the copy.
1) Clean up any (userclone) IDOC's related to SBX or PRD.
2) Delete both DEV and SBX from the central CUA system, using
RSDELCUA in PRD, SBX and in the CUA central system.
3) Backup PRD
4) Export user and authorizations from SBX clients by means of a client
export transport.
5) Restore PRD backup to SBX and do all the post steps for renaming,
etc. (especially BDLS!!!)
6) Import the users and authorizations from the client export (step 2).
7) Check any RFC's or logical systems that are required for CUA.
RFC destinations should be available, but better check.
Logical system names should have been adapted using BDLS in step 5.
8) Execute SCUA on the central CUA system to add DEV and SBX back
into the landscape.
9) Execute SCUG to transfer the users back into the central CUA system
Please see notes 197728 and 565697 on RSDELCUA, and notes
544509, 121163, 369758 and 446294 concerning BDLS and
399917.
Steps in detail:
Source: PRD-System
Target: SBX-System
You will find some points like ‚disconnect RFC'. With this the technical disconnection regarding RFC is meant.
To assure data consistency, you have to take care, that during the actions _No_ changes in the CUA central system regarding the CUA itself or users are performed. It is a good idea to lock SU01 and SU10 for that time.....
Another precondition is, that both systems are on the same basis support package level. (note 449822)
Let's start:
1) execute Reports RSADRCK1 & RSADRCK2 (first in test mode) to identify any existing address problems and clean them up (note 94104)
2) in the CUA central system: assign a special user group to all users of the SBX for later identification (SU10), for instance SBX100 for users of The system SBX client 100. The group can be defined in TX SUGR. Check SCUL - make sure, that all Users (Idocs) have a 'confirmed' status.
3) Export Users with Tx SCC8 and Profile "SAP_USER" from SBX (roles are exported too)
4) disconnect RFC of CUA central system (from now on no actions in the CUA central system! If possible, disconnect RFC by means of hardware disconnect)
5) Perform system copy from PRD to SBX
6) disconnect RFC for SBX
7) delete CUA completely in SBX (all clients!) with report "RSDELCUA" (!Not in the CUA central system!) (note 565697 - SE38)
8) Reimport Users and roles of the User export in SBX with TMS and perform post Steps in SCC7
9) adapt rfc-connections in Tx SM59 in SBX and CUA central system
10) Execute Tx BDLS (possibly in all clients of SBX) (Remark: for the CUA only the entry in table T000 is important.) (note #369758)
11) delete the ALE model for CUA in all clients of SBX (Tx BD64) (this step may not be necessary if the model itself is not changed (=same CUA landscape))
12) reconnect RFC in SBX and CUA central system
14) redistribute the CUA model from the central system ( Tx SCUA ->edit -> save)
15) in CUA central system: SCUM -> change any setting (it does not matter which one) and save. Undo your change and save again . Only upon a change the data is synchronized to child systems.
16) select all users with SU10 based on the usergroup assigned before (SBX100); Assign or delete a non existing role to that users for SBX. A popup will appear, that the role does not exist. Now press 'cancel'. The users will get distributed now.
Now your CUA should work again.
Good luck.
No comments:
Post a Comment