Hi Ricardo
The CUA stores the SU01 information of the users that is replicated to the child system. It will not, however, store the non-global/redistribute fields as per SCUM settings, passwords, etc.
Alex already beat me to the reply but I'll add my reasoning for the copying - in particular when the refresh is different environment.
I worked on a large user base system (100k+ users) and they did refreshes quite often. One one refresh this place decided to copy Production Enviroment to QA. The issue from a security perspective is that not all Production users has QA accounts. In this particuarly situation, Production was the 100k+ whilst the QA was only about 15k (numbers made up but you get my point for the size I was dealing with).
As a result, there were 85k users in QA that were not required. In addition, the roles assigned to the users were different between the systems (production access were different roles and much more restrictive).
To "sync the CUA" the following was done
- All NEW users were imported to the CUA via transaction SCUG. This repesented 85k users. However, this meant 85k x 3 IDOCS (USER, ROLE, PROFILE) on a dialogue work process --> very time consuming
- All the NEW users then had to be deleted out of the system - that's another 85k x 3 IDOCS going back the other direction. Deletion executed via SU10 which also took time
- All EXISTING USERS - were then redistributed to the child system (use SCUL or mass resend program RSCCUSND) which is 15k x 3 IDOCS for the specifc system. This would then overwrite the role assignments based on the entries in the CUA USLA04/USL04 tables and resend any users that were maintained whilst the CUA was disconnected during the refresh.
We never did all of these activities. In the end I had the CUA disconnected and I deleted the rest of 85k users out of the child system to avoid steps 1 and 2. It involved a heap of table extracts to manually identify users to keep vs deleted as well as more extracts to reconcile that pre and post refresh matched. Not fun!
In addition to all of this, users then had to use their Production password instead of their QA one. Change documents for the system were then Production instead of QA. Finally, a heap of change documents written to remove the Prod roles and reassign the QA
The example I gave was due to an operational procedure devised for client refreshes within a system instead of cross-environment. Unfortunately, this refresh was a bit different and no-one stopped to question the approach was appropriate until it was too late. By then, the additional users were in Prod and had to be cleaned up.
The option I recommended - Basis disconnects the CUA, takes the client export of the users, does the refresh, re-apply the users, reconnect the CUA and then distribute Idocs in SCUL to clear any errors (some would depend on SCUM settings).
Regards
Colleen