• State Verified Answer
  • Replies 7 replies
  • Subscribers 72 subscribers
  • Views 35823 views
  • Users 0 members are here
Options
Related

Unable to set user attribute with $Request.Put method in powershell script

andrea giammaria

Hello,

I'm creating users from an HR database's table and the creation is working fine, now I need to trigger an ARS wokflow that executes a script post-creation: the script is aimed to enrich user's data with information got from a CSV file that is stored on the server.

I've created the following Powershell script inside the ARS WF (triggered by Create User event):

function onPostCreate($Request) {
	$path = "C:\mypath"
	Set-Location $path
	$fname = $Request.get("givenname")
	$lname = $Request.get("sn")
    $csv = Import-Csv -Path $path\myfile.csv -Delimiter "," -Header 'Name','Surname','DATA1','DATA2','DATA3'
	foreach ($row in $csv){
		if ( ($row.name -eq $fname) -and ($row.surname -eq $lname) ) {
			$data1 = $row.'DATA1'
			$data2 = $row.'DATA2'
			$data3 = $row.'DATA3'
			$Request.put("edsva-data1",$data1)
			$Request.put("edsva-data2",$data2)
			$Request.put("mobile",$data3)
			break
		}
	}
}

This script is basically searching the just created user on the CSV file, retrieve the data from the file and write those data into the user's attributes but the command $Request.PUT isn't working. By looking at the script debug log it seems the attributes are set but when I check the values on users, they are empty.

I've managed to workaround this issue by using "Set-QADUser" instead of "$Request.Put" but I'd really like to know what I'm missing.

Thanks in advance.

  • 0

    Taking a step back for a second, have you by chance looked into utilizing the Synchronization Service for this use case? It might also be relevant to learn a little more about the mechanism that is creating the users in AD through Active Roles from the HR database. Thanks.

  • 0 in reply to Richard Lambert

    Hello Richard,

    I'm aware that I can use a similar script with Sync Service to accomplish the same thing but I'd really like to understand how to use the $Request.Put method correctly and what I'm missing here. As i said I already got a working workaround for this task that makes use of Set-QADUser command.

    Regarding the HR process: we read the input from a table and we create an user in AD when the creation date in the table is in the current month and the flag "provisioning" is on "ON". Please let me know if you need any further detail.

    Thanks.

  • +1 in reply to andrea giammaria

    Reviewing the sample code above, it would be highly unlikely that a single line of code would need to be written within the Sync Service to accomplish straight forward updating of attributes in AD from a flat-file, as long as the name/location of the source file does not change. The connection to the file, the mappings rules (name=fname, surname=lname...) and the flat-file column to AD attribute updating rules are all built-in functions of the Sync Service.

    With that said, since the workflow/script are working with an onPostCreate function, you might want to try and use $DirObj instead of $Request. Have a look at this sample code from the Active Roles SDK. This from the section labeled "Developing Script Activity Modules".

    function onPostCreate($Request)
{
 if ($Request.class -eq "user")
 {   
  $ou = [ADSI] $Request.Parent
  [string]$ouManager = $ou.managedBy
  if ($ouManager -ne $null)
  {
   $DirObj.Put("manager", $ouManager)
   $DirObj.SetInfo()   
  }
 }
}

  • 0

    One obvious thing that leaps out at me here is that you are using on onPostCreate.

    Strictly speaking, (and I know this may seem odd) but within a Change Workflow script activity, the name of the script function to fire doesn't matter.

    The important point is that if you want these properties added to the object at creation time (which is do-able), you need to insert your script activity into your workflow above the user creation box.

     's suggestion of using $DirObj is fine too and this could used even if the script activity is physically positioned after the user create.

  • 0 in reply to Richard Lambert

    Thanks! I've managed to get things works in this way

  • 0 in reply to JohnnyQuest

    Thanks, that was pretty interesting.

    I've used onPostCreate because my goal is to populate some user attributes (that aren't in HR database) when (or right after) the user is created.
    The SDK says that this function can be used for such kind of activities but I didn't know the difference between the script placing, above or after the user creation box, perhaps I have to read the doc a little more Slight smile

  • 0 in reply to andrea giammaria

    The thing is that out-of-the-box, those pre-defined handlers are meant to be used in policy scripts that are embedded in Provisioning Policies.  This is a very different mechanism from Change Workflows.  The graphical nature of workflows allows you to insert the script "pre" or "post" the action that is being trapped (for example an object create or object modification).  As a result, as I had mentioned before, the name of the function doesn't matter anymore because it is the physical placement in the workflow that determines when the function will execute.