We have an afterCreate rule and script used to create SamAccountName, UPN ,Mailbox and send email to an identity post processing.
When we process and create AD account for more than 10 identities at a time from IDN, AfterCreate script is not getting invoked for some identities out of 10 identities, we could not see loggers in IQservice for identities which were not picked up by AfterCreate PS script
We tried increasing provisioningTimeout to 300 in AD source, still issue not resolved.
Anyone has came across similar issue? Please provide some insights on this will be helpful…
Good morning,
I’m just curious as to why you are doing the above as as afterCreate rather than as a provisioning rule. It seems a complicated way of achieving your results. The email can be sent from the email templates too, bypassing the need for any scripts
You will have 3 options: notifyAccountManager It will send an email to users manager notifyAccountOwner It will send an email to newly created account owner notifyAccountOwnerAltEmail It will send an email to newly created
account owners alternate email address.
You can update the source partially using the API and also using VS code if
you already have configured.
Thanks for your suggestions, we will try for alternate method for email notification
We have some custom logics built to generate UPN , samAccountName in Afterscript,
Hence afterCreate script need to be invoked for proper AD account creation
Hi @sganesan ,
Here are few suggestions from my side
SailPoint Recommendation: It is recommended to write operation rules with only the essential logic needed to trigger a PowerShell script. The majority of the downstream events and modifications should be handled within the PowerShell script itself. This script should reside on the client’s servers, allowing easy maintenance or modification by the client as needed. Additionally, this approach enables the client to implement changes to the PowerShell script functionality without requiring a code review by SailPoint, since the code runs outside of the Identity Security Cloud platform. Before and After Operations on Source Account Rule | SailPoint Developer Community
Code Improvement: In your code, include sleep commands to pause for a few seconds and use the Get-ADUser cmdlet to verify that all necessary attributes, such as UPN and SAM, are populated. Implement this check within a while loop that runs a maximum of three times(assume). If all required values are populated at any point during the loop, it will send an email. Additionally, generate log statements using Add-Content in case of any success/failures.
@sganesan I agree that you have some custom logics in after script and generating some attributes which is happening without any issues I believe.
Also as you have mentioned that it sends email for few and not sending for others which gets created at the same time. (which seems like a expected behavior as SailPoint works Asynchronously, so bulk account creation you will see this issue) You also cannot have before and after delay because it will hamper the process execution.
First of all as others have mentioned that best practice to generate these unique attributes are using cloud rules where you can check the uniqueness and avoid having duplicate.
If you still want to continue with these then I will say generate these attributes as you are doing today with afterCreate native rule. But send email using source config and OOTB email template.
If you worrying about how will you get the newly generated attributes you can create identity attributes in your Identity Profile and map these account attributes as soon as your accounts gets created these Identity Attributes will also be updated.
Now you can fetch these identity attributes in New Account provisioned email and configure the source to send email when new account is provisioned(I have already provided you the link).
For example if you want to get SAMAccountName use the variable identity.SAMAccountName
Where SAMAccountName is the identity attribute where you have the mapping which directly looks for account attribute SAMAccountName.
Going to chime in on this. There’s been some good ‘generic’ suggestions, and some, IMO, pre-mature suggestions (without fully knowing the OPs constraints on the corporate side).
sAMAccountName generation in cloud rule: Only works as ‘best practice’ if you’re on the happy path: e.g. IDN has full AD visibility (e.g. not sub-tree), you don’t mind having the generation logic stored in the cloud, multi-threading / generation collision / race condition is avoidable in the logic…etc.
Source-configured email templates: Depends on the content of the notification, you may not have info of some details in IDN. Or that the content data classification / sensitivity is meant to only pass through on-premises infrastructure (internal emails).
Sleep step: Avoid this if possible. If a wait is required, an option would be to implement an async local queue on the IQService / on-prem side.
Going back to your core issue in the OP:
“AfterCreate script is not getting invoked for some identities out of 10 identities”
Any clue from the VA side of things?
There can be cases where your log file gets locked by multiple processes and the system may fail to invoke the rule for some users.
If that is the case (you would see the logs in your IQService logs as “The process cannot access the file because it is being used by another process”), you can try changing the log file name of the rule and the script as something like below and try to see if it works :
The only logical reason that I can think of is you have more than one IQService in the environment, picking up the request… i.e. Request was handled, executed…you’re just not seeing it in the specific IQService instance’s log that you’re looking at.
