Reporting in Overseer

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.

Overseer Debug Mode

Sometimes when trying to diagnose a problem in Overseer Network Monitor, we will ask customers to enable debug mode. When turned on, Overseer will log a good deal of information to a text file that can be used to determine what is failing where, and how.

To enable debug mode in Overseer, please follow these steps:

  1. Launch regedit by going to start->run, typing ‘regedit’, and clicking ‘ok’
  2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Sensible Software\Overseer\ in the left pane
  3. In the right pane, set the ‘LogLevel’ value to 6
  4. Restart Overseer and the Overseer service
  5. Re-create the error you’re having or leave debug mode enabled per instructions from support
  6. Send the files in C:\Program Files\Overseer 4\Data\Logs\ to support. You may have to zip these files to send through Email, or upload via FTP using credentials supplied by support.
  7. Turn debug mode off by changing the ‘LogLevel’ value above to 0 and restarting Overseer and the Overseer Service.

It is important not to leave debug mode on, as the debug file can grow quite large over time and eventually fill up your hard drive, or otherwise slow Overseer and/or your computer down dealing with a very large text file.

Windows 2008 R2 issues with remote monitoring

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

 

Categories: