We’re using a Before Provisioning Rule to move AD Accounts to the Disabled Accounts OU upon termination. We’ve run into snag with this process.
This works great if the AD Account is Enabled prior to LCS changing to Inactive.
We have a Prehire status where the AD Account is in a Disabled state
If the Employee Offer is “Rescinded” in Workday the LCS changes from Prehire to Inactive. However, the AD Account does not move because it’s linked to the Account Disable Operation in the Before Provisioning Rule.
This creates a bit of a mess because these accounts remain in the original OU taking up a license for O365 etc.
Since the AD account is already disabled, the “move” code is looking for the “disable” operation, and since no disable trigger is fired. When the provisioning plan is compiled, it checks to see if a disable is needed. Since it is not (it’s already disabled), it is removed from the plan.
I’m not aware of any workaround that would address this use case, but Expert Services might be able to help.
Otherwise, you might consider setting up a scheduled PowerShell script to run daily which would go through the existing accounts and move any disabled accounts to the Disabled OU. I found a decent write-up on such a script at Move All Disable Users to Disabled Users OU with PowerShell – ServerAcademy.com. which might help.
The real problem here is trigger of provisioning of those accounts. Once you have trigger you can use BP rule and can move OU.
To trigger provisioning you must perform some kind of action. You have different options
Assign dummy group which belongs to AD through inactive LCS , this would trigger provisioning.
Develop workflow which will assign that dummy group access profile to anyone who is inactive and holding up license(might want to work a bit on search query based on your business requirements) and this would trigger provisioning.
Once you have trigger you can replace this dummy group provisioning with OU move action or just add on top of it.
Chirag - I am going to take a deeper dive into this and discuss with our implementation partner as well. This sounds promising. I’ll update this topic as I know more. Thanks again.
I might be wrong here but wouln’t the easiest way be to use the AC_NewParent and AC_NewName in the /provisioning-policy/UPDATE API for your AD Source with a lookup table to sort different OU’s depending on Lifecycle state and thereafter change DN accordingly hence triggering an OU move for the identity.
I’m discussing options with our implementation partner as well and the suggestion from @chirag_patel sounds like the direction we’re leaning toward pursuing. I’ll definitely discuss this options as well.