What's the syntax for loading a PowerShell Library script from a Scheduled Task script?

Hi,

I'm running Active Roles 7.4, the latest version.  I've created a PowerShell Library script which contains a logging function I'd like to share with all the other Scheduled Task scripts I've written.  Currently, the function is copy and pasted into each Scheduled Task Script, which isn't programming best practise.

However, I can't work out how to tell the Scheduled Task scripts how to use the Library Script.  The error which the Scheduled Task gives is:

The term 'myCoolLoggingFunction' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

My Library Script looks like this (I've trimmed it for brevity):

# This function writes a log entry to a SQL table
function myCoolLoggingFunction([string]$source, [int]$severity, [string]$string, [string]$integer, [string]$dt, [string]$detail)
{
    # No single quotes
    $string = $string -replace '''', ''
    # etc....
}

It's more clear that to get this to work from a Policy Script, I'd call UseLibraryScript in the onInit function ... but I can't work out how to tell a Scheduled Task script to include the Library Script which Active Roles has let me create.  Could you post a snippet of your code if you've got this to work?

Thanks,

Tom

Parents Reply Children
  • What if the script activity is embedded into a scheduled Automation workflow?  Could you not call the library script in that case?  The script activity has to be a policy script right...which supports use of library scripts.

  • Confirmed, that should work just fine. The issue is only with Scheduled Task script modules which are implemented using PowerShell.

  • Would a separate ER need to be raised to see about getting the SDK updated to reflect this? The below blip is still in the current SDK and I can confirm as far back as 6.7 (which is the earliest version in my library), however the KB indicates it dates back to 6.1.

    Understanding Library Scripts

    "Library scripts are source codes that include functions or procedures to be used by policy scripts, scheduled task scripts, and approval rules."

  • Strictly speaking, this information is not incorrect, it's just incomplete. Script modules which are implemented in VBScript function in Scheduled Tasks as expected. The issue lies only in the PowerShell implementation.

  • Hmmm....sounds like a good topic for a short KB article.  Slight smile

  • I'd hoped that as that article applies to versions "6.9, 6.8, 6.7, 6.5, 6.1" that it had been superseded by changes in v7.x :(

    On the "This should work" side I found:

    • The MMC UI lets me add a PS Library Script
    • The above article doesn't apply to 7.4
    • The SDK extracted below suggests to being able to do it

    On the "This won't work" side I found:

    • I just can't get it to work!

    Perhaps for the benefit of anyone else who might run into this in the future, maybe you could adjust the UI so that it doesn't let you add a PS Library Script if it's not going to work?  That might save hair from being torn out :)

    A colleague suggested instead that I save my library function in a a custom cmdlet, which seems to work pretty well.  It's a shame it's not quite as visible as the rest of the scripts in the Active Roles console, but it gets the job done.

    Cheers,

    Tom

  • I'm not sure I follow... as far as I know Library Script behavior has not changed.  The docs incorrectly imply that you can use Library Scripts with scheduled task scripts - which you cannot.

    Did you consider my idea of simply using a scheduled automation workflow to fire a policy script in which you can reference your library script?

  • I did thanks yes, but we barely use Workflow at my company.  We have little scripts all over different servers all doing good work as I expect most IT organisations do and I wanted to bring them all into one place, so that everyone knows where to look for them. The function I want to share among multiple scripts is one which logs to a SQL database, again meaning that there's a central place to check whether any of those scripts are misbehaving or have run into trouble.

    Not everyone knows Active Roles as well as I do at my company, but I'd hope that all engineers would work out a PS script.  Adding Workflow to script execution adds a little more complexity, and will make it a little harder for others to work out what's going on.

    Tom

  • I hear ya on the simplification.  Here's how I tackle this for clients:

    If I create scheduled workflows, I created a folder under the workflows container called "Scheduled Workflows"

    Since these usually fire scripts (as you intend to), under the Script Modules container, I create a script container called "Scheduled Workflows Support Scripts".  Then I usually name each script to match the name of the workflow it supports.

    And there you have it, easy of access and "self documentation".