Skip to main content
Version: 10.2

Optimizing Application Usage

Introduction

Supported Report Types

Level 3 includes historical reporting, user-centric real-time monitoring, and a proactive pop-up alert.

Historical

Process Accounting

This report type periodically logs the processes users use, including CPU or memory usage, and the number of times the application runs. To generate reports using the following data types, make sure that the collection of application usage data is enabled.

Active vs Inactive

This report type provides an overview of application disable status and the events associated with applications monitored. To generate reports using the following data types, make sure that freezemonitor is enabled.

Work and Break

This report type shows the collected statistics regarding keyboard and mouse activities. You can use this to assess the intensity of application usage, which helps determine whether the user actively uses the application or opens it and leaves it running. To generate reports using the following data types, make sure that the collection of application resource activity data is enabled.

User-centric Application Monitor

The Analysis Server's User-centric Application Monitor displays the real-time application usage status of a specific user logged in. To view this, make sure that the Analysis Server web component configuration key is using Level 3.

Pop-up

Level 3 starts the pop-up disabler whenever an application has been inactive.

Requirements

To fully access the benefits offered by Level 3, make sure to meet the following prerequisites:

Configuring Level 3 Applications

You can update the cold_master.conf file to specify applications and licenses to monitor their activity levels and the actions to take when the application is idle; this has five(5) different parts:

NameDescription
applicationsContains configurations listing the applications to be monitored and considered for optimization.
globalContains configurations applied to all the components related to application optimization.
prioritiesContains configurations to set the priorities of applications on the host, user, and/or group level for optimization.
rulesContains configurations setting various rules as criteria for optimization for each application.
custom actionsContains configurations for additional actions during the optimization phase of the applications. This section is optional.
Cold Configuration Main Parts

The following sections will guide you on the required configuration to specify the applications and further configure how you want them monitored and optimized.


Configuring Applications

The applications section contains the criteria for optimizing applications. This section defines the keyboard, mouse, CPU, and i/o threshold and weight values. It also includes the executable(s), feature(s), and license server(s).

These are the required steps to list and configure applications to monitor.

  1. In the Open iT server, open the cold_master.conf in the Configuration directory, which is by default in C:\Program Files\OpeniT\Core\Configuration\.

  2. Locate the line:

    cold_master.conf
    BEGIN applications
  3. Add a new application with attributes, following the format:

    cold_master.conf
    --------------------------------
    <attribute> = <attribute_value>
    ...
    --------------------------------

These are the Basic Application Attributes that you can use to configure each application:

Basic Application Configuration

handle

This is a text string used to uniquely identify the application. The handle name is case-sensitive, and it is used in the priorities and rules sections of cold_master.conf.

Example
handle = Petrel
method

This is used to specify the method for disabling the application. There are four possible values that you can use for Level 3:

  • log - collect usage data, simply log. This can be used to determine the suitable values for the thresholds since it may be difficult to arrive in good threshold levels in the first attempt. Logging while experimenting with this can be helpful. If this method is used, then the application will not be affected by the irq.
  • standby - set the host on a standby mode based on the set criteria; standby is only valid for physical machines
  • suspend - suspend the application based on the set criteria
  • terminate - terminate the application based on the set criteria
Example
method = terminate

irq

This is used to specify the timespan in which the user is warned via the disabler interface of the application to be disabled. Specify its value to your desired timespan based on the ISO-8601 duration fromat PnDTnHnMn.nS.

Example
irq = P15M

exe

Executable Name Identifier. This is used to specify the globbing pattern the executables need to match. If applicable, include the parameters and options when specifying the path for the optimizer to match the executable name corresponding to the process. The user can specify several executables with more than one exe line.

warning

Two (2) glob patterns of different handles must not match the same process since the match is performed on the whole command line.

Example
exe = *Petrel.exe*
exe = *StudioManager.exe*
exe = *ILXAdmin.exe*

timeout

This is used to specify how long the process must be inactive before considering it for disabling. Change its value to your desired interval based on the ISO-8601 duration fromat PnDTnHnMn.nS.

Example
timeout = P45M

When a process has been inactive for this much time, the user is notified that the process may be disabled or, if the irq is zero, it is disabled immediately.

keyboard

The keyboard line has two parameters separated by at least one space. The first value is the keyboard activity threshold, in events per second. An event is either a key press or a key release. The second value is the weight associated with an activity.

