How to fix “Invalid Class” error when monitoring a process

Posted on October 18th, 2018

I recently had a customer have an error indicating “Invalid Class” when monitoring a process. This was a resource that worked perfectly until now. This is a known issue when Windows performance counters are unavailable or disabled. The primary culprit is a registry key that explicitly disables them. To fix this error, open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance\ in regedit. Check for “Disable Performance Counters” value in the right pane. If it’s there and set to 1, that’s the problem. Set it to 0 and reboot the computer. This should be done on both the Overseer computer and the computer being monitored. This fixed my customer issue, and it can fix yours. If it doesn’t, please contact us so we can work through a solution with you.



Overseer 5.0.158 is now available

Posted on October 20th, 2014

I’ve just released a new version of Overseer Network Monitor, 5.0.158. This version adds a ‘start service’ and ‘stop service’ options when right clicking a Windows Service resource type. This can be useful to some if you need to force a restart of a Windows Service remotely.


How to move Overseer 5.0 from one computer to another

Posted on December 27th, 2013

One of the most frequent support requests I get, is a step-by-step guide on how to move Overseer from one computer(or server) to another. This happens for multiple reasons in production environments.  Unlike some other software, moving Overseer to another server is quite easy and painless– no special license activation keys are needed, etc.– just your license key from your original install, the latest Overseer setup file, and a medium to transfer the database(network, thumb drive, etc.).

  1. Before getting started, it is always best to update Overseer to the latest version, available at Please do this on the original computer first.
  2. Next, start the Overseer management application using the desktop shortcut, and click the ‘Service Running’ icon in the upper right corner to stop the service(say ‘yes’ when prompted if you really want to stop the service).
  3. Once the service is stopped, it’s time to export your data. Go to Tools->Backup and Restore Wizard. Follow the prompts, noting where the backup file is being placed(you can specify another location if so desired).
  4. Once backed up, you can get your license key information from Help->License, or ideally your original license Email.
  5. Now, copy the backup file you just made in step #3 to a safe location– thumb drive, network location, etc.
  6. Un-install Overseer from this computer.
  7. Install a fresh copy of Overseer on the new computer, using the same latest version you upgraded the first computer to in #1.
  8. Apply your license key in Help->License…
  9. Go to Tools->Backup and Restore Wizard, and select the option to restore your database, pointing to the file you saved off in step #5.
  10. Wait for the restore/import to complete(this can take a while if you have a large database). Once done, all your settings, resources, and history should be restored onto this new computer, and Overseer should start monitoring your resources from this new computer.



MSSQL Log file is too large

Posted on February 14th, 2013

When using MSSQL for Overseer’s database, sometimes the transaction log will grow way too large. This is due to the default setting in MSSQL of ‘Full’ recovery model, instead of ‘Simple’. Overseer should ideally be run with a “Simple” recovery model to keep this log file from getting out of hand. To do this, please follow these steps:


  1. Open Microsoft SQL Server Management Studio
  2. Expand ‘Databases’, and find your Overseer database, and right click->Properties
  3. Select  ‘Options’ on the left
  4. On the next screen, select “Simple” for the recovery model, and then click OK


Now, if your log file is already very large, you’re going to want to shrink it. You can do this through the SQL Management Studio GUI, as well. To do so, simply follow these steps:

  1. Open Microsoft SQL Server Management Studio
  2. Expand Databases, and find your Overseer database.
  3. Right click on the database, and go to Tasks->Shrink->Files
  4. Choose the ‘Log’ file type, and click OK
  5. Wait for the process to complete, and provided you’ve set the recovery model to ‘Simple’, you shouldn’t have to do this again.



Executing a program when a resource fails

Posted on December 13th, 2012

A very powerful new feature was recently added to Overseer network monitoring software, in 5.0.101. This feature is the Overseer ‘Actions’ system. Actions are processes that can be triggered when monitoring– typically when a resource fails, or new events are available. Currently the only action type, is to execute a program– but being able to execute a program with parameters is an incredibly powerful feature, enabling you to do almost anything.

Actions are configured under Manage->Actions. You can also ‘test’ an action, making it easier to get your parameters just right. Once you have an action defined, you must link this action to a resource. To do so, edit a resource and choose the ‘Actions’ option in the left tree. You can then use the ‘Add’ button to choose the action you’d like, along with the trigger type. Now, whenever that instance(such as ‘first failure’ or ‘every failure’) occurs for that resource, the action will be executed.

Additionally, under the ‘History’ tab for a resource, you can see the full detail of any actions that are triggered– both the input(command line, including parameters) as well as the output(stdout and stderr from your executed program).

How to fix errors connecting to MSSQL Server

Posted on December 6th, 2012

