8 Replies Latest reply on Sep 22, 2017 10:21 AM by MRobare

    Alert Variable issue




      I had a similar issue previously regarding the Alert Variables that where used when sending an email out to Support.  It was sending the wrong URL.

      This has now occurred again, however the fix to enable SSL in the DB isnt the problem, when I use the Variables below I get the link in blue.


      ${N=SwisEntity;M=DetailsUrl} http:///Orion/UDT/EndpointDetailsRedirect.aspx?NetObject=UE-DNS:2470



      This is not even close to being correct - it should read https://websiteaddress/orion/udt....etc

      Any idea where I can fix this please?



        • Re: Alert Variable issue


          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

          2 of 2 people found this helpful
            • Re: Alert Variable issue

              mesverrum it was indeed the SwisUriSystemIdentifier


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




              • Re: Alert Variable issue

                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.

              • Re: Alert Variable issue

                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.

                • Re: Alert Variable issue

                  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



                  • Re: Alert Variable issue
                    Jan Pelousek

                    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.

                    2 of 2 people found this helpful