When a new user is created or moved into the OU, that has an nrfContainerAssignedRoles (I think that is the full name) attribute, Roles and Services (RRSD) Driver gets an event, looks at the entirety of the user, and figures out what Roles and Resources the user should have.

So the OU assigned Role is one of those things the user should have. 

When you assign the Role to the OU I think RRSD will trigger and reproccess all users in that OU, so if it is big, maybe don't do it mid-day...

Geoffrey,

Thanks for the explanation.

When I first assign the Role to the OU, is there a way to limit the RRSD to reprocess to certain users, as I do not want to interfere other users.

Regards,

Keng

Not really.  This is a limitation of how RRSD works.  It sees a single event and processes it, but that event fans out to possibly thousands of users that could be affected and that single event ties it up. 

Some of the multithreaded stuff will help, as after it considers the changes needed to all the users, and generates request objects for each change required.  These can be multi threaded.  But that first event is a killer.

Probably the best reason not to use this approach.  Removing it later has the same cost.

Geoffrey,

So better approach is don't use this type of Role Assignment and use Policies to assign Role to User (without using manual UserApps method) ?

In the case of AD Driver, where is the best place this Policy ? ETP ?

Or use a Loopback Driver to assign Role ?

Regards,

Keng

Generally better to do it in a seperate driver than the AD driver.  I.e. Manage the role assignments in a different driver than the one that implements the assignments.