CUA users are locked during implementation

[Former Member]

Hi,

i was implementing CUA in the development environment.

I followed the same procedure mentioned in the Cook book.

When i completed the procedure suddenly, most of the users got locked.

It Locked Globally. Pls let me know why this has happened.

It is very critical. If this is the case, do we need any down time for the CUA implementation.

Kindly advice.

Thanks ,

Subhashini.

[Former Member]

Hi,

If you do a search for CUA + locked, the first result will give you an OSS note than has fixed this problem for another forum member.

[Former Member]

Hi Alex,

When I searched , I got the following SDN link.

Is this thte link you are mnetioning, I also found that the correction details were not available in my system.

Kindly advice can we go ahead and implement the mentioned note 1317803 in the CUA system.

Thanks ,

Subhashini.

[sdipanjan]

This kind of scenario happens in any of the following cases:

1. Your settings for Global and Local maintenance of User data is incorrect in SCUM transaction of central system.

2. Before user transfer your Company Address synchronization was not done correctly and Central system is not in sync with child systems.

3. Few of the User ids (mainly DDIC, SAP*, SAPCPIC) doesn't have address data maintained (Last Name is missing).

4. During the time of User transfer someone was maintaining some user ids which were Locked in Lock table with an Enqueue Work process and thus the Dialog WP couldn't manage to flag one more Lock entry against the tables getting updated by this user transfer.

5. Same user ids in Central system and Child systems have different values in Address Data.

You need to check which one is true and restart the activity from the TCode SCUG by deleting the affected Child systems first.

Let us know any more help.

regards,

Dipanjan

[Former Member]

Hi Dipanjan,

Thanks for your reply....

The users with different first name and last name during synchronization are coming in different uisers tab and i was able to synchronize without any problem...

when i did for the developemnt environment aroun 50% users were globally....

After that note implentation i tried synchronizing the users in a sandbox client...out of 935 users 38 users got locked....

I was not able to trace out the problem, eventhough the ratio of users locked has reduced.

And Also for some users, in the status it is showing not locked. but in the child system it is showing as locked globally.

pls let me know why is this happening...

if this is the case...how can we go ahead and do this in the production environment.

Kindly advice.

Thanks,

Subhashini.

[sdipanjan]

> The users with different first name and last name during synchronization are coming in different uisers tab and i was able to synchronize without any problem...

>

> when i did for the developemnt environment aroun 50% users were globally....

>

> After that note implentation i tried synchronizing the users in a sandbox client...out of 935 users 38 users got locked....

>

> I was not able to trace out the problem, eventhough the ratio of users locked has reduced.

>

> And Also for some users, in the status it is showing not locked. but in the child system it is showing as locked globally.

>

> pls let me know why is this happening...

> if this is the case...how can we go ahead and do this in the production environment.

It seems too many things have been coagulated. So I would suggest for a fresh approach from beginning. Please follow the below steps to perform a fresh CUA setup from the point where you are currently standing:

1. Run RSDELCUA in the Central system and select all the Child systems in Input. This will sunset the CUA make all systems standalone as before.

2. Check all the systems Individually to find out the list of Locked (during your CUA Set up) user ids. you can do this by running report RSUSR200 or by extracting table USR02.

3. Unlock the user ids.

4. Run RSADRCK2 in all the systems. This will take care of the user ids without address data (missing Last Name field).

5. Test all the RFC connections to make sure that they are not affected with the user id lock happened.

6. Go to TCode SCUA -> Add the Child systems there -> Save and it will perform Text comparison automatically for the first time. Check the color legend of the traffic signal representing the successful saving.

7. Go to TCode SCUM -> Maintain the Global Parameters according to your need by abiding the SAP help or CUA Cookbook.

8. Then go to SCUG Tcode and perform Company Address synchronization for all the child systems even if you didn't create any company address.

9. After you see that all company addresses are in sync with Central system in the Child systems you need to redistribute them to the child systems (unless they are all showing Already Central ).

10. Transfer the users.

regards,

Dipanjan

[Former Member]

Hi Dipanjan,

pls find below the results we got according to our scenario.

1. Your settings for Global and Local maintenance of User data is incorrect in SCUM transaction of central system.

we have not made any changes in the distribution aparameters. the standard values only we have maintained.

2. Before user transfer your Company Address synchronization was not done correctly and Central system is not in sync with child systems.

Company address is not maintained in our case. So i think this is also not the problem.

3. Few of the User ids (mainly DDIC, SAP*, SAPCPIC) doesn't have address data maintained (Last Name is missing).

users with last name missing, users is not at all moved...error is coming to maintain the surname.

4. During the time of User transfer someone was maintaining some user ids which were Locked in Lock table with an Enqueue Work process and thus the Dialog WP couldn't manage to flag one more Lock entry against the tables getting updated by this user transfer.

5. Same user ids in Central system and Child systems have different values in Address Data.

The one thing i was able to see that for users who ahve not logged in after the user creation were logged....

and for those users who have not logged on to the system such users were also locked.

Kindly advice .

Thanks,

Subhashini.

Edited by: Subhashini Krishanan on Sep 30, 2010 11:37 AM

[sdipanjan]

> 1. Your settings for Global and Local maintenance of User data is incorrect in SCUM transaction of central system.

> we have not made any changes in the distribution aparameters. the standard values only we have maintained.

>

You should check the Lock parameters in SCUM transaction. From SAP help documentations as well as CUA Cookbook you can find out the description of each point for SCUM. Please make sure that you are on the right track.

> 2. Before user transfer your Company Address synchronization was not done correctly and Central system is not in sync with child systems.

> Company address is not maintained in our case. So i think this is also not the problem.

>

Even if you don't have customer specific Company addresses created still you have to perform the Address synchronization as a mandatory step before user transfer. A default company address exists in all systems. I suspect you missed it.

> 3. Few of the User ids (mainly DDIC, SAP*, SAPCPIC) doesn't have address data maintained (Last Name is missing).

> users with last name missing, users is not at all moved...error is coming to maintain the surname.

>

Before adding the child systems in Distribution Model, this need to be fixed. Please run the report RSADRCK2 in all systems to update such kind of user ids.

> 4. During the time of User transfer someone was maintaining some user ids which were Locked in Lock table with an Enqueue Work process and thus the Dialog WP couldn't manage to flag one more Lock entry against the tables getting updated by this user transfer.

> 5. Same user ids in Central system and Child systems have different values in Address Data.

>

> The one thing i was able to see that for users who ahve not logged in after the user creation were logged....

> and for those users who have not logged on to the system such users were also locked.

>

For this point, I don't want to comment. As it depends on the scenario I described in the previous post.

Let us know for any more question.

Regards,

Dipanjan

[Former Member]

Hi Dipanjan,

Thank you so much for your advice....

I will do the same as you mentioned.....

will let you know soon whether it worked or not...

Thanks,

Subhashini.

[Former Member]

Hi Dipanjan,

I have followed the same procedure as you have mentioned.

Everything is Ok. there were no lock problem now. only few users has some problem but that is manageable.

while synchronizing, the distribution alone is not taking place properly.

And also, when i used remove invalid assignments i could able to see that old profiles are deleted.

Is it safe to use the option.

Thanks,

subhashini.

[Former Member]

Hi Dipanjan,

The synchronization problem is also resolved now by assigning a Authorization object to the communication user.

Now I was able to successfully setup CUA.

Thanks for your inputs.

Thanks and regards,

Subhashini.

[sdipanjan]

Hi,

Great to hear that. Have a nice day!!

regards,

Dipanjan