Scripted Rule

Scripted rules enable custom rule creation using PowerShell or VBScript to meet complex requirements. Applications can be dynamically allowed, blocked, or elevated based on a wide range of scripted conditions, providing powerful, flexible control over application behavior.

Scripted rules can take advantage of any interface accessible via PowerShell or VBScript, such as COM (Component Object Model), and each script is evaluated under the following circumstances:

  • When a new configuration is deployed to the computer

  • When a user logs on

Configure Scripted Rule

You can configure scripted rules when you are setting up application control rules in the When is this assigned? page. To configure scripted rules, follow these steps:

  1. On the When is this assigned? page, select Scripted option from the Select a source drop-down list.
    The Script tab appears.

  2. Specify a name for the script.

  3. On the Script Language drop-down list, select PowerShell or VBScript options based on your requirement.
    For more information about using the scripts, refer to the following sections.

    If the script returns (exits) with a value of 0, the script will pass and the rules are applied. If any non-zero value is returned, the script will fail and the rules will not apply.

    Each PowerShell script is executed in an instance of PowerShell.exe, and as such, Application Control neither enforces nor adds any specific syntax – all correctly formed PowerShell will work.

    PowerShell must be installed on any endpoints that will be using the script.

    Each script is run within a hosted script engine, allowing greater control over the script execution whilst providing a high degree of input and output control.

    • No VBS file is used.

    • No separate process is spawned.

    A script must be written as a function and can contain many functions, but a main start function must be specified. The start function is run by the Application Control agent and can be used to call other functions.

    The AMScriptRule COM object is built into the scripting engine and provides access to the following methods:

    • strUsername = AMScriptRule.UserName

    • strUserdomain = AMScriptRule.UserDomain

    • strSessionid = AMScriptRule.SessionID

    • strStationname = AMScriptRule.WinStation

    The Microsoft standard in this instance means that WinStation returns the value of the name of the Terminal Services Session, which is determined by the type of session, with typical values being ’Console’ or ’RDP-Tcp#34’, instead of the Window Station name, which is typically WinSta0.

    The AMScriptRule COM object also includes the following methods:

    • strLog = AMScriptRule.Log "My Log Statement"

      Allows you to output logging strings to the agent log file for use with debugging scripted rules.

    • strEnvironmentvar = AMScriptRule.ExpandEnvironment ("%MyEnvironmentVariables%")

      Expands environment variables of the user running the script.

    Using WScript. shell to expand environment variables only returns SYSTEM variables.

  4. On the Entry Function drop-down list, select ScriptedRule.

    The Entry Function option is only available for VBScript.

  5. In the Script field, add a PowerShell or VBScript.

  6. Navigate to the Options tab to configure the script executions and timeout.

  7. On the Options tab, select script execution method from the Execution Type drop-down list as follows:

    • Per session as user: Specifies that the script runs for each user logging on. Settings are only applied for the duration of the user session. Note that the script will also run if the desktop is unlocked.

    • Per session as system: Specifies that the script runs with system account permissions once for each user logging on. Settings are only applied for the duration of the user session.

    • Per computer as system: Specifies that the script runs with system account permission once at computer startup. Settings are applied to all user sessions until the computer restarts, the Application Control agent restarts or there is a configuration change.

  8. Enable the Do not execute script until user logon is complete options to prevent the script from running until user logon is complete.

  9. Specify a time in the Seconds to wait or script timeout to allow a script to continue running before the script times out. A setting of zero (0) seconds prevents the script timeout. If a timeout occurs the result is fail and settings cannot be applied.

  10. Click Add.