| Field |
Description |
|---|---|
| Rule Name ( Name in the table) |
Name by which this rule is listed in the Script Rules table. (Required) |
| Description |
Additional information about the rule. This can be any text you choose to enter. (Optional) |
| Status |
Radio buttons that make this rule Enabled or Disabled. This allows you to create a rule that you use only at certain times, or to temporarily disable a rule without losing its definition. |
| Platform |
Platform (Windows, Mac, or Linux) for which this script rule is defined. Each script rule must be specific to one platform. |
| Script Definition (Add/Edit page only) |
How you want to define the script rule. The menu choices are: File Association – Choose this definition to allow the file association list on the agent computer to determine the Script Process. You still must provide the Script Type (file name). File Association might be a good choice for a common script type if your environment includes computers with different versions of the script engine for that type (for example, different versions of Perl). However, it is not necessarily the best choice when individual computers have multiple versions of the script engine; only the one identified in the File Association will be managed by App Control. Consider your environment before making this choice. PLATFORM NOTE: Only Windows scripts can use File Association. Script Type and Process – Choose this definition if you want to specify both the file patterns that define the script and the process that runs the script. |
| Script Type ( Type in the table) |
The file name pattern that determines whether a file matches this rule and is therefore considered a script. In most of the standard rules, the script type is defined by the file extension you want identified as a script (for example, *.vbs). You can use paths, wildcards, and macros in the script type. See Specifying Paths and Processes for a general description of pattern definitions options in App Control rules. |
| Script Process ( Process in the table) |
The executable whose behavior you want to control when it processes files matching the Script Type. Examples of script processors include wscript.exe (Visual Basic scripts), cmd.exe (batch scripts), ps.exe (PowerShell scripts) as well as processes that are not obviously script processors such as firefox.exe, chrome.exe and word.exe. You can use paths, wildcards, and macros in the script process. See Specifying Paths and Processes for a general description of pattern definition options in App Control rules |
| Rescan Computers |
If checked, rescans all connected computers running the App Control Agent to discover any files matching the script rule. If a matching file is found, it is added to the File Catalog with a file state of Approved. If not checked, all script files matching the rule are Unapproved. If a computer is disconnected, it will get the “rescan” rule once it reconnects, and will be re-scanned. Keep the following in mind: Enabling Rescan Computers in a new or existing rule causes a delay during which existing local scripts might not be approved. If a script file matches a custom rule that instructs the App Control Agent to ignore rules, it will continue to be ignored. |
| History |
For existing rules, a History panel on the Edit Rule page appears showing some or all of the following fields. In addition, these fields can be added as columns on the rules table page.
|
Caution: Use of very broad definitions for either the Script Type or Script Process field is not recommended because of negative performance impact. If either field in a rules uses * or *.*, a warning will be displayed on the page. Be as specific as possible in defining the file patterns in a Script Rule.
