Introduction: The monitor-response model
In DomainScan, monitors and responses are fully separated, as well as separated from devices. This means that monitor and responses can be deployed really fast.
DomainScan monitor-response model The monitorMonitors are the part of the monitor-response model that
supervises the device or user.
A single monitor can perform a single check, but at any number of devices, which means that it’s necessary to make a monitor for each situation one wants to supervise (or monitor).
The eventWhen a monitor detects that the situation is not as it is supposed to be, an event is created.
This event contains information about which monitor that created the event, as well as why it were created and on what device or user the situation occurred.
The responseResponses are optional, but without a response DomainScan can not do anything about a situation other than report that an event has occurred.
Responses are small units that can perform an action in case of events.
That can be sending an email alert or execute a script, process or program. The response must be assigned to devices or users in the same way that monitors are assigned.
The response will only be executed if the event meets the trigger conditions for the response.
To summarize, a monitor-response is created by:
1: Create a monitor with the Monitor Wizard
2: Create a response with the Response Wizard
3: Assign both monitor and response to a device (or a number of devices)
Two types of responses can be created – email responses and responses that execute a process (any program, script or file can be selected to be executed).
Example scenarioIf a
monitor is created to check that the
Active Directory service is running on all directory servers, then an event is created for each server where the monitor detects that the particular service isn’t running.
Because of the fact that the Active Directory service is crucial to directory enabled domains, it must be running. Therefore, DomainScan can, with the aid of a Response, be set to restart the server automatically in case of events.
Furthermore, DomainScan can run several Responses with different threshold conditions, which can be used to alert backup-personnel in case that the event continues to be present (i.e. the restart does not succeed).
Example scenario 2. Multiple responses
Several responses can be triggered by a single event. And by adjusting the trigger conditions for each Response, one can achieve a cascade of actions for each event.
Pretend the above example, but where the scenario is that the administrator crew must first be warned about the stopped Directory service, so that they can solve the condition manually (1).
And then, if the condition lasts for more than 15 minutes, then a restart must be issued (2).
Finally, if the issue isn’t resolved within 30 minutes, then a distress message must be sent out to the entire IT department, and maybe even an external support company (3).
This scenario can be solved easily by creating 3 responses, with slightly trigger different conditions.
Each response must be set to react to the same severity level, and occurrence must also be equal. The only condition that is to be altered between responses in this scenario is the ‘Time’ condition, which must be set to:
(1)
0 minutes for the initial Mail Response.
This response, which is triggered immediately when the event has occurred, simply informs the administrator crew that the Directory service is not running.
(2)
15 minutes for the Process Response
This response will be triggered when the condition has lasted for 15 minutes, and the Response must be set to execute a statement that restarts the server (i.e. by executing the Shutdown command or a batch file).
(3)
30 minutes for the distress Mail Response
This response is similar to the first response, only with the exception that the list of mail recipients is larger.
Note. (1) and (2) and (3) will all be triggered after each scan cycle once the event has lasted for at least 30 minutes, which means that all 3 responses will be executed by DomainScan until the issue has been resolved.
The following response types can be created:
- Email
A response type that will send a message with an event description to one or more email-addresses.
- Process
Launch a file, a batch file, a command or any other process that can be executed – for instance a vbscript that starts an automated failover process.
To setup a response, 4 steps need to be completed.
1: – Define response name and type.
2: – Define trigger conditions.
3: – Define settings specific to the response type.
4: – Select target devices.
1 - Response name and type
up
NameThe name of the response.
TypeThe response type.
PauseIf set, then the response will not be triggered.
TemplateIf the response is to be a template response for other response, enable this option.
2 - Trigger conditions
up
Triggers conditionsSeverityThe severity level that must be met by the event to trigger the execution of the response.
Time (min)The time, in minutes, that the event must have been active before the response is executed.
OccurrenceThe number of times that the same event must occur, before the response is triggered.
The event must meetSet if the event must meet all or just a single of the parameters in the above conditions.
By default, ‘any’ is set.
Monitor filterRespond to events from any monitor
This type of response can be triggered by any monitor, as long as the trigger conditions are met.
This is the default response behavior.
Only respond to events from approved monitors
('Paired response')
With this setting, one must specify which monitors that can trigger this response.
This must be done on each device or user where the response is deployed.
Respond toResponse to device events (enabled by default)
If unchecked, then this response will not be triggered by device events.
Response to user events (enabled by default)
If unchecked, then this response will not be triggered by user events.
Note: It’s not possible to uncheck both options.
The process response can be used to execute a program, restart a server or a service, starts a recovery process or any other process that will be useful to run in case of a critical error.
Due to the fact that the process is executed by Windows, there is no limit to the type of process that can be executed, as long as it can be executed by Windows.
Note | The process will be executed with the same username/password as is defined for the DomainScan Service. The executed process will therefore be subject to the same security limitations as DomainScan (if any). |
Also, the process, that is to be executed, will be executed by DomainScan Service, with no interaction with the user desktop.
Therefore, it is not recommended to start a program that either expects user input or runs as a GUI program, due to the fact that it will not be visible, but it will still be launched and consume resources.
For instance, if a Response is created that starts
Notepad upon events, then
Notepad will be launched, but it will not be visible to the user.
Process to run
The program or file to execute.
Startup directory (optional)
The folder from where the process will be executed.
Parameters (optional)
If the process expects one or more parameters, then enter the parameter string here.
Max parameter lengthIf the parameter length is not to exceed a certain number of characters, then one can set the max here. A value between 0 and 65536 can be selected, where the value 0 means that the length of the string is not checked.
If the length value is set, then the string will be truncated in case of the parameter being longer that the max value.
ParametersIf one needs to add custom parameters to the Parameters string, then one can use these inserts. Then, once the response is to be executed, DomainScan will translate the insert parameter before the response is executed.
The translation is as follows:
| Incident device name | %name | Insert the name of the device where the event occurred |
| Incident device description | %des | Insert the description of the device where the event occurred |
| Monitor name | %name | Insert the name of the monitor that created the event. |
| Event severity | %severity | Insert the event severity |
| Event date | %date | Insert the current date as yyyy-mm-dd |
| Event time | %time | Insert the current date as hh:mm |
ExampleFor instance, if the Response is to restart the mail server in case of fatal events, then it can be done remotely (on systems where the Shutdown command is implemented) by executing the process ‘shutdown –r –f -m \\mailserver –c “DomainScan Service restart process”’.
To create this process, enter shutdown in the process to run line, and ‘shutdown –r –f -m \\mailserver –c “DomainScan Service restart process”’ in the parameters line.
Optionally, enter the path to the shutdown program in the startup directory line.
AddressesEnter one or more email addresses that are to receive the event message if the Response is executed.
Server settingsBy default the Response will use the SMTP server settings that are set in
Preferences, but in case a different SMTP server are to be used (for instance, if the response is to be executed when the primary mail server is non-responding), then the alternate server can be assigned here.
Connect as If an alternative login is needed in order to gain access to the mail server, then it can be created in
Security and selected here.
Response targetsSelect the devices where the Response is to run on.
To apply the Response to an entire domain, simply click the domain, and the Response will automatically be assigned to all devices in the domain (unless domain monitors are disabled on specific devices).
It is possible to import or export responses.
Export
To export a response, select a response on the overview page and select File -> Export. Then select a name for the response file, and select save.
Note: Usage information is not exported.
Import
To import a response, select File -> Import. Then select the response file that you wish to import and select open.
DomainScan will then commit the file.
In case that a response with the same name exists, then the imported response will be appended with a (2).