PS> get-qarsoperation How can I track change history for sub tasks triggered by a direct change set on a object

I set a Boolean VA on an object and that triggers a workflow and dynamic group updates.
Change history in the webUI shows subsequent completed operations as being called by the original Operation-ID
I do not see that calling operation ID in any of the default displayed properties or control for the sub-tasks using the powershell commandlets.
is there a way in get-qarsoperation to get a triggering event i.e. set Boolean on object, and track sub-tasks by their 'requested by' value that matches the operation ID for the originating tasks.

You can see the visual in the web based change history - where the 'requested by' on the trigger event is called by my user account.
the operationID for that event, shows up in 'requested by' value on events triggered by that change.

get-qarsoperation shows an operation GUID associated with a change - but I can't seem to resolve that to an operation ID.


  • Is your triggering VA being saved to the database or is it "transient"?  If it's transient, my guess would be that the set operation is not recorded.

  • The triggering Boolean is stored in the DB, remembered until the AM, when ARS systemically resets the value to a default state 'False'.
    This is used to allow an authorized individual to except themselves from a PIV requirement for the remainder of the day - ending the follwing AM.
    The Boolean is set by the user, and unset by the system in the wee hours.

    The triggered workflow sets the UAC flags to disable smartcard required and password never expires, and the nightly sweep triggers those flags to be set back.
    The same operation makes the account eligible for self-service password reset through the ARS WI - while the toggled boolean is true.

    I'm attempting to track why - the same workflow, which works for other groups - isn't completing for the problematic group.
    the boolean gets set, the dynamic group is populated as a result, the user is placed in an MU which is the scope used to authorize 'self' permission to self set a password.

    every piece works for all my candidate groups - save this one.  its the last mile that is failing to complete …

    … and my goal here is to track where in the process the breakdown is occurring.  I see no failure of the workflow execute … so, testing with one of these users side-by-side with a working 'toggler' and a 'failing toggler' and evaluating the differences. 

    I see in ARS event viewier, there isa workflow GUID and a Workflow instance GUID -  
    if the PS> commandlets can't provide breadcrumbs allowing tracking a change through triggered workflows - then maybe somethin can be devised using workflow instance via poweshell query of the eventlog for ARS.   SLOW.

  • I am curious about one thing:  why are you using a dynamic group membership to populate the MU rather than just looking for the VA itself?  I get that perhaps other processes depend on the group but could the MU just not depend on the VA directly?  It just feels like you have an extra layer of processing there.

  • The MU isn't dependent on the DG.   The DG group provides cyber a window into those that have toggled for the day.  Its used for their reporting, rather than ACL assignment...  I'd rather not use a DG, but 'groups' they know and understand.   My customer reports the process worked as expected for them this morning - and the only change I made to the process was to re-commit the same rules tweaking only the description.   Waiting to confirm - but even if that 'refresh' of the rules worked - I've got the bug to find a way to track a request from initiating event through any triggered workflows or policy scripts ... if that's possible.

  • I was just re-reading your initial question and noticed reference to Powershell cmdlets.

    Not sure if you are aware of this, but when using the Quest cmdlets and directing the action through the AR server, you can force additional info into the Change History.  Here's a trivial example:

    Set-QADUser -proxy -identity $MyUser -Description "Something new" -Control @{"OperationReason"="JohnnyQuest set this"}

    I'm wondering if this might be helpful.