With the addition of the database query monitoring feature of Overseer Network Monitor, I’ve had a couple users come to me with errors connecting to their MSSQL server using Overseer. This is primarily because the default configuration of Microsoft SQL Server disables TCP/IP communication for security reasons. When Overseer is unable to access the MSSQL server, you may get an error like this:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (Provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server

Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding


To properly configure MSSQL server to listen on TCP/IP, you’ll have to follow these steps:


1. Find and run the “SQL Server Configuration Manager” on the start menu. This should be under “Microsoft SQL Server 2008 R2->Configuration Tools”.

2. Once you open the SQL Server Configuration Manager, navigate to SQL Server Network Configuration->Protocols for MSSQLSERVER. Find ‘TCP/IP’ on the right side, and double-click it:


3. On the TCP/IP Properties page, make sure ‘Enabled’ is set to Yes, and ‘Listen All’ is set to yes, per this screenshot:


4. Also, make sure the port is specified on the ‘IP Addresses’ tab, under the “IPAll” section. This should typically be 1433:


Once this is done, you’ll have to restart the MSSQL Server service, and then attempt to connect to it with Overseer again. If things still don’t work, you may have a firewall blocking port 1433, either on the MSSQL Server machine, the Overseer machine, or potentially a hardware firewall in between– make sure port 1433 is allowed/forwarded as needed.




Proxy auto-detection broken by recent Microsoft update

Posted on November 29th, 2012

Recently, Microsoft released a ‘security update’ for .NET Framework 3.51, to address KB2729452. Apparently someone, somewhere, was using proxy auto-detection scripts to somehow compromise a system. Reading the KB, this change doesn’t appear to be a problem for software developers. Unfortunately, this ‘security update’ actually broke legitimate usage for any software that uses HttpWebRequest, which is part of the .NET Framework, and is the normal way to check websites, connect to websites, etc. via code.

A customer recently brought this to my attention, and thankfully was aware that one of the new updates he installed caused the problem. I was able to work-around this problem for him by giving him a special file, but it became clear to me that other customers are likely to have this issue and it will appear as though Overseer simply doesn’t work. So, to work around this breaking change from Microsoft, I’ve added support in Overseer to specify proxy information. I left the option to ‘auto detect'(which used to be what Overseer did), but the default selection is now ‘no proxy’– this is the least problematic setting for most people. Those that have proxies can easily set their proxy information, or attempt auto-detection(which will likely work if this MS Update hasn’t been loaded).

Moving Overseer 5.0 to another computer

Posted on November 21st, 2012

One of the most common support requests I have, is people asking how to move Overseer to another computer. For one reason or another, people simply need to move from older hardware to new, or simply different. Obviously, they want to maintain their existing resources, history, etc.

Overseer 5.0 makes this very easy. To move Overseer 5.0 to another computer, simply follow these steps:

  1. Open Overseer and stop the service(click the “Service Running” text)
  2. Go to Tools->Backup and Restore Wizard, and perform a backup to a safe place
  3. Install Overseer on the new computer
  4. On the new computer, go to Tools->Backup and Restore Wizard, and perform a restore from the file you just backed up
  5. Uninstall Overseer from the old computer

At this point, Overseer network monitoring software should be running on your new computer with the resources from the old one. Note that this works both when using SQLite or MSSQL as Overseer’s database.

For more information, please see these entries in the help file:

Backing up the database

Restoring the database


Should you upgrade Overseer to use MSSQL?

Posted on November 12th, 2012

An Overseer 4.1 customer recently asked me when upgrading to 5.0, if they should consider using the MSSQL add-on. While some customers have explicitly asked for Overseer to utilize an MSSQL database, others aren’t necessarily sure what benefits it provides. This blog post will discuss the reasons to use the MSSQL add-in.



If you have hundreds of resources, and/or use a very short ‘check every’ setting on your resources, Overseer can spend a considerable amount of time waiting for the file system to write data to disk. The default SQLite database works well, but it is built with data-integrity in mind, versus performance– so sometimes a SQLite database will be slower than an MSSQL database. MSSQL uses different algorithms to assure data integrity, which work quite well, while not hurting performance as much as SQLite’s algorithms do.

Additionally, when Overseer uses MSSQL as its database, MSSQL can be running on the same or a different server. This has the potential to allow you to use a far more powerful computer configured as an MSSQL server(likely also used for other applications at your location).


Data Accessibility

If you have a need or desire to access the Overseer data, using MSSQL as the Overseer database is the ideal choice. You can easily open the database in standard MSSQL tools, or integrate easily with your website using code that simply connects to the MSSQL database and queries the data. This makes more extensive reporting possible, along with website status display, etc.



Overseer supports backing up its database using the Tools->Backup and Restore wizard. This works when using SQLite or MSSQL as the database. When MSSQL is used as the database, however, online backups can be performed using your standard MSSQL backup tools– potentially alongside other MSSQL databases used in your organization.


I’m convinced– how do I use it?

Once you’ve purchased the MSSQL add-on module, you can configure Overseer to use MSSQL as it’s database by following this blog post:

Using MSSQL for Overseer’s database



Overseer 5.0.89 has been released

Posted on September 24th, 2012

I’ve just released another minor update to Overseer, 5.0.89. This has a small bug fix that only affects people attempting to run the Overseer management application multiple times on the same computer(such as in multiple remote desktop sessions). Overseer 5.x was throwing a ‘System.UnauthorizedAccessException’ error. Note that to run Overseer multiple times such as this, the registry setting ‘HKLM\Sensible Software\Overseer\MultipleInstances’ must also be set to 1.   This build fixes the error message and allows Overseer to run more than once on the same machine.