|
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 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 April 6th, 2011
Windows 2008 R2, and possibly some other later versions of Windows, have a problem with being remotely monitored by non-domain accounts. This blog post will show how to work-around this Windows “feature” that disables such monitoring.
Recent versions of Windows introduced UAC– User Account Control. While this may be useful on some workstations, most server admins will disable it so they don’t spend half their day clicking ‘yes’ on prompts. What many don’t realize, however, is that disabling UAC on the server doesn’t disable “remote UAC”– most people don’t even know such a thing exists…
Well, it does– and it causes remote monitoring tools like Overseer to **not work** when utilizing local accounts. Domain accounts will still work to monitor the computer, but if you’re trying to monitor a W2K8R2 computer that is not a member of a domain(and therefore using local accounts), you may run into this issue. This is further obscured by the fact that this remote UAC does not appear to affect the built-in ‘Administrator’ account– only separate users that should normally be allowed(members of Administrators group).
Well, the solution is here. To disable this ‘Remote UAC’ feature, you can add this DWORD registry value, setting it to 1:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy = 1
No restart of the server or any services is required. Note that this registry change must be done on any servers being monitored by Overseer– not just the computer running Overseer itself.
For convenience, you can use the .reg file below to add this registry key, or you can do it manually using regedit.
DisableRemoteUAC.reg
Posted on March 28th, 2011
Would you like to monitor the number of SQL connections to your MSSQL server? Possibly the number of SQL connections to a specific database? This can easily be done with Overseer Network Monitor’s MSSQL Monitoring capabilities.
A previous post of mine showed you how you can monitor MSSQL database sizes. In this post, I’ll use a similar mechanism to what I used there. First, create a DB Query resource type in Overseer:
We used this SQL query:
select d.name,p.* from master.dbo.sysprocesses p join master.dbo.sysdatabases d on p.dbid=d.dbid
This gets the count of the current connections from the MSSQL master database. You can add “WHERE name=’databasename’” if you’d like to only track connections for a specific database. You can then use the scalar result comparison settings to determine when you’d like to be notified of this count.
Is this helpful to you? Are you looking for another SQL query to perform a specific MSSQL Monitoring task? Please contact us using the support link above, and share what queries you may have used, or what type of query you might be after.
Thanks.
Posted on March 21st, 2011
Numerous people have asked how they can monitor their resources through a firewall with Overseer Network Monitor– which ports do they have to allow, etc. For HTTP or EM1 resources, this is simple– forward tcp port 80(or 443 for https/SSL). If you’re monitoring ping resources, simply forward ICMP echo packets. For Windows-based resources, the answer is a little more involved.
Overseer monitors windows resources using standard Windows Networking protocols. The exact ports vary in different versions of Windows, and there’s some negotiation thrown in to find one that works. Typically forwarding tcp ports 135-139 and/or 445 will do the trick. I often caution people not to forward these ports on the public internet, however.
It is my professional opinion that Windows Networking protocols are not internet safe. While some of them may contain appropriate security mechanisms to prevent network sniffing, I prefer to **never** open a windows protocol port to the open internet. If you look at windows security updates, you’ll notice that the vast majority of the security holes are in regards to Windows networking(and IE)– it’s therefore inherently safer to not allow these ports to be opened to the internet…
If you must open these ports to the internet, be sure to lock down the firewall rule to only allow authorized IPs access. You should also have strong passwords on your network(this is generally a good idea everywhere, but not always followed).
Now, the preferred way to monitor remote Windows resources is using a secure VPN. Many routers/firewalls support site-to-site VPN tunnels, and these are incredibly useful for this sort of thing. Please consult your network administrator for the best way to create a site-to-site VPN tunnel for monitoring purposes.
Posted on October 30th, 2010
Multiple customers have requested the ability to filter duplicate event log notifications when they’re monitoring Windows Event Logs. At first glance, this may seem like a simple thing, but it’s a little more complex than that.
If you want to enable duplicate event log filtering, you’re going to have to enable this feature on your event log resource(s):
As you can see, you must check the box to prevent duplicates, and then specify a number of minutes as the ‘duplicate’ time window. After this amount of time, if the event is seen again, you’ll get another notification. This is critical, as otherwise you may not get event log entries because you had the same event logged days, weeks, or even months ago.
The second value is the ‘Detection Method’. Windows Event Logs use a source name(such as the name of an application) along with an Event ID. This event ID is a number defined by the source of the event. The last value is the message. This message is usually unique to the specific time an event happens. The event ID usually indicates the type of event happening(i.e. “unable to write to file”), and the message indicates some data specific to that event(i.e. which file cannot be written to). This option lets you control how duplicates are detected.
Posted on October 24th, 2010
This version of Overseer Network Monitor includes multiple new features.
First, we’ve added a text file import wizard. This allows you to create multiple resources based on data in a text file. You can import resources for Ping Monitoring, Disk Space monitoring, Windows Service monitoring, and Website monitoring. Be sure to check out this new features under the Tools menu option.
Second, we now have a ‘show current incident’ option under the right click menu for resources in a failure state. Previously, to see what the current problem was with a failing resource, you had to right click->Show History, and double click the most recent incident. This feature provides a shortcut to get to the information faster when your resource is down– so you can solve the issue and get your systems and networking operating again.
Third, Overseer now defaults the group on new resources to the currently selected resource group. This should make manual entry of resources a little easier, as most of the time you should no longer have to change this value from its default.
Fourth, this version fixes a problem with the left hand pane refreshing after making a change to resource groups.
Lastly, a few minor navigational enhancements to the GUI have been made. Things like keyboard shortcuts that you just expect to work(home/end, delete, application context key, etc.).
Posted on November 4th, 2009
One user Emailed me about a problem with opening event log monitoring resources on one of their servers. It appears their server had more stringent registry permissions than those used in QA for Overseer. This version fixes that problem by changing Overseer to require a lower level of permissions on the appropriate registry keys.
|