Launch Powershell script from ARS Web Interface

Hmm, then I'm stuck again - unfortunately as I'm working with user properties in that script.
Please find excerpts following.


# get user mail address
$usermail = (Get-QADUser $Request.GUID -IncludedProperties PrimarySMTPAddress -DontUseDefaultIncludedProperties).PrimarySMTPAddress

# get user URI
$UserURI = (Get-QADUser $Request.GUID -IncludedProperties "msRTCSIP-PrimaryUserAddress" -DontUseDefaultIncludedProperties)."msRTCSIP-PrimaryUserAddress"

#define E-Mail from
$from = "<mail address>"

#define relay server
$smtpserver="<relay server>"

#send Welcome-Email
Set-CsPinSendCAWelcomeMail -UserEmailAddress $usermail -UserURI $UserURI -From $from -smtpserver $smtpserver -force

I think you need to explain your use case as I don't understand how your script is supposed to find out who's properties it's supposed to read?

$Request.GUID will get you the GUID of an in-process user but this only works if you are running this code after some action has taken place on a user such as a create or modify.

I want to send a welcome mail to the user which is marked, therefore pulling out some attributes to correctly send the message.

Who is going to be initiating this process? Is it the end-user themselves or another person, say help desk staff? If it is help desk for example, would this process then search for all users that are "marked" (using a virtual attribute perhaps) to send this welcome email to?

So, your script will contain properties of the person who kicked off the script? We call that the "Initiator".

Helpdesk and admins and only on behalf. I now went down the road of a workflow checking for a change in an extension attribute and then executing the script.

My interpretation is that he wants the user to select an object in the web interface (i.e. check the box beside it) and then use that as the target object for the script (read that's object's properties to send the welcome message).

Tricky stuff...not readily explained here.

Apologies for late reply guys and not being specific enough, I'll try to do that now.
JohnnyQuest was guessing quite good already.

I managed to suit my needs now, even if I had to "sell" another extension attribute for this but it's working fine.

I created a menu entry which updates the extension attribute which I "monitor" by way of the workflow which then executes the script, reading neccessary user information, generating the PIN and sending the welcome message.
Everything's working fine as expected.
Link is only been displayed if the user is EnterpriseVoice enabled on SkypeForBusiness
(msRTCSIP-OptionFlags being 385).

For the records, the script:

function LyncSendWelcomeMail ($Request)
{

# check if object is a user
if ($Request.Class -ne "user") {
return
}

# check if user is lync-enabled
$usertosend=(Get-QADUser $Request.DN -IncludedProperties msRTCSIP-UserEnabled -DontUseDefaultIncludedProperties)."msRTCSIP-UserEnabled"


if ($usertosend -ne $true) {
return
}

# open remote PowerShell session to SfB Server
$username = <username>
$pwdTxt = <not needed to mention>
$securePwd = $pwdTxt | ConvertTo-SecureString
$credobject = New-Object System.Management.Automation.PSCredential -ArgumentList $username, $securePwd
$lync_session = New-PSSession -ConnectionUri "https://<servername>/OcsPowershell" -Credential $credobject
Import-PSSession $lync_session

# get user mail address
$usermail = (Get-QADUser $Request.GUID -IncludedProperties PrimarySMTPAddress -DontUseDefaultIncludedProperties).PrimarySMTPAddress

# get user URI
$UserURI = (Get-QADUser $Request.GUID -IncludedProperties "msRTCSIP-PrimaryUserAddress" -DontUseDefaultIncludedProperties)."msRTCSIP-PrimaryUserAddress"

#define E-Mail from
$from = "<from_address>"

#define relay server
$smtpserver="<relayhost>"


# load function to send WelcomeMail
. C:\scripts\ps\SfB_WelcomeMail\sfb_welcome_mail.ps1

#send Welcome-Email
Set-CsPinSendCAWelcomeMail -UserEmailAddress $usermail -UserURI $UserURI -From $from -smtpserver $smtpserver -force

#close remote PowerShell Session
Remove-PSSession $lync_session

}

Does the extension attribute that the workflow is queueing off of need to be stored in AD? If that attribute is simply a trigger attribute for kicking off the workflow, you could consider using a virtual attribute in ARS. This way, you can free up that extension attribute in AD.

No, there's no need to store it in AD. It gets cleared after the workflow kicked in anyway. Could you detail the virtual attribute way Richard?