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

ARS Quesry Based Distribution Group

Is it possible to create a query based distribution group where the LDAP query compares two attributes and adds a user to the group if they are not the same?

The two attributes that I want to compare are 'mail' and a virtual attribute 'edsvaFirstEmailAddress'.

If the two values are not the same then the user should be added to the group.

Is that possible?

  • Active Roles Dynamic Groups use LDAP, and LDAP cannot perform comparisons.

    However, you can abstract this using a Workflow.

    Create a new Boolean attribute called something like edsvaCompareFlag. Then, create a Change Workflow which is triggered by a change to either of your two attributes of interest. The Change Workflow runs an IF/Else branch which sets a true value to edsvaCompareFlag if the attributes are not the same. This is the Workflow which keeps up on real-time changes.

    Now create an Automation Workflow which performs a search in Active Directory and sets the edsvaCompareFlag flag for existing user accounts. You might only need to use this once, or you can choose to run it nightly as a sanity check.

    Now, just build your Dynamic Group based on the value of edsvaCompareFlag.

  • Thanks Terrance. That looks like a runner.

    I want to use the first workflow that you mention to run a powershell script against each user that is identified by the change workflow. The main purpose of this script will be to write changes to the 'mail' attribute to a CSV which will be uploaded to our Workday HR system for further processing.

    I am comfortable with the script but what is the syntax in the script to reference and work on the user objects that are identified by the IF/ELSE change workflow please? That is to say, I expect that the change workflow will identify multiple user objects where 'mail' has been changed and so I want my script to run against each user object in turn. How do I do that please?

  • Active Roles will fire a single instance of the Change Workflow for each object which is changed. If your script references the $Request object properly, then it will resolve the individual user which is spawning that Change Workflow.

    How you want to handle this is up to you. You could have script logic in the If/Else branch check, or have the entire thing scripted and then update the attribute of the $Request object. I suggest the latter option.

    The SDK is a good resource for references to Active Roles Workflow context objects, like $Request and $DirObj, which will be useful.

  • Thanks Terrance.

    I have found this in the SDK (it's a local path). I'll be able to tailor this to my requirements.

    One thing that I need to clarify, please, is whether or not the $Request in-process object is automatically passed to the script or whether I need to configure anything in the Workflow to pass the $Request to the script?

    mk:@MSITStore:C:\Installs\Quest\6.9\ARServer%206.9%20SDK\ARServer_6_9_SDK\ARServerSDK.chm::/EnterpriseDirectoryManagerScriptPolicy/BindingObjectBeingProcessed.htm

    Binding to the Object Being Processed

    .

    .

    .

    [PowerShell]

    function onPostModify($Request)

    {

    If($Request.Class -ne "user"){return}

    # Bind to the destination container

    $ou = Get-QADObject $Request.Parameter("TargetContainer")

    # Set the user department    

    $DirObj.Put("Department", $ou.Name) # Commit changes    $DirObj.SetInfo()

    }

  • Yes - the in-process object is always available in the $Request.

    I typically reference it as $Request.GUID or $Request.DN - the latter being the friendlier textual representation.  There's also $Request.Name which gives you the Domain\User style name if you don't need to know where the object lives.

  • JohnnyQuest is correct, you don't need to do anything in the Workflow, but it is important to wrap your script in a function which takes in the $Request object, as per the example:

    function onPostModify($Request)

    {

    #Do stuff...

    }

  • Anticipating the next question, the actual name of the function doesn't matter so long as $Request is a parameter to it as in Terrance's example.  You will reference the function name in the properties of the script activity that launches the script.

  • That's interesting Johnny. I have called my function "function onPostModify($Request)", assuming that it has to contain 'onPostModify', but from what you say that is not the case and I could call it "function Anything($Request)"?

  • Yes.  When the script is being called by a workflow Script Activity, the function name is not important because you are explicitly telling the Activity which function to run and when (i.e. when the Activity executes).  On the other hand, if you were using the script with a provisioning or deprovisioning policy, the function name is important because at that point, the Admin service is executing the code and the name actually determines the timing of the execution - for example, onPostModify code will fire AFTER a change is made to an object.