Example
keyboard = 0.9 1

mouse

The mouse line has two parameters separated by at least one space. The first value is the mouse activity threshold, in mouse clicks per second. The second value is the weight associated with an activity below the threshold.

Example
mouse = 0.9 1

cpu

The cpu line has two parameters separated by at least one space. The first value is the CPU load threshold, and the second is the weight associated with a load below the threshold. If the activity level measured is less than or equal to the threshold, the weight will contribute to the sum used to decide whether a process should be disabled.

Example
cpu = 1.5 1

i/o

The i/o line has two parameters separated by at least one space. The first value is the i/o activity threshold, in bytes transferred per second. The second value is the weight associated with an activity below the threshold.

Example
i/o = 1.5 1

The summary of the examples used in the basic application attributes will look like this in the configuration file:

Example: Configuring Applications
BEGIN applications
-----------------------------------------
handle = Petrel
method = terminate
irq = P15M
exe = *Petrel.exe*
exe = *StudioManager.exe*
exe = *ILXAdmin.exe*
timeout = P45M
keyboard = 0.9 1
mouse = 0.9 1
cpu = 1.5 1
i/o = 1.5 1
-----------------------------------------
Advanced Application Attributes

These are the Advanced Application Attributes that you can use in addition to the basic attributes to better configure the applications.

arch

Machine Architecture Identifier. This is used to specify the architecture in which the application handle should be valid. Globbing is allowed.

Example
arch = i386

exclude

This is a globbing pattern used to specify excluded executables from the exe list.

Example
exclude = *.txt

multiple

If set to yes, all processes using the executables in the exe line(s) will be viewed as components of a single application. All processes must be inactive for the joined application to be considered inactive.

Example
multiple = yes

match-children

If set to yes, all child processes will be handled together while optimizing the application.

Example
match-children = yes

lm

License Manager Identifier. This is the type of license manager used by the application. The possible values are flex, lum, lmx, or rlm.

Example
lm = flex

vendor

Vendor Name identifier. This is used to specify which vendors to poll. When vendors are identified, the -s argument is used in lmstat when running lmutil (e.g., slbsls -s); otherwise, -a is used. This is only available for FlexLM.

Example
vendor = slbsls

feature

Feature Name Identifier. This is used to specify the feature or product to return the license when the application is disabled. Multiple features are allowed. This is required if lm is specified. use the format <feature-name>\<version>.

Example
feature = *\*

feature-case-sensitive

If set to yes, case sensitivity is applied on features.

Example
feature-case-sensitive = yes 

lmserver

Machine License Server Identifier. This is used to specify the license server(s). If more than one server is in the set (e.g., triad setup), specify them in a comma-separated list (e.g., lmserver1=<port1>@<host1>,lmserver2=<port2>@<host2>,lmserver3=<port3>@<host3>). If there is more than one server set, put it in a separate line. This is required for FlexLM.

Example
lmserver1 = <port1>@<host1>
lmserver2 = <port2>@<host2>

shared-license

If set to yes, this matches the feature name, user, host, and PID to ensure that the right license is removed and that the application/process for optimization checks it out. If set to no, the PID in the lmstat is used to match the optimization process.

Example
shared-license = yes

show-window-titles

If set to yes, the window titles of the optimized applications will be listed in the disabler pop-up. This will be automatically set to yes when match-children is enabled.

Example
show-window-titles = yes

standby-level

This is associated with the standby method. The level designates how deep the standby will be.

  • 1 - standby
  • 2 - hibernation
Example
standby-level = 2
note

This was formerly known as std-level. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

standby-delay

This is associated with the standby method. This specifies a delay for the server indicating how long to wait before trying to free licenses.

Example
standby-delay = P30S
note

This was formerly known as std-delay. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

hide-quit-button

If set to yes, the Terminate button after an app is suspended will be hidden. Only valid if the method used is suspend.

Example
hide-quit-button = yes
note

This was formerly known as term-excl. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

minimize-popup

If set to yes, the disabler window will appear on the task bar but will stay minimized and not pop up on the screen.

Example
minimize-popup = yes
note

This was formerly known as minimized. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

user

User Name Identifier. This is used to specify under whose name the freezmonitor will run. To specify more than one user, use a comma-separated list. Globbing is allowed.

Example
user = Administrator

host

