If you have configured your Port Forwarding Server as in the examples above, you will be able to view the status of your Port Forwarding connections by clicking on Port Forwarding Status page under Server Functions object in the tree.
Click the Export button to download a CSV file containing detailed information about port forwarding operations for each of the port forwarding rules created on the Port Forwarding Config page.
This page allows the browsing of the Active Directory nodes using LDAP.
Under Scheduling & Alerts, you can make use of ExpertAssist’s scripting capabilities, as well as set up a service to send you email alerts when certain events occur on the remote machine.
This powerful feature of the ExpertAssist enables you to monitor the system based on the performance data collected.
You can also define conditions, and actions to be performed. A condition and an associated action are known as a rule.
Use the System Monitoring page under Scheduling & Alerts object in the tree to make changes and create new rules.
A rule has the following structure:
<rule name> (delay)
{ <condition> { <action1> } else { <action2> } }
The action can consist of several statements – they have to be separated with a semicolon.
Such as:
MemUsageAboveFor(70%, 20m)
{
SendMail(“administrator@company.com”,“Memory usage on [MACHINE]”,“High memory utilization!\n” “(Max: [MAX_USAGE])”);
SendMessage(“administrator”,“High memory utilization on [MACHINE]!\n” “(Max: [MAX_USAGE])”);
}
You can enable or disable certain rules right on the System Monitoring page.
The Edit rules button lets you edit the monitoring rules in your browser.
For example:
"Check Memory Usage" (10m)
{
MemUsageAboveFor(70%, 20m)
{
SendMail("administrator@company.com","Memory usage on [MACHINE]","High memory utilization!\n""(Max: [MAX_USAGE])");
}
else
{
SendMail("administrator@company.com","Memory usage back to normal","See topic.");
}
}
The above rule executes every 10 minutes (delay), and checks the condition MemUsageAboveFor. In the above scenario, if the memory utilization is above 70% for 20 minutes or more, the condition becomes true, and action1 is executed.
The action, in this case, will send an email to administrator@company.com describing what has happened. The rule will keep checking the condition every 10 minutes after the condition has become true. If it’s still true, it does nothing – but if it becomes false (that is, the emergency situation is resolved) it executes action2. In that case, ExpertAssist will email the administrator to let him know that the problem has been resolved.
|
Note: There is one special rule that can – and should – be defined: it’s called ERROR. If something goes wrong while performing actions – for example, when the user Administrator is not logged on and the above actions are executed, SendMessage will fail – ERROR is executed, allowing you to customize error-handling behavior. |
|
Note: You can use any of the built-in and/or custom written PowerShell scripts in your monitoring scripts to implement a PowerShell-based customized auditing and background monitoring actions. |
The monitoring script runs like a trigger. If it invokes the PowerShell script, it first initializes the $POWERSHELL_RES variable to 0. This state is then handled as the ‘previous state’. Then the ExpertAssist monitoring script engine compares this state to the state known as the ‘current state’ that is set when execution of the PowerShell script is finished. If executing the PowerShell script changes the state and the current state is different to the previous state, monitoring script triggers and executes the branch depending on the trigger value. The trigger in this case is the value of the $POWERSHELL_RES variable. If executing the PowerShell script returned the $POWERSHELL_RES variable set to 1, the monitoring script condition (main script branch) is executed following the monitoring script function declaration. If executing the PowerShell script returned the $POWERSHELL_RES variable set to 1, the monitoring script ELSE condition (else script branch) is executed. Thus, if the previous state has the $POWERSHELL_RES of 0 and executing the script returned the $POWERSHELL_RES set to 0, monitoring script will not trigger. If executing the script returned $POWERSHELL_RES set to 1, it indicates a trigger and the main script branch is executed since the variable value is 1. The table below shows the value of the $POWERSHELL_RES variable on a particular state and the script branch that will be executed within the monitoring script.
Table 4: The $POWERSHELL_RES variable.
Previous State |
Current State |
What is Executed |
---|---|---|
0 |
0 |
The states do not differ. Nothing is executed. Waiting for a trigger during the script execution delay. |
Not a 0 |
Not a 0 |
The states do not differ. Nothing is executed. Waiting for a trigger during the script execution delay. |
0 |
Not a 0 |
Tigger. Current state has changed and the $POWERSHELL_RES has been set to some value that is not a zero. Executing the main script branch. |
Not a 0 |
0 |
Tigger. Current state has changed and the $POWERSHELL_RES has been set to zero. Executing the else script branch. |
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center