Launch Powershell script from ARS Web Interface

Sorry if I'm missing something obvious (we've just recently deployed ActiveRoles Server), but I cant seem to find an easy way to launch a standalone powershell script from within the ActiveRoles server Web Interface.

I have a simple script which exports a list of user objects from our Deprovisioned Users OU to a CSV file, and I'd like our Help Desk staff to be able to launch this script from the WEB UI by clicking a custom menu item like "Generate Deprovisioned Users Report"

Can anyone point me in the direction of any existing documents that show me how to do this?

  • In reply to rlambert:

    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.
  • In reply to rlambert:

    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.
  • In reply to JohnnyQuest:

    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

    }
  • In reply to bezibaerchen:

    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.
  • In reply to Richard.Lambert:

    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?