|
Posted on April 3rd, 2012
I’ve recently had a couple customers ask me about dependencies. This is a relatively new feature in Overseer, so some of our existing customers don’t even know exactly how to use them. They are rather hidden, but will become more visible in the next major version of Overseer. While hidden, resource dependencies can be very powerful in controlling excessive notifications when a single point of failure goes down, such as an internet connection.
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’.
Posted on March 15th, 2012
Sometimes Overseer customers will Email me and tell me that Overseer notifies them that their server is down, yet they login and everything is fine. This is something that will occur from time to time– Overseer detects a failure, but this may be caused by a network hiccup(particularly over WAN connections), or occasionally an OS issue. The first thing to do, is obviously investigate by looking at event logs, do some basic network tests(ping [host] -t to look for packet loss), etc.
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.
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 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 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 May 25th, 2011
Some customers have asked me how to get Overseer Network Monitoring Software to Email them a notification when a server restarts for some reason. While Overseer does not provide this functionality directly, this is possible with a simple event log resource in Overseer, as Windows logs a specific event entry when the server restarts.
To setup an event log resource to monitor when a server restarts, create a new event log resource, set the machine name to the server you wish to monitor, set the appropriate password, and choose “System” as the log name. Double click the default Event Filter and change it to include only event ID 6009 for the ‘eventlog’ resource. You can also click ‘Set Custom Notification Text’ to set a custom text indicating to you that the server has rebooted. Click ‘Test’, and you’ll see a message box with your message, indicating the last time your server was restarted(assuming you keep ‘%TIME%’ in your custom text).
Now, when your server reboots, everyone in the associated notification group will get a notification when the server reboots. If you have any questions or comments, please contact us using the support link above.
Posted on May 24th, 2011
People often ask how to move Overseer Network Monitoring Software from one computer to another– maintaining all their configuration settings, data, etc. This is actually a very easy process.
- Close the Overseer application if you have it running
- Stop the Overseer Service(this can be done in the Services MMC under computer management)
- Navigate to c:\Program Files\Overseer 4\Data\ and copy all the files to a safe location
- Un-install Overseer from this computer
- Install Overseer on the destination computer
- Stop the Overseer service on this destination computer
- Copy the files that were copied out in step#3 above into the same directory on the destination computer
- Start Overseer on the new computer
This should maintain all configuration settings, historical data, etc. You can apply your license by going to Help->License… and entering your license information you received in your original Email.
If you have any questions about this process, please contact us using the support link above. Thanks.
Posted on May 13th, 2011
Multiple Overseer customers over the last few years have sent me Emails where Overseer was returning an error from the system, “Network path is not found”. This is a very common error message returned by Windows, and has a number of potential causes– 100% of the time, this has been a configuration issue in the customer’s environment. If you are receiving this error with our network monitoring software, please use this checklist to try to determine the cause:
- Make sure both computers(Overseer computer and remotely monitored computer) are running on the same LAN, or a WAN without port blocking.
- Make sure the Windows firewall is disabled, or that they are sufficiently opened to facilitate communication between these computers.
- Make sure UAC is disabled. Note that some aspects of UAC may remain enabled, even after turning it off in the GUI.
- Check the times on both computers. Computer clocks must be within 15min of each other, ideally within seconds or less. Be sure to check both the date and time.
- Make sure these services are enabled and running on both computers:
- Remote Registry Service
- Server
- Workstation
- Computer Browser
- Remote Procedure Call
- TCP/IP NetBIOS Helper Service
- Open your network card(s) properties, and make sure these are checked:
- Client for Microsoft Networks
- File and Printer Sharing for Microsoft Networks
- Also make sure “Enable NetBIOS over TCP/IP” is enabled
- Make sure “802.1x” authentication is disabled(potentially buried under ‘configure’ tab for network adapter
If all these things are checked and the error persists, please perform these tasks and contact support with the results:
- Check the system, security, application event logs on both computers for potentially related errors
- Make sure you can connect to the remote computer manually:
- Start->Run and type in \\remotemachine\c$ where remotemachine is the name of that computer
- Use the same credentials as used in Overseer when prompted
- Run ‘regedit’ and attempt to open the remote machine’s registry(File->Connect Network Registry…)
- Create a debug file where you’ve re-created the problem, and include it with your message to support.
Posted on April 29th, 2011
Reporting is an aspect of Overseer that has been quite weak for quite some time. There are some ways to get historical information through the ‘Show History’ and ‘Show Availability’ right click options on a resource, but nothing that can easily be printed, and no multi-resource reports available.
I am currently working on adding some reporting functionality to Overseer. I’ll start with some simpler, yet still useful reports such as a Resource Incident report– which can be run for a resource group or an individual resource. Availability reports should be next. All reports will be exportable to PDF, HTML, Excel, and more. Stay tuned for a future release that includes these reports.
Posted on April 22nd, 2011
I have just released Overseer 4.1.31.0. This release adds a simple, yet powerful feature to the management interface. You can now right click on any resource and select ‘Duplicate Resource’, which will open an edit form of a new resource exactly like the one you clicked. You can then tweak a value and click ‘Save’, or ‘Cancel’ to abort the process.
This should enable people to more quickly and easily create new resources that are similar to existing resources. This, along with the recently added resource discovery wizard and text file import, should make it much easier to create your resources in Overseer and monitor all the services, devices, servers, and websites critical to your organization.
If you have any ideas on making Overseer easier/simpler to use, please let me know by using the ‘Support’ link above. Thanks.
|