Overseer 4.1.41 has been released

Posted on August 17th, 2011

Overseer 4.1.41 has been released. This is primarily for a bug fix that only affects those using EM1 environmental monitors, and monitoring relative humidity with that monitor.

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.

Referring to computers by multiple names can cause issues

Posted on August 9th, 2011

Overseer Network Monitor is designed to monitor multiple resources on multiple computers from one location. To do this, the user must enter in the appropriate credentials for these computers(usually the domain administrator account). When Overseer checks the resources, it impersonates this user so it has adequate privileges to perform this monitoring.

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 ‘’… If 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 ‘’– but never one for one resource, and one for another resource.