Is it possible to apply a VA value to multiple users in one pass?

So - maybe nothing in the box ...

maybe out of the box?

My working assumption in this task - is,
that the VA value lives completely inside ARS config. 
And ARS config is stored in SQL.
SQL has tables that can be updated.

can, a SQL query be structured to update a table that contains the VA's tied to an AD user object

- and push the VA via SQL command in one pass.
and on ARS restart, the aradminsvc will associate the VA values with the live user.

You definitely don't want to get into doing an manipulations of the AR SQL tables as this would put you off-side from a Support perspective.

I was going to suggest a programmatic trigger of a policy check.

So initially, you set a provisioning policy PVG rule that says that myVA "MUST BE" value "X"  and then programmatically trigger AR to check objects for compliance with this policy and correct those that are not.

Hmmm .. <peeks over glasses>  that is worth a real shot, Terrance.  

Try this instead of your Set-QADUser

$ADObj = [ADSI]("EDMS://" + $objUser.distinguishedname)

# 2 indicates append

$ADObj.putex(2,”'edsvaRoleBean'”,@(“$strRoleType″))

$ADObj.setinfo()

Encountered an error with the putex as written.

$ADObj.putex(2,"'edsvaRoleBean'",@("$strRoleType")) 

I removed the double quotes - and left the singles on the rolebean - ran without error, but replaced the existing roles under that VA name with just the one.
whoops.  I can roll that back - but, here's the error that was returned as written above -
$ADObj.putex(2,"'edsvaRoleBean'",@("$strRoleType"))
Exception calling "putex" with "3" argument(s): "The directory datatype cannot be converted to/from a native DS datatype

$ADObj.putex(2,'edsvaRoleBean',@($strRoleType)) 

$ADObj.putex(2,'edsvaRoleBean',@("$strRoleType"))

Exactly as I ran it - and it didn't error .. Try catch let it run in peace for a small test collection.

and checking the change history - shows the before and after values in edsvaRoleBean to be just the one 'new' value rather than the 'list' showing the new one appended.     2 means 2 ... until it doesn't  : )  I had a math teach tell me that once.

well - on second look - I left the double quotes on the $strRoleType ... I'll remove it on my end and re-test.

My bad... I believe the '2' should be a 3 for an Append.

see - my math teacher was right.   I'll re-test. Thanks Johnny

there had been a post by one of the Nova Scotia support peeps - on how to query SQL to return the before and after values of an attribute changed via active roles...   I can't find it now here- or in my own notes.    That knowledge would come in handy now.    Quest/OI change history commandlets only show the after value - but the sql query nugget buried somewhere in the forum  / KA's here has that query spelled out.    Can you share that here?

Changing the putex from 2 to 3 resolved that issue - now appends.
in small batch testing didn't appear to improve speed - however, the efficiency of the method will improve will improve with the next large batch run

I'll run the SQL index rebuilds this weekend to see if that helps as well.

On a larger dataset, it should be quite a bit faster.  

On a larger dataset, it should be quite a bit faster.