Mass transport in production caused users lost access

[former_member275658]

Hi Gurus,

We sent a mass transport to production system and the users reported that they lost access to transactions. When we checked, it was user comparision issues in production as the user master data showed red roles for users. We ran PFUD for all the roles in production which corrected the issue. There is an background job scheduled daily at 1 am.

But, we have to find an RCA for this. Why this happened as we never faced this issue as we did mass transport previously in production.

Any idea, why we need to run PFUD after transport ?

Please advise.

Thanks,

Salman

[Former Member]

Is it possible that when the transport was created, the "User Assignment" checkbox was selected by accident?

I've never done it, but this would transport the roles with their corresponding user assignments in dev, which would then mismatch with the role assignments in the Prd system.

Since I've never done it I can't be sure that the symptoms you describe are what you would see, but it's the first thing I would check.

[former_member275658]

No, transport was created with uncheck on user assignment.

This mass transport contains some roles which we deleted as part of garbage roles along with new roles. Is that the reason it occurs and users looses access till we run PFUD ?

Not sure, why it happened, I never faced this issue whenever did mass transport for roles.

[Bernhard_SAP]

Hello Salman,

first of all: whenever you import roles (with profiles), you need to run the user comparison (PFUD) so that changes take effect (new authorizations need to be added, outdate need to be removed from user buffer).

If you had no problems in the past w/o running pfud, that is more a coincidence.

second:

but what I have seen already is, that such problems can occur, if SAP note  #1614407 has not been implemented into all systems of your transport landscape. As this note improves the transport function, its recommendable toapply it soon.

b.rgds, Bernhard

[former_member275658]

FYI, We use customized profiles instead of default profiles inside the roles.

When we transported the roles some roles had default profile names instead of custmized profile names in production and devlopment had the customized profile name. Also, users reported loss of access instead of running PFUD manually. The issue was derived roles got messed up so we pushed all the derivations through the master roles to resolve this issue in production

We use catt script to update the profile names to our naming convention.

Why this issue didn't appeared in  QAS testing. Please advise if anyone has faced this issue.

Regards

Salman

[Former Member]

Renaming profiles is very silly...

You should reset the number range in table AGR_NUM_2. Then clean out the old names which are colliding and generate new ones. That will solve the problem.

Cheers,

Julius

[former_member275658]

Thanks Julius! I agree renaming profiles is silly. I have to find RCA for what caused us to run pfud manually and adjust the derive roles. Is the RCA = due to collision between old profiles and new custom profiles in production??

[Bernhard_SAP]

pls see my memo above.

there is a remark in the said note 1614407:

Important:

For technical reasons, you can no longer transport roles with generic

profiles in the same request as manually created profiles and

authorizations after you implement the correction. Their data is deleted

when the request is released.

Maybe there is a relation to that, if you have applied that note already in the DEV system of your roles...

b.rgds, Bernhard

[Former Member]

Dear Salman,

I have faced this sitution sometimes back, this generally happens when the role in transport is too heavy (i.e. multiple profiles exists for a role) or the transport has too many roles (profiles) inside and yes regenerating the parent role and passing on the updated authorization to all derived role and then PFUD is the correct solution to regain lost access.

Possible reasons for this Glitch (Please check and put relevant one in your RCA)

1. Please check if your transport was the latest transport to be imported to production for every roles inside it, just to be sure that your changes has not overwritten some old necessary changes changes.
2. Since you have transported so many roles, this glitch may occur if the role was being imported to production the same time it was being modified in dev box. I mean to say there is a chance of authorization loss in profile when its transported and updated simultaneously. Please check the transport logs and change logs for the concerned role. If it is colliding then it could be the reason.
3. Some times this is due to issues in transports. (Basis issue so I cant comment for this case) .

Hope this helps,

Regards,

Amit