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.

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.

1. Open Microsoft SQL Server Management Studio
2. Expand ‘Databases’, and find your Overseer database, and right click->Properties
3. Select  ‘Options’ on the left
4. On the next screen, select “Simple” for the recovery model, and then click OK

   

Now, if your log file is already very large, you’re going to want to shrink it. You can do this through the SQL Management Studio GUI, as well. To do so, simply follow these steps:

1. Open Microsoft SQL Server Management Studio
2. Expand Databases, and find your Overseer database.
3. Right click on the database, and go to Tasks->Shrink->Files
4. Choose the ‘Log’ file type, and click OK
   
5. Wait for the process to complete, and provided you’ve set the recovery model to ‘Simple’, you shouldn’t have to do this again.

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).

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).

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.

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.