One NCM server for 2 sites

Along with the question above, it is also possible to have one NPM server forward a syslog or trap message to the other NPM server that I could then call the configautodownload from?  I don't want to have to send all the logging information to one server.  I would like to only send the needed information for a RTCD.

Along with the question above, it is also possible to have one NPM server forward a syslog or trap message to the other NPM server that I could then call the configautodownload from?  I don't want to have to send all the logging information to one server.  I would like to only send the needed information for a RTCD.

NPM can forward the Syslog message, but it won't retain the original source IP address.   It will look like it's coming from the Orion server, which won't work for RTCD which depends on the source IP address.

Alternatively, you can use Kiwi Syslog server which has the ability to act as a transparent proxy and simply forward on specific Syslog messages.   I know what question is coming next ;-)   As described in previous posts, our plan is to integrate Kiwi Syslog server technology / capabilities into Orion over time.

Along with the question above, it is also possible to have one NPM server forward a syslog or trap message to the other NPM server that I could then call the configautodownload from?  I don't want to have to send all the logging information to one server.  I would like to only send the needed information for a RTCD.

NPM can forward the Syslog message, but it won't retain the original source IP address.   It will look like it's coming from the Orion server, which won't work for RTCD which depends on the source IP address.

Alternatively, you can use Kiwi Syslog server which has the ability to act as a transparent proxy and simply forward on specific Syslog messages.   I know what question is coming next ;-)   As described in previous posts, our plan is to integrate Kiwi Syslog server technology / capabilities into Orion over time.

Yes, this should be possible.   If you are using the NCM integration module, it only displays devices that exist in NPM.   So, you can use your node limitations on accounts as you would normally to restrict access to nodes.    FYI, in our next release of NCM, we plan to make all of the capabilities of the standalone NCM webconsole available in NPM (including upload, download, execute script).

Is there any way to allow the nodes to be viewed in NPM but not show the link to NCM?  Once they used the NCM link, they would be able to see anything they wanted correct?

NPM can forward the Syslog message, but it won't retain the original source IP address.   It will look like it's coming from the Orion server, which won't work for RTCD which depends on the source IP address. Alternatively, you can use Kiwi Syslog server which has the ability to act as a transparent proxy and simply forward on specific Syslog messages.   I know what question is coming next ;-)   As described in previous posts, our plan is to integrate Kiwi Syslog server technology / capabilities into Orion over time.

I figured that would be the response.  Its interesting because we partly sold the Orion tools as a way to get away from the Kiwi tools and to standarize one one platform.  Now it looks like we're going back to them!  You also know what my next question is...  What does "over time" mean? 

If Kiwi isn't an option, what would you recommend we do if we want to use the RTCD features but don't want all of the syslog data traveling that far?

Is there any way to allow the nodes to be viewed in NPM but not show the link to NCM?  Once they used the NCM link, they would be able to see anything they wanted correct?

Yes.   Go to Admin > Account Manager > Edit Account.   Scroll down to "Network Configuration Manager settings".   Set default view to "none".   That should remove the Network Configuration Manager link for the user.

I figured that would be the response.  Its interesting because we partly sold the Orion tools as a way to get away from the Kiwi tools and to standarize one one platform.  Now it looks like we're going back to them!  You also know what my next question is...  What does "over time" mean?  :)

Nicely done sir.  I was setting you up for that one ;-)

We have plans to make significant steps toward this effort this year.   We're actually working through the details of what that would look like right now.  What Kiwi Syslog features (besides the one mentioned above) do you miss and would want migrated to an Orion Syslog solution?

Sorry about the delay in getting back to you. 

To be honest, we barely used the features of the syslog server at all.  We basically used it as a way to archive error messages so we could look through them later to look for patterns.  We also monitored it to make sure that we didn't see a sharp spike in the amount of logs we got.  We knew if there were, there was most likely a problem.  We used the free version. 

The thing I like about it was the fact that we had devices grouped by facility and then those facilities were each archived to a file once a week.  The files usually stayed pretty small and it was a nice way to keep that data if it was needed.  I'd like that to still be available since I haven't seen a good way to do it with the current syslog tool.  (I'll be honest, I haven't looked either.) 

One thing that would be nice that maybe you've thought about.  For our larger remote sites that have their own it staff, it would be nice if they could use the syslog server and have it forward the data to the Orion NPM server in a compressed fashion to reduce bandwidth use.  (The compression would be a nice feature but the ablity to have it gathered and forwarded would be more important.)