This Knowledge Base Article shall discuss the functionality around the Spectrum to CAPC integration device synchronization and discovery functionality.
Spectrum to CAPC Integration Details
Discovery, Spectrum Global Collection and Data Aggregator (DA) Discovery Profile details
It is important to start with the fact that Spectrum does not integrate with DA directly.
We often think of it this way, because we talk about using Spectrum to seed the DA with devices and their elements, but there are some subtleties to what's going on under the hood.
There may be a misconception among some users that the contents of the special CAPC IP Domain based Global Collection models in Spectrum will result in an IP list match between the "<DomainName>" Discovery Profile in CAPC. There is not always a one to one relationship between the IP addresses of device models that are members of those special Global Collections (GC) and the "<DomainName>" Discovery Profile in CAPC DA views.
When a Spectrum OneClick server is added as a Data Source (DS) in CAPC, CAPC pushes IP Domains to Spectrum OneClick. The "integration" code in Spectrum OneClick implements this push by the creation of CAPC IP Domain based models in Spectrum. Although the CAPC IP Domain model type is derived from a Global Collection it is important to understand that it is not a Global Collection as might be normally known to Spectrum users. There are special behaviors that go along with this model type that are not available to normally created Global Collections in Spectrum.
At this point in Spectrum you should see a CAPC IP Domain based model for each IP Domain in CAPC. They will be found in the Spectrum OneClick client console under the Global Collection listings at the global level of that view, independent of other landscapes configured in Spectrum. The user can then configure search criteria or manually add devices to these CAPC IP Domain based Global Collections, the same as can be done for other standard Global Collections.
Once devices are added to those Global Collections as members, on the subsequent synchronization cycle pull phase from the Spectrum Data Source in CAPC, those devices are synchronized to CAPC. This is important for a couple of reasons:
- Ensures the devices are reconciled in CAPC with devices from other Data Sources correctly
- If you have Data Aggregator as a DS you can map everything to the Data Collectors (DC) you want to use to monitor specific devices. For example mapping specific Spectrum landscapes to specific IP Domains, and thus specific DCs.
That is the "nuts and bolts" of how Spectrum participates in Inventory synchronization with CAPC.
Independent of the above information, the DA is a special Data Source unlike the others created for integration with CAPC, such as the Spectrum Data Source.. It can be configured to discover devices from other Data Sources. Notice the terminology "other Data Sources". It is important to understand that function is not specifically limited to the Spectrum Data Source. When this switch is enabled for the DA., when the DAs next synchronization cycle arrives, any devices in CAPC which the DA does not know about are pushed to the DA.
What the DA does with them is add the IP to a system configured Discovery Profile which is maintained for each IP Domain. A key point:
This is only for devices the DA doesn't already know about.
These system created Discovery Profiles can be launched manually, or scheduled to run on a user defined schedule, same as any other Discovery Profile in the DA.
If the device is one previously discovered in the DA, prior to the device being synchronized via the integration, as manageable (i.e. SNMP polled) the IP is removed from the default domain based Discovery Profile. This is because the DA is already monitoring the device based on the selected Monitoring Profiles (MP) that are configured for the Collections the device is a member of.
If the device is discovered as a Pingable device type, the DA will begin monitoring the device for Reachability metrics, but the IP will remain in the discovery profile allowing application of other SNMP Profiles configured in the DA that may update the device to an SNMP Managed one at a later discovery run.
If the device can't be reached with either Ping or SNMP, the IP remains in the Discovery Profile, allowing for ACL, firewall or other network adjustment such that the DCs can reach the device for successful discovery as either a simple Pingable device, or as a more complex SNMP manageable device.
Some common questions around this product functionality we are asked are:
I haven't added device models in Spectrum to the special integration Global Collections for synchronization to CAPC. With those GCs in Spectrum empty of members, why are there so many IP addresses in the <DomainName> Discovery Profile in the DA? No users populated that Discovery Profile with IP addresses. Was that created and populated with IP addresses from devices previously synchronized to CAPC under the older integration methods and functionality?
Answer for Question 1
The most likely scenarios for such a situation are:
- They come from another Data Source not Spectrum, could be NFA, eHealth etc...
- They were in the default CAPC IP Domain in Spectrum at some point, and maybe removed
- A prior Spectrum integration with 9.2 and CAPM 2.3 could have done it
There are devices that haven't been synchronized from Spectrum to CAPC via the integration. They were discovered in the DA independent of the integration code, with normal Discovery Profile execution using a custom user create Discovery Profile. The IP address for those devices does not exist in the special <DomainName> Discovery Profiles in the DA. When those devices are then added to the integration and synchronized from Spectrum to CAPC and the DA via membership in the special Global Collections in Spectrum, their IP addresses are still missing from the list in the <DomainName> Discovery Profiles. Why were they never added to that <DomainName> Discovery Profile?
As described above, this is due to the fact that the DA had already discovered the devices and they were already configured for polling. When that condition is observed by the integration code it will maintain the configuration as it is rather than potentially duplicating discovery activities with the IP existing in multiple Discovery Profiles that could run on schedules.