We created an aftermodify [1] powershell rule to update manager attribute for their active directory account. But it seems for every identity the powershell rule need to be executed once.
So it took too long time and customer receives the following error message.
sailpoint.connector.ConnectorException: java.lang.InterruptedException: Timeout waiting for response to message 93 from client xyz after 600 seconds.
It seems to be timeout error and we can not increase the provision timeout over 600 seconds.
We tried to use Start-Job but it does not work.
Please help to confirm if the powershell rule could be run in background?
It seems to me that you should be able to use Start-Job in the after create rule definition (not in the Powershell script that is called). I am pretty swamped, if I can, I will try to experiment with this in sandbox.
Another option would be to have your after create script call a simple function to write the data needed to a flat file or a SQL table, then have another script launched by the Windows schedule on the IQService server that picks up the data and performs the task. The after create script will return right away, and then there will be a little delay until the other script is triggered and updates the data.
Why are you using an after modify rule to update manager? Have you tried adding an identity attribute to hold the manager’s AD DN, and then map that directly to the AD manager attribute? That way, attribute sync can be used to keep it up to date, and each operation will be its own non-sequential operation.
I’ve seen this work well when there are no other options. Since this approach is not going to provide failure insight within ISC, it would be wise to include some failure alerting within the scheduled script. You can have it trigger a workflow with an external trigger on ISC to send the email so that it still comes from ISC.
Becasue we need to use advanced filter which can not include the manager attribute in account schema, so we decided to use aftermodify rule to sync the manager attribute.
The connector supports advanced query filters like endsWith, NOT, and NE during aggregation. The Azure API does not support the advanced query filters while also using an expanded attribute such as manager in the URL. When using the advanced filters, ensure that you remove the manager attribute from the account schema and remove the owners attribute from the group schema.
I think if powershell run in background does not work.
Is it possible to create a workflow to catch the identity mananger attribute if it is changed and call entraID api to sync the entra ID mananger attribute?