This is used to specify the host where the optimized application is running. Use a comma to specify more than one host. Globbing is allowed. Only valid if the method used is terminate.

Example
host =host1234lin

restart

Relative Path to Executable. This is used to specify the path to an executable file. It activates a Restart button in the disabler after terminating the application. Clicking the button will start an instance of the executable specified. Globbing is not applicable for this parameter. Use a comma to specify more than one executable. The value all, for all executable files, is also applicable. Only valid if the method used is terminate.

Example
restart = all

license-removal-interlude

This is used to specify the time interval, in seconds, between license removal attempts.

Example
license-removal-interlude = 10
note

This was formerly known as rm-retry-interval. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

license-removal-attempts

This is used to specify the number of license removal attempts if the license checkout still exists after executing the license removal command.

Example
license-removal-attempts = 6
note

This was formerly known as rm-max-retry. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

assume-hidden

Setting this to yes optimizes hidden licenses.

Example
assume-hidden = yes

bypass-license-check

Setting this to yes resumes suspended application(s) even if there are no available licenses.

Example
bypass-license-check = yes
note

This was formerly known as force-resume. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

minimize-disabled-app

Setting this to yes minimizes an application upon suspension.

Example
minimize-disabled-app = yes
note

This was formerly known as minimize-app. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

usage-aggregation-method

This only applies when the multiple and match-children attributes are used. It either sums up or averages all the idle parameter values and compares them against the set threshold values to determine idleness.

  • average - threshold values are averaged
  • sum - threshold values are summed up
Example
usage-aggregation-method = sum
note

This was formerly known as combine-threshold. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

window-rules

If the value is on-resume, the application window will be restored, and if on-suspended, the application window will be minimized.

Example
window-rules = on-suspended

timestamp-matching

Setting this to yes verifies if the license checkout time falls within the specified timestamp-range from which the application started or resumed. This allows the freezemonitor to identify which license(s) to remove in case multiple application instances belong to the same host and user with varying activity levels.

Example
timestamp-matching = yes

timestamp-range

This is used to specify the time range used by the timestamp-matching attribute. For example, if the value is 5 minutes, it would check 5 minutes before and after the application start time and see if the license check-out time is within range. The default value is 5 minutes.

Example
timestamp-range = P30S

suspend-timeout

This is used to specify the time to wait before applying the suspend-timeout-action on the suspended application. The default value is P6H.

Example
suspend-timeout = P30S

suspend-timeout-action

This is the action to take when suspend-timeout elapses. The default value is resume.

  • resume - the application will be resumed
  • terminate - the application will be terminated
  • none - the application will not be suspended or terminated
Example
suspend-timeout-action = terminate

suspend-timeout-req-license

If set to yes, the disabler will wait for license checkout(s) before suspending the application again during suspend-timeout resumption.

Example
suspend-timeout-req-license = yes

suspended-period-limit

This is used to specify the timespan in which an application is allowed to be suspended without timeouts.

Example
suspended-period-limit = P30S
note

This was formerly known as force-terminate. The attribute rename is introduced in version 10. You can still use the old attribute names in version 10 but not the new ones in version 9. You can continue using the old attribute names if you have version 9 and version 10 clients.

license-requirement-offset

This attribute handles checkout race conditions wherein suspended applications may still be resumed even when no licenses are available in the pool. Use the value min to only require one available license when resuming suspended applications regardless of the original license usage or specify the offset to the number of free licenses needed to resume an application. The default value is 0, which means no offset.

Example
license-requirement-offset = 1

suspend-without-license

If set to yes, the licensed applications are optimized even if no licenses are checked out.

Example
suspend-without-license = yes

exit-on-termination

If set to yes, the quit view will be skipped when an application is terminated.

Example
exit-on-termination = yes

show-debug-section

If set to yes, a debug section will be shown in the lower part of the disabler pop-up window. You can find an example of the debug log in the last part of the Disabler Process section.

Example
show-debug-section = yes

kill

Use this attribute to forcibly stop the application, with the application not allowed to refuse the termination request. It is only valid if the method used is terminate and has the value false by default. Started support in v10.2.

Example
kill = true

force-exit

Use this attribute in place of the kill attribute to create a more positive impression on customers. This new attribute offers the same functionality as the kill attribute. Started support in v10.2.530.

Example
force-exit = true

exit-on-failed-removal

