Overseer 4.1 is currently in bug-fix status. Overseer 5.0 is currently under development, and will have many usability enhancements, a bit of a face-lift, MSSQL database support, and some new resource types.

Overseer lets you specify multiple dependencies, although often times this will just be one– such as an internet connection or pinging a server before attempting to monitor Windows event logs, services, disk space, websites, etc.

To setup a dependency, first click the ‘Advanced’ button on the resource dialog:

This will bring up a dialog that lets you add and remove dependencies:

On this screen, click the ‘Add’ button to add a dependency or ‘Delete’ to delete one. You can also select the “Send notifications on dependency failures” setting. When this is checked, Overseer will send a notification to the user when the resource dependency fails. For example, the resource in this example is “Microsoft’s Website”. Overseer will first check the status of the configured ‘Local Gateway’ dependent resource, and if it is down, it will normally not check or send notifications for “Microsoft’s Website” being down– it will simply go to ‘Failure’ status silently instead– ideally so you can get one notification that “Local Gateway” is down, instead of dozens that other resources that depend on it are down as well. However, if this checkbox is checked, notifications will be sent about “Microsoft’s Website” being down when Overseer determines that the “Local Gateway” dependent resource is down.

When clicking ‘Add’ on the resource dependencies screen, you’re presented with this dialog:

This dialog lets you find a resource more easily by filtering– by name, type, and resource group. Once you find the one you’d like, simply double-click it, or select it in the grid and click ‘Select’.

However, even if something is found, it’s possible that there’s nothing you can do about it right away– but you really don’t want to be bothered by Overseer. Thankfully, there’s a feature in Overseer created just for this purpose.  Simply edit the schedule for the resources in question and edit the ‘After resource has been down’ setting, as shown in this image:

Now, Overseer will wait 15 minutes before sending the first notification. So, when Overseer is checking resources using this schedule, if it fails it will see it’s been down 0 minutes, and wait. 5 minutes later, it will check again– if it’s still down, it will be down 5 minutes– which is also less than 15. It will wait until it hits that 15 minute mark(as configured above), and once it does, it will notify the administrators.

NOTE: This has been fixed in 4.1.46.

The problem here, is a security policy that is sometimes on for Windows XP which causes this problem. It’s called “Network access: Sharing and security model for local accounts”, and is sometimes set to “Guest only – local user authenticate as Guest”. The proper setting is “Classic – local users authenticate as themselves”.

Thankfully, this can easily be changed using these steps:

1. Start->Run and type ‘secpol.msc’ and click OK
2. Navigate to Local Policies->Security Settings
3. Find ‘Network access: Sharing and security model for local accounts’ on the right, and double-click it
4. Change the value to ‘Classic – local users authenticate as themselves’
5. Reboot

Thanks.

1. Download the Windows command line shell tool from http://www.sqlite.org/download.html  (currently labeled ‘sqlite-shell-win32-x86-3070800.zip’, but that will change as new versions are released)
2. Extract the contents of the above zip file to your c:\Program Files\Overseer 4\Data\ directory(assuming default paths)
3. Make sure Overseer is closed
4. Launch a command shell by going to Start->Run and typing ‘cmd’ and pressing enter.
5. Type the following commands:

   cd "\program files\overseer 4\data"

   net stop overseersvc

   sqlite3 overseer4config.db vacuum

   sqlite3 overseer4data.db vacuum

6. Now, you can close the command window and re-start Overseer, which will automatically prompt to restart the service.

If you have any questions or anything doesn’t go as described here, please contact support using the support link above.

Thanks.

As a side note, I plan on adding support for an inexpensive USB temperature monitoring device soon. These devices will be available for sale on our website at a fraction of the cost of an EM1 unit(probably less than the EM1 probe itself!). The limitation, is that it will have to be physically connected to a computer– but most customers of Overseer Network Monitor have a computer close enough to what they’d like to monitor that this isn’t a big deal. Stay tuned for more information.

This generally works quite well, but there is a catch. For added performance, Overseer is able to monitor multiple resources at the same time. This can cause a problem if those resources are on the same physical computer, as the Windows authentication system only supports one login/impersonation from one computer at a time.  Overseer handles this by limiting resource checking for a specific computer to one at a time(it can still monitor multiple resources simultaneously, but they must be on separate computers– those on the same computer have to wait in line for the other resources to be checked).

This also works quite well, and is entirely transparent to end-users of Overseer Network Monitor. The one gotcha can come in when the user refers to a computer in multiple different ways… For example, they may have a disk space resource setup as \\server1\c$, but they have a service being monitored on ’10.0.0.101′… If 10.0.0.101 and ‘server1′ are the same computer, Overseer does not know this, and the problem above can occur. This often presents itself as false reports of problems, and often times Overseer is unable to successfully test a resource on that computer until the Overseer service is restarted.

In the future, I may add a function to Overseer to attempt to resolve a computer’s name to an IP, and identify it that way to prevent this problem– but that, too, won’t be 100% in the case of some multi-homed machines.  For now, Overseer users will have to be aware that it’s best practice to use the same name when referring to the computer throughout Overseer– use either ‘server1′ or ’10.0.0.101′– but never one for one resource, and one for another resource.