shattori ✭✭✭✭✭

Yes. The reverse zone is there and correct. 

I have never found an answer to this. Unfortunately, the unmanage node utility is and always has been garbage. It just doesn't work consistently. What I do is create a fake SMTP server (127.0.0.1) and then I wrote a SQL query to switch that to the default SMTP server during maintenance, then I reboot my polling engines at…

I applied and and it's not looking good.

That's it! It did indeed trigger the reboot alert! You have no idea how much this has been driving us crazy. THANK YOU THANK YOU THANK YOU! Now...to wait for a patch.

I just applied the fix in our environment, still waiting for it to get pushed out to the servers. *fingers crossed*

Here's a down and dirty script. I don't have it in a SAM template, just scheduled on the servers. $process = Get-Process SolarWinds.ServiceHost.Process $threshold = '314572800' $mem = $process.ws if ($mem -gt $threshold){ Restart-Service -Name SolarWindsAgent64 -Force }

It's definitely worth a shot. I'll give it a try.

Yes, the fix was to populate that custom field for all nodes. I used a SQL script to do it ( vs. hand editing every node). It's now a required field when adding nodes.

There are no logs stating out of memory or anything related to snmpd on the hosts.

The article says "Note this issue means a loss of functionality to perform Cortex Real-time Polling against those agents". What functionality would be lost? I'm trying to figure out if it's better to disable this plugin or to continue to mask the issue by restarting the agent service.

I'm not convinced the hot fix they gave us actually resolved the issue, so I'm betting no. 

We had to write a PowerShell script to restart the agent after it got over 300MB. They say a patch is coming, but we needed to do something in the meantime.

The error clears within 10 minutes. Most of the servers are VMs (on VMWare 6.5, running a current set of tools), but some are physical as well. It does not seem to matter. I haven't seen false alerts on Linux servers, just the Windows boxes. I set a condition where the server has to be up for at least 10 minutes before the…

Nope, it was working for awhile and now it's broke again. The custom field is populated for all nodes and we're no longer getting down notifications again.

That is indeed true, we did resolve it by populating that custom field (which is not a required field).

This is great information, but I'm having to do this on a monthly basis. Is anyone else experiencing this? I'm getting very frustrated having to do this fix so often.

That's completely unacceptable. My case is still open (case 00203794). Try responding back and referencing the case numbers in this thread. For the life of me I can't understand why they would do that.

Will do.

We're on the latest version of everything, except NTA.

These are separate infrastructures in the same data center, but behind different firewalls and completely different security permissions. Can VMAN do that?

That is incredibly disappointing.

My apologies, I apparently don't get notified when someone comments on a post. We are in the process of updating the script to give more information (although Solarwinds is limited on the amount of messages that can be displayed). However, we just migrated Veeam to a Windows 2016 server and we're having issues with remote…

I have the same issue. Running Exchange 2016. Single server, no DAG. Did you ever get this resolved?

Go into the assigned application monitor (Settings --> All Settings --> Sam Settings --> Manage Application Monitors) In the left column Group By Application Monitor Template --> Click on AppInsight for Exchange --> Select the correct server in the right pane --> Edit Properties. Under the two entries for PowerShell at the…

Unfortunately that did not correct the issue. Still getting false alerts when a node becomes managed again.

Did you ever figure this out? I'm starting to go down this path. We were hoping to be able to monitor hardware health via the iDrac so I don't have to monitor my Windows server with SNMP (which is the only way to get disk information), but I'm running into the same issue. I'm on iDrac 9.

That would be a component down alert. You can go into the triggered actions and alter the default email template to include the information you want in there. For instance: Component ${N=SwisEntity;M=ComponentAlert.ComponentName} of Application "${N=SwisEntity;M=Application.ApplicationAlert.ApplicationName}" on…

Were you able to resolve this? I have them same issue.

We upgraded one of our environments to 6.5, now we're getting alerts every few minutes that our hosts rebooted. They have not rebooted.

I have an open case on this. No one has been able to resolve it, it's been escalated up a few levels at this point and am waiting on a response.