Overseer Network Monitor 5.0.119 has been released

I have just released a new version of Overseer Network Monitor. This adds support for Sensatronics E4 and E16 devices. Overseer already has supported the EM1 device, but many people have requested support for the E4/E16 devices as well– probably because these devices are less expensive than the EM1 unit, and if you only need to monitor temperature(which is the most common request), the E4 or E16 is the ideal solution.. Anyways, this release adds full support, and re-names the “EM1″ resource type to generically the “Sensatronics” resource type, with a drop-down to indicate which model.

Additionally in this release, I’ve added support for the cell phone carrier, ‘ICE’, in Costa Rica. This was asked for specifically by a customer there, and we’re happy to add it.

Overseer 5.0.114 has been released

I’ve just released a new version of Overseer network monitoring software, 5.0.114. This version fixes a bug that could happen if a default was set under tools->options->defaults, and then that Schedule, Notification Group, Password, or Resource Group was subsequently deleted. Going back into the options screen and clicking save would throw an error.  This version fixes that problem.

This version also fixes a problem a specific customer had with OverseerSvc’s default TCP port assignment. The default has been tcp 12345 for years– even though this is a local port for communication between the Overseer and its own service– and nothing that needs to be passed through firewalls, etc… This customer had another product, “Trend Micro Common Client Communication Service”, that was listening on port 12345, which caused the Overseer service to crash trying to use this port.  I have changed the default port that OverseerSvc uses to 12344, and made this port customizable in the registry. Considering Overseer only uses this to communicate with itself via ‘localhost’, this shouldn’t cause anyone any issues, nor require any firewall changes, etc.

Overseer 5.0.113 has been released

I just released a new version of Overseer Network Monitoring Software, 5.0.113. This version adds a feature requested by a customer, to be able to edit the dependencies on multiple resources at once. This is done by selecting multiple resources and right click->edit. This puts you in multi-edit mode. Now, any changes to dependencies will apply to all resources that you just selected.

Overseer 5.0.112 has been released

I have just released a new version of Overseer Network Monitor. This version adds the ping latency value to the dData field in the CheckLog table. Since users can now use MSSQL as Overseer’s database, more users are requesting that this sort of data is logged, and I’m more than happy to oblige. While Overseer may not use this data(other than display in the history grid), customers may choose to run reports based on this data.

Overseer 5.0.110 has been released

I’ve just released a new version of Overseer network monitoring software. This has seemingly minor changes, but potentially with major impact to those that it affects. First, Overseer should now run with UAC turned on. If you’re an admin running with UAC turned on(the default on Windows), Overseer will now prompt for administrative privileges when starting. This will avoid an error upon start.

This version also makes a change so that the DBQuery resource type will log scalar data from a check into the CheckLog Overseer database table. This is useful for those with the MSSQL add-in and are looking at the checklog table for some reason(potentially reporting).

Executing a program when a resource fails

A very powerful new feature was recently added to Overseer network monitoring software, in 5.0.101. This feature is the Overseer ‘Actions’ system. Actions are processes that can be triggered when monitoring– typically when a resource fails, or new events are available. Currently the only action type, is to execute a program– but being able to execute a program with parameters is an incredibly powerful feature, enabling you to do almost anything.

Actions are configured under Manage->Actions. You can also ‘test’ an action, making it easier to get your parameters just right. Once you have an action defined, you must link this action to a resource. To do so, edit a resource and choose the ‘Actions’ option in the left tree. You can then use the ‘Add’ button to choose the action you’d like, along with the trigger type. Now, whenever that instance(such as ‘first failure’ or ‘every failure’) occurs for that resource, the action will be executed.

Additionally, under the ‘History’ tab for a resource, you can see the full detail of any actions that are triggered– both the input(command line, including parameters) as well as the output(stdout and stderr from your executed program).

Overseer 5.0.106 has been released

I just released a new version of Overseer Network Monitor, 5.0.106. This version adds a couple variables that can be used in custom texts– most notably, %SQLQUERY% and %SQLRESULT% for the DBQuery resource type. These were added at the request of a user– if you have variables that you’d like added, please let me know.

In addition in this release, I was able to re-create a rather complex bug that some users have had in certain environments. I was able to solve this issue, which was essentially a bug in the underlying .NET Framework. Fortunately, I was able to work around this problem and it should no longer be a problem for the users that operate in those environments.

Overseer 5.0.101 has been released

I have just released Overseer 5.0.101. This release actually has a very powerful feature, that’s been requested by many customers. Customers have requested that upon failure of a resource, that Overseer can launch a program with parameters. As of 5.0.101, Overseer has an ‘Actions’ system that lets you do just that– launch a program with parameters upon first failure, every failure, every check, recovery, or new events(event log entries).  This can be very useful for many different types of functionality.

I’ll be posting more blog posts detailing how this works, but for now I just wanted to get this released. You can add/edit your actions under Manage->Actions, and assign them to a resource using the ‘Actions’ section when editing a resource. The help file(both online and the local version) has been updated with information on actions.

Being notified when a computer is connected to network

Although Overseer Network Monitor is primarily used to notify administrators of problems when a resource goes down, some administrators have other requirements as well. A customer recently contacted me needing to be notified whenever one of his mobile users connected his laptop to the corporate network. He needed this so he could push policies to them– but this could be useful for many things, such as general network security.

The primary way this is done with Overseer, is with the new ‘Reachable’ setting for a ping resource. There are a few other settings that are best to tune as well. Here’s a step-by-step on setting up a system like this.

First, let’s create a schedule. This defines when these computers should be checked for and how often notifications should be sent. You can define when they are checked by setting values on the ‘Monitoring Frequency’ and ‘Monitoring Exceptions’ screens. For notifications, something like this would probably be ideal:

As you can see, this instructs Overseer to send notifications immediately(as soon as it detects the laptop is connected), do not notify repeatedly(setting of 0 minutes), and to stop sending after 1 notification has been sent. I’ve also unchecked the ‘Send notification when resource recovers’, as this doesn’t matter for us.  Name this schedule something appropriate, such as “Mobile Computer Detection”.

Next, let’s create a resource group for these laptops to keep them separate from our other resources. This can be done by going to manage->resource groups and adding one. Give it an appropriate name, such as “Mobile Computers” below:

Next, let’s create an actual resource. Go to New Resource->Ping. Create a resource with settings something like below:

As you can see, I’ve created a resource labeled “Derek’s Laptop”, assigned it to the ‘Mobile Computers’ group I made, assigned the ‘Mobile computers connected’ schedule, and assigned it to a “Laptop Notification Group” notification group I also created(which includes my Email, but not my cell phone, for example). I set the host name to the name of my laptop, and set the fail if setting to ‘Host is Reachable’.

Click Save, and now Overseer will send you a notification whenever that host is connected to the network. Based on our schedule settings, we will also not be notified repeatedly, nor when the computer is removed from the network– but we’ll be notified again if the computer is hooked up after being disconnected. Note that the laptops will need to have their firewalls configured to allow ICMP/Ping requests, if they aren’t already.

Overseer 5.0.87 has now been released.

I have just released a new version of Overseer Network Monitor, 5.0.87. This release includes a new feature for ping resource types. Normally when defining a ping resource, you can choose to fail if the host is unavailable, or if latency exceeds a specified amount. I’ve added a new setting per user request– the ‘Reachable’ setting. Now, you can create ping resource types that will fail if a host **is** available. This can be useful to know when certain computers are connected to the network and/or turned on. The specific customer who requested this is looking to be notified whenever one of his company’s employees plug in their laptops that they bring home with them.