Alert Variable issue

smiffy85​

I fixed a similar issue for a client last week.  Make sure your websites table in the db has the server name correct and ssl checked.  If those are both good then most likely the cell you are looking for is on the websettings table.  There are several rows which reference the name of the orion server for different purposes so you might end up having to get on the line with support to have them help you ID the row that you are missing, I'd guess that you may need to put the server name in the SwisUriSystemIdentifier row.

-Marc Netterfield

    Loop1 Systems: SolarWinds Training and Professional Services

•                 LinkedIN: Loop1 Systems
•                 Facebook: Loop1 Systems
•                 Twitter: @Loop1Systems

If u have changed any settings related to ur website then I guess that is where u need to check. I haven't come across this issue but when we enabled SSL for our client, some links were not coming correctly. But the issue was more around certificate for us.

mesverrum​ it was indeed the SwisUriSystemIdentifier

I had changed it but it didnt take effect on emails until today, thanks for your help.

I found your post very interesting and I had hoped that your fix would also work for me, but it did not.  I have email alerts that are being sent out with the same problem - no HTTPS and shortname instead of the FQDN.  My issue is different as my alerts are querying SwisEntity and Alerting.  do you know where these values are stored so I can update them?

this is the details from a email trigger

An issue on an object you are monitoring occurred at ${N=Alerting;M=AlertTriggerTime;F=DateTime}.

View full object details here: ${N=SwisEntity;M=DetailsUrl}.
View full alert details here: ${N=Alerting;M=AlertDetailsUrl}
Click here to acknowledge the alert: ${N=Alerting;M=AcknowledgeUrl}

I am running NPM 2015.1.2

Thanks

Guys, I just found this thread. URLs are generated per content of the Websites table.

NEVER EVER change the SwisUriSystemIdentifier record unless you exactly know what you're doing. 

The fact, that some people may claim the change helped them is given just by mixing of more updates at the same time. SwisUriSystemIdentifier is internal record, serving for generation of objects identifiers. By changing it, you're risking serious system inconsistencies (breaking the Dependencies, Containers, Alert Configurations, limitations and many other places which store the object identifiers in the database) and the consequent repair is not trivial at all.

So it sounds like if websites is set correctly you probably just need to restart the services or would you need to do a config wizard/db maintenance to have the value propagate the value out?

-Marc Netterfield

    Loop1 Systems: SolarWinds Training and Professional Services

•                 LinkedIN: Loop1 Systems
•                 Facebook: Loop1 Systems
•                 Twitter: @Loop1Systems

I have seen this in my instance couple of times...usually its due to the variables not supported for the current version of Solarwinds or an issue with contacting the database...

So, from the way I'm reading this Solarwinds created multiple different variables that reference the name of the server.  However, they also have different locations where the server can be named, and in different formats.  Finally, they program the many different variables to reference the many different host name data fields at random thereby leaving it up to us to guess which variable is using which name.......

In my case someone created two different "servername" name and formats (one FQDN and one not) within our website DB, I don't know why.

Now we have two different variables in our alerts and they are returning two different results for the hyperlink, one FQDN and one not.