This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Deprovision Script not setting attributes

 Hello, 

 

as per subject I am setting up a deprovision script that which works outside ARS but is giving me headache when running with ARS as part of the pre-deprovision event. 

In a nutshell I have an hashtable of attributes that needs to be set:

 

$attributes = @ {
'attribute1' = 'value1'
'attribute2' = 'value2'
} 

 

Hashtable contains 8 AD standard attributes and 2 ARS virtual attributes, issue is none of this is being populated. I've enabled script debug but no errors or anything is showing so before opening a case I thought to post here. 

As I said code is sound as it works perfectly outside ARS in a standard PowerShell session via Connect-QadService and the -Proxy parameter but not wihin ARS. 

If this makes any difference attributes in the hashtable are usually alredy present on the user object just with a different value (goal is to update these values with new values upon deprovision).

Am I doing something wrong? Do I need to clear atributes before updating them? Do I need to specify one by one?

Thanks for any pointer... I'm really lost at the moment :(

*EDIT* Just to add the same approach/cmdlet is used to update another standard AD attribute, actually standard to our AD using custom schema :-), which is usually empty and this works correctly that's why I'm puzzled...

Parents
  • Thanks but again that's not going to work in our (very specific scenario) and all I call this a bug in the way ARS is handling script code which is perfectly valid in terms of syntax.

    I ended up opening a call with support and support engineer pointed out possible race conditions in scenarios like this one.

    We removed the "move user" step from the deprovisioning policy but while this seemed to work initially it stopped, without any reason, shortly after I closed the call.

    I ended up tweaking the script so that it sends a call to our Orchestrator server kicking in a custom runbook that will take care of the object's manipulation, maybe not the most elegant solution but works as intended.

    I will continue researching this and if I can ever find out the root cause I will update the post.
Reply
  • Thanks but again that's not going to work in our (very specific scenario) and all I call this a bug in the way ARS is handling script code which is perfectly valid in terms of syntax.

    I ended up opening a call with support and support engineer pointed out possible race conditions in scenarios like this one.

    We removed the "move user" step from the deprovisioning policy but while this seemed to work initially it stopped, without any reason, shortly after I closed the call.

    I ended up tweaking the script so that it sends a call to our Orchestrator server kicking in a custom runbook that will take care of the object's manipulation, maybe not the most elegant solution but works as intended.

    I will continue researching this and if I can ever find out the root cause I will update the post.
Children
No Data