Use this attribute to release a suspended application in the event of a license removal failure. This allows the pop-up to attempt a retry on the next schedule, rather than leaving the application in a suspended state with a checked-out license. It is only valid if the method used is suspend and has the value no by default. Started support in v10.2.

note

You may choose not to use this attribute if an application automatically releases licenses when a certain heartbeat is missed.

Example
exit-on-failed-removal = yes
Example: Configuring Applications
BEGIN applications
-----------------------------------------
handle = Petrel
method = suspend
exe = *\petrel.exe*
irq = PT60S
timeout = PT10M
keyboard = 0 1
mouse = 0 1
cpu = 10 1
i/o = 800 1
lm = flex
feature = *\*
suspend-timeout-req-license = yes
lmserver = 27000@host000
lmserver = 27000@host001,27000@host002,27000@host003
custom-action = SaveSession
-----------------------------------------
END

Configuring Global Threshold

The value to be compared with the threshold is the sum of the weights for the CPU and I/O. A weight is added if the activity of the corresponding measured entities is less than or equal to the threshold, as defined in the applications section in cold_master.conf. If the sum of these weights is greater than or equal to the global threshold, then the process is considered idle and becomes a candidate for disabling. The default value of this threshold is 4.

These are the required steps to change the threshold value.

  1. In the Open iT server, open cold_master.conf in the Configuration directory, which is by default in C:\Program Files\OpeniT\Core\Configuration\.

  2. Locate the line:

    cold_master.conf
    BEGIN global
  3. Configure the global disable threshold. Locate the line:

    cold_master.conf
    disable-threshold: 4
    note

    The thresholds on CPU and I/O are the lower bound of the active levels. That is, if a value is 0.2, then any activity level equal to 0.2 or below will cause the weight to be added.

  4. Save the changes.

Including Feature Data in the Archive

Additionally, you can also specify in the global section whether you want to include the feature data in the archive.

Add the following in the global section:

archive-feature-info: yes
note

When using this feature, make sure that you provide values for the lmserver and feature attributes in the applications section.

After configuring the global section to include the feature in the archive, you also need to configure the feature-level processing.

Configuring CPU Calculation

You can also specify how the CPU threshold will be calculated in the global section. By default, this will use the updated calculation, which considers the number of logical processors for both platforms and uses % utilization as the unit of measurement for the CPU threshold. The old calculation only considers the logical processors on Windows machines and uses CPU seconds per second as the unit of measurement.

Add the following in the global section:

cpu-formula-v2: yes
note

This is, by default, set to yes in version 10 onwards.


Configuring Priorities

This section specifies the prioritization of application usages based on the type of application, the host, the user, and the usergroup. Specific applications, users, usergroups, and hosts hold greater significance in terms of application usage compared to others. Some setups may require the uninterrupted availability of certain applications.

These are the required steps to elevate or lower application priority for hosts, users, and usergroups.

  1. In the Open iT server, open cold_master.conf in the Configuration directory, which is by default in C:\Program Files\OpeniT\Core\Configuration\.

  2. Locate the line:

    cold_master.conf
    BEGIN priorities
  3. Start the configuration in the table with the provided examples.

    cold_master.conf
    # HANDLE            HOST           USER                GROUP           PRIORITY
    Calculator, *, *, *, low
    Calculator, *, Administrator, *, normal
    NotePad, *, *, Administrators, total
    InternetExplorer, tiger, *, *, high
    OpenWorks, *, root, *, total
    RationalPurify, *, root, *, high

    Refer to the Cold Configuration Column Properties table to learn the accepted values for configuring each application.

    Column NameAccepted ValueDescription
    HANDLEString (e.g., Notepad)Application Name Identifier. The valid name that identifies the application. This is the value of the handle when configuring applications.
    HOSTString (e.g., desktop123win)Host Name Identifier. The valid name that identifies the machine that hosts the application. Globbing is allowed.
    USERString (e.g., Administrator, $DOMAIN\user)User Name Identifier. The valid name that identifies the user that uses the application. Globbing is allowed.
    GROUPString (e.g., Administrators)Group Name Identifier. The valid name that identifies the group where the user using the application belongs. Local group/s and globbing are allowed.
    PRIORITYtotal, high, normal, lowThe keyword representing the priority range of the application.
    • total - Never disable the application even if the method used is suspend, terminate, or standby. The application will be in LOGGED state and will be reported as inactive.
    • high - Elevated priority. The application timeout time is doubled.
    • normal - The default priority for all applications.
    • low - Lowered priority. The application timeout time is reduced by half.
    Cold Configuration Column Properties

  4. Add new entries by either inserting a new line into the existing priority table or, if preferred, replace the existing entries with the applications you added.

    Example: Configuring Priorities
    BEGIN priorities
    # HANDLE HOST USER GROUP PRIORITY
    Petrel, *, *, *, low
    Petrel, gullvinge, *, *, normal
    Petrel, gullvinge, *, Administrators, total
    OpenWorks, *, root, *, total
    RationalPurify, *, root, *, high
    Open iT Client, *, *, Administrators, total
    END
    note

    When an application matches on multiple lines, the priority is given to the first matching line from the bottom. Therefore, it's advisable to specify general priorities before specific ones.

    The example means that the application Petrel is assigned with three priorities, but for different values for other parameters. This application will never be disabled if it is used by the Administrators group on the host gullvinge. For other groups on gullvinge, it has a limited timeout. For other hosts, it will be disabled after half the original timeout time.

  5. Save the changes.


