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.

MSSQL Log file is too large

When using MSSQL for Overseer’s database, sometimes the transaction log will grow way too large. This is due to the default setting in MSSQL of ‘Full’ recovery model, instead of ‘Simple’. Overseer should ideally be run with a “Simple” recovery model to keep this log file from getting out of hand. To do this, please follow these steps:

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.

Overseer 5.0.111 has been released

I have just released a new version of Overseer, 5.0.111. When using Overseer to monitor a SQL Server, a user was experiencing an error, “Machine name may not contain backslashes”. This ended up being a problem when using the DBQuery resource type, monitoring MSSQL using a named instance(i.e. SERVER\instance) and Windows integrated authentication. This bug has now been fixed.

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.

Proxy auto-detection broken by recent Microsoft update

Recently, Microsoft released a ‘security update’ for .NET Framework 3.51, to address KB2729452. Apparently someone, somewhere, was using proxy auto-detection scripts to somehow compromise a system. Reading the KB, this change doesn’t appear to be a problem for software developers. Unfortunately, this ‘security update’ actually broke legitimate usage for any software that uses HttpWebRequest, which is part of the .NET Framework, and is the normal way to check websites, connect to websites, etc. via code.

A customer recently brought this to my attention, and thankfully was aware that one of the new updates he installed caused the problem. I was able to work-around this problem for him by giving him a special file, but it became clear to me that other customers are likely to have this issue and it will appear as though Overseer simply doesn’t work. So, to work around this breaking change from Microsoft, I’ve added support in Overseer to specify proxy information. I left the option to ‘auto detect’(which used to be what Overseer did), but the default selection is now ‘no proxy’– this is the least problematic setting for most people. Those that have proxies can easily set their proxy information, or attempt auto-detection(which will likely work if this MS Update hasn’t been loaded).

Overseer 5.0.92 has been released

I’ve just released another version, 5.0.92. This version fixes a bug affecting only users using MSSQL as the Overseer database. This fixes an error that occurred when adding a new resource when using MSSQL.

Overseer 5.0.89 has been released

I’ve just released another minor update to Overseer, 5.0.89. This has a small bug fix that only affects people attempting to run the Overseer management application multiple times on the same computer(such as in multiple remote desktop sessions). Overseer 5.x was throwing a ‘System.UnauthorizedAccessException’ error. Note that to run Overseer multiple times such as this, the registry setting ‘HKLM\Sensible Software\Overseer\MultipleInstances’ must also be set to 1.   This build fixes the error message and allows Overseer to run more than once on the same machine.

Overseer 5.0.88 has been released

I’ve just released a new version of Overseer Network Monitor. This is version 5.0.88, and the only change is a fix for a small bug reported by a customer. Sometimes, in some rare circumstances, an incident wouldn’t get closed. This would become obvious to the customer when the recovery Emails would over-state the down-time, as it would be referring to the incident that wasn’t closed, versus the most recent. This change fixes the incidents and patches up any issues with the current state of the data in this regard.

Warns and prevents deletions of items that are used

Previous versions of Overseer would sometimes let the end user accidentally delete something important… Most notably, Overseer would allow the user to delete a resource group that has resources in it. This would make those resources inaccessible, even though they’d still be monitored and alerts sent. This is obviously not a good thing, so in Overseer 5.0, I went through all the ‘things’ in Overseer, and added a quick check when deleting them– now if you try to delete a notification, notification group, schedule, resource group, etc. that is in use by another item(i.e. a resource using a schedule for network monitoring), Overseer will prevent you from doing so and explicitly tell you why.

Overseer 5.0.85 has been released

I have just released another version of Overseer network monitoring software, 5.0.85. This version just contains a small bug fix that a user reported. The ODBC information wasn’t being saved when clicking ‘ok’ in the Tools->Options dialog. This should all work now.