nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

NPM/NCM, why are there two different nodes tables?

mtxpert

After doing a ton of work to group our 550+ network devices in NPM, I had to go back and redo it in NCM. Luckily I was able to do an alter table command however it seems very silly to keep node information in two separate tables in two separate databases.

Any goals to collapse the two separate products into a single database by just adding the additional tables when NCM is installed?

Find more posts tagged with

Database

integration

Accepted answers

All comments

chris.lapoint

Node management integration (perhaps not single DB) is definitely on the roadmap. The reason for separate DBs today is that NPM and NCM have traditionally been sold both as standalone products. We've recently begun providing more and more integration as customers like yourself have asked for both monitoring and config management to be available from a single pane of glass.

One thing we've done in NCM 5.x that you may not be aware of is we've added an Orion NPM import job to NCM (Schedule > Create New Job > Import devices from Orion database). This way you only have to make the changes once in NPM and then they will synchronize on a schedule you define.

HTH,

mleinio

One thing we've done in NCM 5.x that you may not be aware of is we've added an Orion NPM import job to NCM (Schedule > Create New Job > Import devices from Orion database). This way you only have to make the changes once in NPM and then they will synchronize on a schedule you define.

Chris, are you able to check (and possibly help) the situation with my case 91668 (IIRC...)? We are still having data integrity problems in this scheduled import process you describe.

Markku

chris.lapoint

Markku, I apologize. I didn't realize that you were the one that reported that issue with manually set transfer settings being changed on import. We've reproduced this in QA and we're looking at whether we can fix this in 5.5.1.

mleinio

Thanks Chris for confirmation on this issue. I wonder why the support case was closed without any communication with me on the issue.

Anyway, hopefully a fix will be available (public or private) as soon as possible.

Also, as a feature request for this import job, I'd really like to see possibility to use SNMP community as a selection criteria for importing nodes (now it is only possibly to use Vendor and Machine Type properties and "EnableNCMImport" custom property for selecting the nodes for import). Was there a feature request forum somewhere... :-)

Markku

pserwe

Markku, I apologize. I didn't realize that you were the one that reported that issue with manually set transfer settings being changed on import. We've reproduced this in QA and we're looking at whether we can fix this in 5.5.1.

Chris, realizing this is a pretty recent thread, but this Node Import functionality is one I've been looking for, for quite some time (a little less than a year).

Basically, I want NCM to synchronize the nodes from NPM, nightly would work, but it has to be clean. As it is, the general node import process on NCM isn't quite as clean as NPM, I'd like it to all get rolled into one process. This would follow along with the suggestion I made quite a while back to make the custom property data population a part of the node import process. That feature is the only thing that made me start using the web interface to add nodes!

I also need to reiterate how important a unified database for all products is, the "two products under one web front-end" thing is getting old, so much data and work is redundant between the two. Even simple stuff like custom properties.

So, in all of the above, there hasn't really been a question. The questions are:

1) How soon do you guys expect to be ready to release 5.5.1, making the workaround to the two-database system functional for ongoing maintenance?

2) How far down the roadmap is one database to rule them all, one database to bind them?

These are, relatively obvious questions, I would think.

Peter