Configuring Rules

The rules section determines when applications should be considered for disabling. Multiple rules can be created for each application. It is possible that more than one rule is valid for a particular application handle. In this case, the first rule that is valid will be used.

warning

Each handle in the configuration file must have a defined rule. Handles that lack rules will be ignored.

These are the required steps to set various rules as optimization criteria for each application.

  1. In the Open iT server, open cold_master.conf in the Configuration directory, which is by default in C:\Program Files\OpeniT\Core\Configuration\.

  2. Locate the line:

    cold_master.conf
    BEGIN rules
  3. Start the configuration in the table with the provided examples.

    cold_master.conf
    # ID   HANDLE              RULES
    1, Calculator, count > 0
    2, NotePad, wday=[1-5] + hour=[8-16]
    3, InternetExplorer, wday=[1-5] + hour=[0-7]
    4, InternetExplorer, wday=[1-5] + hour=[17-23]
    5, InternetExplorer, wday=[6-7]
    6, Games, count > 1
    #7, OpenWorks, license-use > 70
    7, OpenWorks, count > 1
    #8, RationalPurify, license-use > 85
    8, RationalPurify, count > 1

    Use the following syntax for each entry:

    Entry Syntax
    <id>,    <handle_name>,     <rule1> + <rule2> + ... <ruleN>

    Where:
    The <id> is a unique number to identify the entry.

    warning

    The ID uniquely identifies each line and must be unique; duplicates will be ignored and logged as errors.

    The <handle_name> is the application name identifier defined in the applications section.

    The <rules> are the conditions that define the behavior of the entry.

    Each rule should have the following syntax:

    Rule Syntax
    <key> <operator> <value>

    Refer to the Rule Keys and Rule Operators tables to create a rule.

    KeyDescription
    countNumber of processes
    license-usePercentage of licenses currently in use
    yearYear
    monthMonth (1-12)
    mdayDay of month (1-31)
    weekWeek of year (1-53)
    wdayDay of week (1-7)
    timeTime of the day and the timezone (07:00-16:00 or 23:50Z).
    Rule Keys

    warning

    While you can still use the hour and minute keys, please note that these keys are slated for deprecation in version 11.

    note

    When using the time key, make sure to use the +/-hh:mm format, which works both with and without a timezone. If you don't specify a timezone, it will automatically default to your machine's local time zone. Z (Zulu time) means UTC.

    OperatorDescription
    =Equal to
    !=Not equal to
    >Greater than
    >=Greater than or equal to
    <Less than
    <=Less than or equal to
    Rule Operators

    The <value> may be a single numerical value, a set of numbers, or a range. Single numerical values are given as is. Sets and ranges must be enclosed in square brackets [ ]. The values of a set are separated by commas, and a range is indicated by a hyphen.

    Rules can be presented on the same line, separated by a plus sign (+), or displayed individually on multiple lines.

    If the rules are presented on a single line separated by +, the application must meet all of the conditions to be eligible for disabling.

    Single Line Rules
    1, Openworks, license-use > 80 + count > 1

    The example will be interpreted as: If license-use is greater than 80% AND if the count is greater than 1, the application may be considered for disabling.

    If the rules are presented on multiple lines, the application must fulfill at least one of the conditions to qualify for disabling.

    Multiple Line Rules
    1, Openworks, license-use > 80
    2, Openworks, count > 1

    This example will be interpreted as: If license-use is greater than 80% OR if the count is greater than 1, the application may be considered for disabling.

    note

    It is advisable to put the lines for the same handle together to easily locate them while updating.

  4. Add new entries by either inserting a new line into the existing rules table or, if preferred, replace the existing entries with the applications you added.

    Example: Configuring Rules
    # ID   HANDLE              RULES
    1, Petrel, count > 2
    2, Petrel, license-use > 85
    3, OpenWorks, wday=[1-5] + time=[08:00-17:00]
    4, RationalPurify, time=[23:50Z]
    5, Open iT Client count > 0

    The examples indicate that the application Petrel can be disabled under either of two conditions: when the number of processes exceeds two or when the license usage percentage surpasses 85%. OpenWorks can be disabled from Monday to Friday between 8:00 AM and 4:59 PM. RationalPurify will be terminated 10 minutes prior to midnight GMT. The Open iT Client can also be disabled if at least one instance is running.

  5. Save the changes.

