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

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 HKLM\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.

MSSQL Log file is too large

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.

 

 

Warns and prevents deletions of items that are used

Previous versions of Overseer would sometimes let the end user accidentally delete something important… Most notably, Overseer would allow the user to delete a resource group that has resources in it. This would make those resources inaccessible, even though they’d still be monitored and alerts sent. This is obviously not a good thing, so in Overseer 5.0, I went through all the ‘things’ in Overseer, and added a quick check when deleting them– now if you try to delete a notification, notification group, schedule, resource group, etc. that is in use by another item(i.e. a resource using a schedule for network monitoring), Overseer will prevent you from doing so and explicitly tell you why.

Another “Network Path was not found” gotcha

When testing Overseer 5.0, I got stuck on a “Network Path is not found” issue. I was testing with workgroup-based computers instead of domain-based computers, and I was quite certain it was due to this setup that the problem was happening– as my domain based computers continued to work fine, even connecting to workgroup-based computers…

Eventually, I tracked this down to using usernames such as “.\administrator”… Sometimes Windows uses these, so you’d think it’d be OK– but when connecting FROM a workgroup-based computer to another workgroup-based computer(and maybe domain computer; I didn’t test that), you’ll get a “Network Path was not found” error– totally useless for an obvious **username** issue… While there are many causes of the network path was not found error, this is one that I didn’t know about until today.

Oddly enough, I did a network tap when trying to figure this out, and I saw Windows attempting to connect **on port 80** to the computer, versus using SMB ports(139, 445, etc.)… This was crazy, yet I could find no information online about this– obviously, it’s using the WebClient service instead when it sees a username like this…I’m still not sure why.

So, bottom line– if you’re receiving a “network path was not found” error, and you’ve gone through the checklist, make sure you’re not using .\username when logging in.

If you’re using Overseer network monitoring software, Overseer will automatically change a username without a domain qualifier into the appropriate MACHINE\username– so simply enter the username, and you’ll be OK.

Known issue: Licensing information ‘lost’

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.

 

NOTE: This has been fixed in 4.1.46.

Categories: