|
Posted on January 6th, 2012
It has recently come to our attention that customers upgrading from previous versions of 4.1 to 4.1.41 or higher are experiencing issues with their licensing information(registered name and license key) ‘disappearing’. We have tracked this down to a change that has caused Overseer to look at a slightly different registry key(where this information is stored). If you require your licensing information, please contact us and include information regarding your company/registered username so we can find it in our system. Alternatively, you can use RegEdit and browse to HKLM\SOFTWARE\Sensible Software\Overseer\ and look at the ‘RegisteredUser’ and ‘LicenseKey’ fields and copy/paste these into the ‘Enter License’ form under the Help menu in Overseer. We’re sorry for the inconvenience this may have caused anyone.
Posted on November 10th, 2011
Occasionally with Overseer, a Windows XP system is configured in such a way that accessing it with valid login credentials will throw the error “Logon failure: unknown user name or bad password”. This is particularly frustrating when you KNOW it’s the correct user and password, and sometimes it’s even a local account– which is particularly confusing, as local accounts always ‘just work’…
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:
- Start->Run and type ‘secpol.msc’ and click OK
- Navigate to Local Policies->Security Settings
- Find ‘Network access: Sharing and security model for local accounts’ on the right, and double-click it
- Change the value to ‘Classic – local users authenticate as themselves’
- Reboot
You’ll now see things work as expected, for Overseer and any other connections.
Posted on October 5th, 2011
I have just released Overseer 4.1.42. This is a small release that fixes a bug that I was just made aware of. The bug involved a red X on the resource selection screen in the Resource Discovery Wizard. Oddly enough, this bug was created when I upgraded the GUI library I use for Overseer, DevExpress. When I did that, I changed the ‘default skin’ to the more updated ‘Office 2010 Blue’ from the ‘Office 2007 Blue’ that’s been the default for years… Apparently that caused a ‘custom draw’ event handler to throw an error… This is unfortunate, and a clear sign of the danger in upgrading a library– or a default skin(at least with DevExpress)… Unfortunately, this bug existed in Overseer for many months before someone finally reported it– it certainly doesn’t look good for me, and is another reminder to test every single part of the software, even if a change makes no sense that it would effect that part of the software… If you see a bug in Overseer, even if it seems minor, please contact me at the support link above so I can fix it!
Thanks.
Posted on September 23rd, 2011
Overseer generally maintains its own database and doesn’t bloat significantly larger than it needs to be to hold your data. However, in some limited situations, it may be beneficial to compact the database if it gets quite large for some reason. This function should be built into Overseer at a future time, but for now it can be done with this manual process:
- 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)
- Extract the contents of the above zip file to your c:\Program Files\Overseer 4\Data\ directory(assuming default paths)
- Make sure Overseer is closed
- Launch a command shell by going to Start->Run and typing ‘cmd’ and pressing enter.
- Type the following commands:
cd "\program files\overseer 4\data"
net stop overseersvc
sqlite3 overseer4config.db vacuum
sqlite3 overseer4data.db vacuum
- 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.
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.
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 ’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.
Posted on July 22nd, 2011
I have just released Overseer 4.1.37. This is a small version update that includes a check when deleting a resource group to prevent it from being deleted if there are still resources in it. Previous to this change, a user could delete a resource group and be unable to access the resources that were in that group. This required sending the config database to Overseer support to patch the database.
Posted on July 7th, 2011
I’ve just released Overseer Network Monitor 4.1.35. This release adds a Resource Availability report under Reports->Availability Report. This report allows a user to see the uptime/downtime for a group of resources, or any single resource. In the future, this report will support grouping based on hourly, daily, or monthly segments, but for now it shows the total availability for the report period it’s run for. This should satisfy the requirements of many ISPs that have service level guarantees.
Posted on June 17th, 2011
In Windows 2008, Microsoft introduced a new type of event log. This was an extended event log, which is found under “Applications and Services Logs” in the server manager MMC. Unfortunately, this new event log system uses a totally different API to access, and Overseer 4.1 is currently unable to monitor these event logs using it’s Windows Event Log Monitoring capabilities.
I recently looked into adding this functionality for a customer who requested it, and found that Microsoft also requires .NET 3.5 to access these event logs. Overseer has been coded using .NET 2.0 to maintain compatibility with W2K users. Unfortunately, to add this feature, Overseer will need to use .NET 3.5 which is not supported on W2K. This means Overseer, once this feature is added, will also no longer be able to support running on W2K(it will still be able to monitor W2K servers and workstations).
What does this mean to you? Do you still have Overseer running on a W2K box? Is this new event log monitoring important to you? Please weigh in by contacting us at the support link above.
Posted on June 10th, 2011
Today I’ve shipped Overseer 4.1.34.0. This release adds support for reporting to Overseer, and adds one report to start– a resource incident report. This report lists your resources and the incidents within the specified time frame, with start time, end time, and down time for that incident.
This is the first report of more to come. Overseer, our network monitoring software package, has been lacking on reports for many years, and this release lays the foundation to add more reports going forward to Overseer. Next on the list is an availability report, which should be in the next release.
Are you looking for a report for Overseer? Do you need another feature in Overseer? Please let us know using the Support link above and we’ll see what we can do.
|