Configuring Custom Actions

These are the required steps to configure additional actions during the optimization phase of the applications.

  1. In the Open iT server, open the cold_master.conf configuration file in the Configuration directory, which is by default in C:\Program Files\OpeniT\Core\Configuration\.

  2. Locate the line:

    cold_master.conf
    BEGIN custom_actions
  3. Add a new application with attributes, following the format:

    cold_master.conf
    --------------------------------
    <attribute> = <attribute_value>
    ...
    --------------------------------

    Refer to the Custom Action Attributes table to learn the attributes used to configure each application.

    AttributeDescription
    titleIdentifier for the application. This will be shown in the disabler pop-up logs when the custom action is run. Must be unique per custom action.
    commandThe binary or executable to be run before or after the optimization method. Supports additional variables. Supported variables:
    • %root% - directory where Open iT is installed
    • %bin% - directory where Open iT binaries are located
    argsSupported arguments:
    • %pid% - the process ID of the application to optimize
    • %root% - directory where Open iT is installed
    • %bin% - directory where Open iT binaries are located
    conditionSpecifies how commands should run. Values can be one of the following:
    • once - run once, regardless of the amount of applications to be optimized
    • all - run per application to be optimized
    • parent - run for the parent application only (this command will run like all if match-children is disabled)
    • child - run for the child process only (this command will not run if match-children is disabled)
    • exe=<pattern> - run for each process that matches the pattern
    timeoutTimeout for the custom action. Default value is P1M.
    get-stdoutGets the stdout of the command. Possible values are yes and no. If set to yes, the command-line output will be the path where the created logs are saved. Default is no.
    allow-unsignedAllows running of unsigned binaries or scripts as custom actions. Possible values are yes and no. Default is no.
    Be cautious when running scripts from unverified sources.
    when-to-runSpecifies when the command is run. Possible values are:
    • pre - run command before optimization. This is the default value.
    • post - run command after optimization
    Custom Action Attributes

  4. Save the changes.

    note

    For licensed applications, make sure that the license manager utility(e.g., lmutil.exe) is in C:\Program Files\OpeniT\Core\bin.

Save Scripts

Save scripts are one of the many types a custom action script can perform. These are scripts tailored to an application's behavior to ensure proper saving of progress before the disabler optimizes the application.

Example: Configuring Custom Actions
BEGIN custom_actions
-------------------------------------------------------------------------------
title = SaveSession
command = %bin%/AutoHotKey.exe
args = "%bin%/ahk/Petrel-save-script.ahk" %pid%
"%root%Log\temp\freeze\autosaves\" |more
condition = all
timeout = P2M
get-stdout = yes
allow-unsigned = no
when-to-run = pre
---------------------------------------------------------------------------------

# In this configuration, the AutoHotKey.exe binary will be run in the bin dir
# with the configured argument for each application included in the optimization
# (in case multiple, or match-children is configured). The output of the script
# will be used as the save path in the data created. This will be run before
# suspending/terminating the application.

The following scripts are readily available and are found in C:\Program Files\OpeniT\Core\bin\ahk:

  • AnsysSpaceClaim-save-script.ahk
  • AnsysWorkbench-save-script.ahk
  • Petrel-save-script.ahk

Create a save script, or ask Open iT to create one by emailing support@openit.com