I have the NNMi Topology Integration working. It populates the "Node" ci's in RTSM correctly, and as expected. However, I was wondering if you guys have any advice on how I might enrich the results and populate the Windows ci with the Winodws Servers that NNMi knows about.
I realize that this is working as expected. Just want to know if there might be a way to make the Windows ci's actually show up as Windows ci's in RTSM. This would help me greatly down the road with SHR.
P.S. This trhead has been moved from Application Perf Mgmt (BAC / BSM) Support and News Forum to CMS and Discovery Support and News Forum. - Hp Forum Moderator
From NNMi directly - no way. From other data collector that you may have in your BSM that monitors the Windows servers and report them to BSM as Windows CIs - yes (in this case the 2 CIs will be merged by RTSM reconciliation mechanism).
Your response is certainly more than HP Support gave me.
Are you saying I could deploy a "probe" from the RTSM that would enrich or merge the CI's that are created from NNMi?
My situation is such that I have 300+ Windows servers that are only discovered and monitored for up/down via NNM. They don't have OM agents, and they are not discovered my our DDM probes.
I know the old way of integrating BAC and NNMi was a probe. Maybe I need to try something like that ? I dont need much, just the ability to have a Windows node from NNMi get set as a Windows CI in RTSM.
No, I didn't say about deploying a probe from RTSM. I was talking about BSM data collectors that could monitor the same Windows servers that are reported by NNMi as Node CIs. Example of such data collectors could be OM or SiteScope. If you don't have such data collectors in your BSM environment and don't use regular DDM discovery for those Windows servers then you are out of luck.
What you mentioned (the old probe based integration) is still available. However, it's not a recommended way to do topology sync from NNMi to BSM. Also the overall product direction is to change even this probe-based integration mechanism to report Node CIs rather than specific router, switch etc. CIs. I didn't check whether it was already implemented in the recent BSM and UCMDB versions, but I wouldn't be surprised if it is already there.
HP Support is saying I can use both the standard Topology Integration and the old probe, to achieve what I need. I'm leary of that.
Seems like it should be a lot easier than this, since NNMi knows these are Windows servers, and identifies them as such. I thought a rtsm enrichment would do the trick, but I strike out every time I try.
Note that if your environment does not have other data collectors to refine the NNMi data, all CIs
will be of type Node. In this case the Data Flow Probe "pull" integration method is more useful for
BSM, where functionality is based on more specific "strong type" CITs - sub-types of the Node
I strongly disagree with this statement, and don't really understand how it was made to the best practices guide. Having "strong" CITs is the least to be useful for BSM use cases. As I said I'm not sure that the "pull" integration in the recent BSM and UCMDB versions still produces CIs of "strong" CITs. I've just checked the list of discovered CITs for NNM_Integration adapter (used for the pull integration) in UCMDB 10.01 and BSM 9.22, and I don't see any "strong" CITs there any longer - no switch, router, Unix or Windows CITs etc.
Also I believe TBEC rules are designed to work with Node CIs, not Windows or Unix CIs. That's why the recommendation from the best practices guide doesn't look reasonable to me.
UCMDB and RTSM are designed to handle different use cases, so what can fit UCMDB use cases might not be such a good thing for BSM use cases. Does UCMDB care about TBEC? No, but BSM does. Does UCMDB care about real time discovery? No, but BSM does.
There is no way to change CIT of a CI based on any attribute value. There are very valid reasons why NNMi to BSM direct topology integration produces Node CIs with corresponding NodeRole attribute populated, rather than CIs of specific CITs.
Network devices can easily and dynamically change their role with only minor configuration changes in the device (or by adding a single card to the device). Reconciliation can make a CIs type "more specific" (i.e. change a Node into a NetworkDevice, or a Node into a Router), but it can only make those changes in the same "branch" of the CI Type Model. In other words, while a Node can become a Router (because Router is a subtype of Node), reconciliation cannot change a Unix CI into a Router (Router is not a subtype of Unix). These limitations/rules of CI Type reconciliation were just too limiting for today's network elements. Consider a Linux system discovered by NNMi. With just a minor system configuration (enable 2nd network interface, assign IP address and assign a route), this device has changed from a "server" type of device to a router. That is a change that is not supported by UCMDB/RTSM reconciliation rules. Or look at a network router that changes into a firewall just by adding a few ACL statements to the router's configuration. There are many more examples, both within the network domain, but also between "computers" and "netdevices", or even with application servers (regular computer becomes a voice gateway by adding e.g. Cisco CallManager software). For all these reasons, NNMi (and the BSM Data Model architects) decided to use "weak" typing with a "strong" NodeRole attribute for NNMi-generated topology.
Keep in mind that a single node can have multiple node roles, that was the original reason for the "weak" CI typing and introduction of the NodeRole attribute. NNMi will decide based on the node's capabilities (as discovered by NNMi) which NodeRole(s) to set. If a node has IP forwarding capability (com.hp.nnm.capability.node.ipforwarding), then NodeRole is set to "router". If the node has switching capability (com.hp.nnm.capability.node.lan_switching), then "lan_switching" is set.
Your scenario is no go. First of all, NNMi doesn't support simultaneous integrations with UCMDB and BSM, so #1 and #3 will contradict. When you have NNMi, BSM and UCMDB you have to decide where to integrate NNMi topology - to BSM or to UCMDB. It's either/or, not both/and.
There is no one universal answer that will fit all situations - whether to integrate NNMi into BSM or UCMDB. It will depend on the overall solution architecture, size of the environment, use cases and tons of other factors. In vast majority of cases if you expect NNMi events in BSM/OMi the direct NNMi to BSM topology integration is the way to go, with subsequent RTSM to UCMDB sync for network related CIs. But again there may be some factors that will point to NNMi-UCMDB integration as a preferred one.
yes, NNMi doesn't support simultaneous integrations with UCMDB and BSM, but ucmdb can be integrate nnmi using adapter (integration studio). and can be filter TQL to sync cis to bsm to avoid conflict. so 1 and 3 would be works good.
As I said # 1 and #3 together are not supported. NNMi is supported for topology integration to either BSM or UCMDB, not to both at the same time. You can test whatever you want, and it may work for you. But it doesn't change anything - you run an unsupported deployment, and take all risks associated with this.
Should you come across any issues and create a support case, and HP Support finds out that you run both UCMDB and BSM topology integrations from NNMi simultaneously, they will ask you to first revert to the supported deployment and reproduce the problem in the supported environment.