• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 63 subscribers
  • Views 8328 views
  • Users 0 members are here
Options
Related
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

Updating EDS_CONTROL_OBJECT_DN Not Working - ARS 7

michael.otis
over 7 years ago

I've created a workstation deprovisioning policy, this policy changes properties, disabled and moves a workstation to a deprovisioned OU. This isn't a form policy, it's an attribute setter command. It flips a boolean to true which kicks off the policy and everything completes just fine expect it throws an administration error because it isn't updating the EDS_Control_Object_DN instead of updating the destination DN on the website. Below is the snippet of code from the onPostModify function:

#Disable and move Object to Defined OU and Refresh Page with Correct DN
Disable-QADComputer $GUID
$MoveResult = Move-QADObject $DN -NewParentContainer $newParent -Proxy
$RenameResult = Rename-QADObject $MoveResult.DN -NewName $newCN -Proxy
$NewSamResult = Get-QADComputer $RenameResult.DN -Proxy | Set-QADComputer -sAMAccountName "$($newCN)$" -ObjectAttributes @{DNSHostName = ""; servicePrincipalName = ""} -Proxy
$Request.PutOutControl(11, 3, $NewSamResult.DN)

 

I've also noticed there is a way to set controls in the workflow in ARS 7 but that doesn't seem to work either. There isn't really any documentation on how to use that either.

  • 0 over 7 years ago
    Try this right after your move:

    $Request.PutOutControl($Constants.EDS_CONTROL_OBJECT_DN, $Constants.EDSTYPE_DN_STRING, $MoveResult.DN )
  • 0 over 7 years ago
    No, didn't work. Getting this error still.

    Error: Administration Service encountered an error when retrieving properties of the object 'CN=TEST123,OU=DEPROVISIONED,OU=Workstations,DC=Domain,DC=COM'. Directory object not found. (Exception from HRESULT: 0x8007208D)
  • 0 over 7 years ago
    Interesting - my thinking is that this is a timing thing. As you know, ActiveRoles tends to "lose track" of objects when you move them. I would have thought by doing the PutOutControl right after the move, it should have been able to keep things straight. Might be interesting to check the contents of $Request.DN right after the new PutOutControl statement to see if it's actually getting reset. Also, have you considered using the built-in "Move" activity and then doing the rest in your code? I'm not sure if it's more "state" friendly.
  • 0 over 7 years ago
    If I check $Request.DN after the PutOutControl, it returns the correct DN that should be return to the Web Interface. I've even checked the contents of the actual PutOutControl variable and it is correct, yet it's still not reloading the Web Interface will the right DN. Sounds like a glitch to me.
  • 0 over 7 years ago
    It could be. I'm not sure that's it a good idea to effectively perform two object renames in succession the way you are (i.e. move then CN change)

    Does it work if you don't do the CN change?
    What if you do the CN change first, followed by a PutOutControl and then the move.

    Also, you didn't answer my question about the possibility of using the built-in workflow Move activity.
  • 0 over 7 years ago
    No, none of those options work.

    How do I execute the built-in move workflow from the function? Are we assuming that would communicate the proper DN to the WI?
  • 0 over 7 years ago
    I assumed (perhaps incorrectly) that you have this script embedded in a workflow already.

    In re-reading your intro, its suggests that you have this as part of a provisioning policy?

    What I am suggesting is that you create a workflow that triggers off your attribute change.

    Add a move activity as the first step of the new workflow.

    Take your script and remove the move bit. Embed the rest as a script activity in the workflow.
  • 0 over 7 years ago
    Some things were in a workflow. I've now embedded everything into the workflow triggered by the specified virtual attribute changing to "True". It moves the object immediately and triggers the script. It runs exactly the way it did before, I turned on script debugging and this entry shows that it is setting the control but it obviously isn't getting passed to WI.

    Call method '$Request.PutOutControl'
    Arguments list:
    [1] : Value=11 : Type=System.Int64
    [2] : Value=3 : Type=System.Int32
    [3] : Value=cn=TEST123{1},OU=DEPROVISIONED,OU=Workstations,DC=domain,DC=com : Type=System.String
    DEBUG: 37+ >>>> }