Orion Integration does not work in Multi-Instance WHD deployments

I have several WHD instances, all running near at latest versions due constant attempts to mitigate issues introduced in each version with character display, scheduling and other quirks....

One of the items I've been troubleshooting for a while is Orion integration. This works without issue in a single instance WHD (one WHD server with either an embedded or external DB), but does not work with different errors in a multi-instance deployment. For WHD, "multi-instance" refers to running more than one WHD application server with one DB. For example, I have two WHD front-end servers that run with daemon mode set to none and a third server dedicated to daemon responsibilities. The two front-ends are load balanced behind a VIP.

I've had a couple support tickets open on other matters with 'clustering' (WHD terminology) deployments with regard to some view issues and now this Orion integration. All of the available documentation on the matter makes this a straight forward configuration action and is easily accomplished in a non-clustered, single server environment. Come to find out after a couple weeks of back and forth on the matter it turns out there is an 'internal engineering' document on this exact integration that is not published anywhere I can find and states as follows (per support):

We apologize for any inconvenience.

As per our Application Engineers, we don't have public documentation on this limitation but that doesn't change the fact that it is.

This is a limitation that was mentioned when a feature was released in the Engineering training.

Known Issues and Limitations:

1. Change of WHD hostname or port will break existing Orion connections
2. Not supported in hosted environments
3. Not supported when load balancing multiple WHD instances

Now, why this isn't available or stated in the admin guide or the dedicated Orion integration document I don't know. But hopefully this shows up if someone else is encountering issues with features of the product not working in supported deployment scenarios and maybe it will get the visibility it needs to remove the 'Issues and limitations' on existing features before time is spent on new ones.

Some of the issues you'll encounter, for search indexing purposes are 'Invalid JSON String' during the filter creation process that won't let you proceed any further. This occurs on the front-ends without the daemon enabled. When attempting on a daemon server running in background mode, you'll get an unresponsive 'Next' button in the filter configuration page with javascript errors in the browser console.

Thanks

James

Find more posts tagged with

webhelpdesk

integration

whd

Alerts

Comments

james.kluza

The issue with this, it appears, is how the subscription is created in Orion and I believe the certificate that is used for credential encryption.

- The Credential

In a multi-server environment, the certificate used to encrypt the credential could be different. So, depending on which server you are using to create the connection and which one the sub service hits as a response might not match.

- Sub EndpointAddress

This is defaulting to whatever is configured as Server DNS Name in General > Options > so if you are using a VIP that is what the subscription points to in Orion.

I've been able to get this configured by:

1. Creating the connection as usual from the daemon server which is in the same subnet as Orion

2. Backing out of the SolarWinds Orion configuration in Web Help Desk and manually updating the Orion_Alert_Filters table

3. Click back through the Orion connector setup in WHD and it will save and show both Orion and Filters as 'Configured'

4. Manually update the subscription for the Web Help Desk in the Orion DB to point to the daemon server instead of the VIP address.

What I find interesting is now I can trigger an alert and I see that activity in both the PendingNotifications and Subscriptions tables and they clear and show successful delivery as expected, however, the tickets are not being created in WHD. I feel this is close to working. Maybe an issue with the filter setup.

james.kluza

I got this to work, as follows:

1. Create the connection from WHD and click test, but do not click next.

2. Find the id of the record created in dbo.orion_alert_filters

3. Insert a new row into dbo.Orion_Alert_Filters with the following (obviously you should have a backup of your DB before direct edits, do so with caution, etc.)

INSERT INTO dbo.orion_alert_filters VALUES(1,'',0,)

4. Back in the console, click 'Next' and create the filter like normal. Click next.

5. Validate your criteria if you want and then finish the wizard. At this point, you should see both the connection and filter as 'Configured'

6. If you have a second front-end, log in to it directly, click through the wizard until done and it too should show 'Configured' in both categories.

Test your alert from Orion.

This may or may not work for you. Heck, I may have lucked out and hit the frontend that I configured it from initially and that is why it's working, but I will be trying in another environment later and will report.

One thing to note is that I don't think Orion either likes or supports having two separate WHD subscriptions in one Orion. I had both my test and production in there and while both are in there and they show successful deliveries, tickets won't open.

Good luck.

pabely

We were told by Support that WHD does not support multiple links to n number of separate Orion installations, which is most annoying as it lets you config this in WHD. WHD links to multiple Mailboxes, LDAP, Asset Discovery connections etc.