Is Microsoft Message Queuing required for proper Additional Poller operation?

joedissmeyer · 2016-04-09T03:44:13+00:00

* Does Microsoft Message Queuing on additional polling engines need to have the ability to communicate with the primary poller? * More specifically, do I need to enable TCP 1801 traffic from the additional polling engines to the primary polling engine? * And if I don't enable the traffic, what will happen if I don't do…

joedissmeyer

Does Microsoft Message Queuing on additional polling engines need to have the ability to communicate with the primary poller?
More specifically, do I need to enable TCP 1801 traffic from the additional polling engines to the primary polling engine?
And if I don't enable the traffic, what will happen if I don't do this? What will be 'broken'?

I ask because of an issue we continue to have with one of our additional polling engines where TCP 1801 is NOT allowed from the AP to the Primary and the MSMQ folder keeps on filling up with orphan data, triggering the Orion Server SAM monitor.

Here is a rough sketch of our current Orion environment:

Some important notes:

The primary polling engine and additionals 1-3 are all on the same network subnet, and are members of the same active directory domain.

Additional polling engine #4 is able to communicate to SQL and the primary poller. It is a member of a completely different active directory domain and different network subnet.

There is a firewall between Domain A and Domain B.

When I look at the Message Queuing service on the first three APs I see they are successfully connected to the primary poller and messages are being sent to it.

2016-04-08 23_35_18-mRemoteNG - confCons.xml.png

But on the AP that has the MSMQ issue it is not successfully connected and is stuck in "Waiting to connect".

2016-04-08 23_38_45-mRemoteNG - confCons.xml.png

Find more posts tagged with

additional poller

npm 11.5.3

message queue

msmq

sam 6.2.2

Accepted answers

All comments

joedissmeyer

I opened support case # 970690 to get an answer on this.

lynchnigel

It says in the documentation that its a 'feature' that enables the local storage, using MSMQ of upto 1GB of polled data per poller in the event that the connection between polling engine and the database is temporarily lost. The question to the side is 'poller remotely available'

MSMQ V.3 ?

Diner

Hello,

per my knowledge the AP MSMQ doesn't need to talk to the Primary engine. However the AP needs to talk to the Primary Information Service and BusinessLayer (Orion Module Engine). I can't see the entire name of the queue, but if that belongs to the Information Service, that may mean, that AP is unable to deliver the PubSub messages (typicaly informations about changes in polled data) to the Main.

So what you need here is:

Assure (on DNS level or the hosts file), that the NetBios name is resolvable to the reachable IP address in both directions (AP can resolve Main NetBios name to IP and vice versa)
Open TCP ports 17777 and 17778 between Main and AP (communication to the BL and InformationService)
Assure, that AP can talk to the database
APE surely needs to have it's local operational MSMQ as it's used as midware layer between the Collector DataProcessor and Database + the temporary storage for the messaging between main and APE

I hope it helps.

Regards,

Honza

bkyle

Please see this link:

MSMQ installation errors - SolarWinds Worldwide, LLC. Help and Support

Diner

Excuse me, but I don't see any relation to the topic. Joe didn't mentioned any problems with MSMQ installation. Regarding the remote polling, lynchnigel already posted it, so for completeness I edited my post, so it will be visible why the APE needs the MSMQ

joedissmeyer

Thank you Jan. This is my issue. I only allowed port 17778, not 17777 through the firewall.

I'll submit a firewall change request on our end and go from there.

joedissmeyer

Just a follow-up to this issue:

Our issue with the MSMQ on the APE has now been resolved. We put in a firewall request to open up both TCP 17777 bi-directional but the MSMQ issue persisted. We submitted another firewall request to open TCP 1801 bi-directional and after doing that MSMQ communication from our Additional Polling Engine to the Primary Poller (master) started working. Bi-directional may not have been needed but we asked for it just in case. Since doing this we haven't had any issues.

Side-note: With the new NPM v12 and SAM v6.2.4 release there is mention in the release candidate planning documentation that RabbitMQ messaging will be used and will require to open up TCP 5671 between APEs and Primary pollers. So we went ahead and already asked to open up that port bi-directionally as part of our upgrade plan.

lynchnigel

Thats good news and thank you for letting us know, i'm setting up an additional poller on another site soon and so it will come in handy to know.

Quick Links

All Categories
Recent Posts
Activity
Unanswered
Groups
Help
Best Of