Planning to populate BMC Helix CMDB
If you plan to discover configuration data, you need BMC Discovery products or third-party discovery products. This documentation assumes the use of BMC Discovery products. If you have already discovered your configuration data with other tools and that data resides in a database or flat files, use Atrium Integrator to transfer that data to BMC Helix CMDB. For details about how to transfer data, see Transferring-data-from-external-data-stores-to-BMC-Helix-CMDB.
Select a discovery provider
If you are implementing discovery products for the first time, select either the BMC Discovery product, the BMC Client Management product, or a third-party discovery tool as your discovery provider. If you want to use both BMC discovery products, use them to discover different endpoints. In this situation, duplicate CIs are not collected and imported to the production dataset.
To select the appropriate BMC discovery provider, consult the following topics:
- Configuration data discovered by BMC Discovery
- Configuration data discovered by BMC Client Management
If you identify multiple providers for a class or attribute, you must later identify which provider's data will be reconciled to the production dataset.
Recommendations
Consider these suggestions when working with discovery sources:
- Do not load every discovered CI into the CMDB on every transfer. Transfer only new CIs and CIs that have been modified since the previous transfer.
- You do not have to populate each possible class with every one of your data providers. Bring into the CMDB only the data that is used by a data consumer to make key business decisions. If no application is consuming the data, there is no value in maintaining and managing it in the CMDB.
- If you are using more than one discovery source to populate an attribute and those sources format the attribute's value differently (for example, one uses capital letters and the other does not), then you should not rely on those values being formatted consistently in your production dataset. Though one discovery dataset will take precedence over the other in reconciliation, there will be cases where the production dataset receives its value from the lower-precedence dataset. For example, a CI might not yet have been imported into the higher-precedence dataset or might have a NULL value for the attribute in that dataset.
Therefore, you should normalize the values of such attributes between datasets before reconciliation. You can use the Normalization Engine to do this for specific attributes. For others, you would need to normalize before importing to BMC Helix CMDB.
- When deciding how often to transfer data to the CMDB, ask yourself how often the data changes and how important it is that you pick up those changes. You might want to split your transfers into longer intervals for stable things like facilities data and shorter intervals for volatile things like network data.
- Network discovery applications are not the only type of discovery source that you can use to update the CMDB. LDAP systems, Human Resources systems, Facilities systems, third-party Asset Management databases, and others can serve as discovery sources.
Configuration data discovered by BMC Discovery
BMC Discovery has the capacity to integrate with CMDB and push the configuration data into BMC Helix CMDB.
For other discovery products such as BMC Client Management, Microsoft SCCM, or other external datasources, Atrium Integrator pulls the configuration data from these data sources and transfers that data into BMC Helix CMDB.
The BMC Discovery product builds a complete topology of your applications and infrastructure including switches, servers, operating systems, software, configuration files and logs, business applications and dependencies. Its discovery is agentless and uses standard management protocols such as SSH, WMI and SNMP.
Configuration data discovered by BMC Client Management
The BMC Client Management product collects hardware and software inventory information about desktops, laptops, and handheld devices across major platforms within your company. For more details, see Integrating with BMC Helix CMDB in the BMC Client Management online documentation.
For a complete list of the CIs and relationships imported into BMC Helix CMDB, see the BMC Helix CMDB - BMC Client Management class mapping.
Transfer existing configuration data with Atrium Integrator
Atrium Integrator enables you to transfer data between an external data store and AR System forms or BMC Helix CMDB classes. For example, if you have existing data that has already been discovered with a non-BMC discovery tool, you can use Atrium Integrator to transfer that data to BMC Helix CMDB.
Atrium Integrator can transfer data between Microsoft SQL Server, Oracle, IBM DB2 Universal Database, XML files, flat files such as comma-separated value (CSV) files, BMC Helix CMDB, and AR System. For more information, see Transferring-data-from-external-data-stores-to-BMC-Helix-CMDB.
How Calbro Services discovers CIs
Calbro Services uses the BMC Client Management product to discover the desktop and laptop computer systems (including hardware and software), used by Calbro Services employees.
Calbro Services also uses BMC Discovery to discover information about the servers, software, and other devices used to deliver banking information to Calbro Services customers.
Lastly, Calbro Services uses a third-party discovery tool to collect information about the equipment that supports the corporate payroll services. Calbro Services uses Atrium Integrator to bring relevant data from the payroll database into BMC Helix CMDB.
Assessing the configuration data source environment
Based on your configuration data requirements, identify the systems (endpoints) from which you will gather the configuration data, how you will access those systems (based on agentless or agent-based discovery), and the impact of the data collection process on production activities and the network. Following are some questions to consider:
- Which endpoints contain the data that you need to discover?
- How many endpoints need to be discovered?
- Should the endpoints be discovered using agentless discovery or agent-based discovery and will that discovery methodology be allowed in the IT environment?
- What type of endpoints need to be accessed: servers, desktops, laptops, hand-held devices, mainframes, or network devices?
- Which ports are opened on the firewall?
- What credentials are required to access the endpoints?
- Will discovery impact production systems or the network?
For more information about planning discovery with BMC Client Management, see the Integrating with BMC Helix CMDB.
Managing unqualified data
Your discovery tools might be unable to identify a device at an endpoint they discover. The unknown device might be a laptop computer, printer, router, server, or some other piece of hardware. For example, your discovery application might discover an IP address, but lack the proper credentials to access and identify the device at that IP address. Information about unknown devices at known IP addresses is called unqualified data .
Consuming applications can use unqualified data just as they use qualified data. For example, a performance management application can establish performance monitors at known IP addresses for unqualified data. The application does not need to establish new monitors if the unqualified data becomes qualified.
To configure unqualified data, create BMC_ComputerSystem configuration items (CIs) in BMC Configuration Management Database (BMC CMDB), with the IsUnqualified attribute set to Yes. Connect these CIs to discovered BMC_IPEndpoint CIs by BMC_HostedAccessPoint relationships.
For example, Calbro Services discovers three IP addresses, but cannot identify the devices at those IP addresses. The administrator creates BMC_ComputerSystem, BMC_IPEndpoint, and BMC_HostedAccessPoint instances as shown in the following figure.
Unidentified devices at known IP addresses
If Calbro Services later learns the identity of a device at an IP address, the administrator updates BMC Helix CMDB by completing the following tasks:
- Create a new BMC_IPEndpoint* CI, a new CI for the identified device, and the appropriate relationship instance between those CIs. Set the {{IsUnqualified attribute to NULL.
- Mark the original BMC_IPEndpoint, unqualified BMC_ComputerSystem, and BMC_HostedAccessPoint instances for deletion.
- Create a BMC_BaseRelationship instance between the unqualified BMC_ComputerSystem CI (the source CI) and the new CI that represents the identified device at that IP address (the destination CI). Set the Name attribute of the relationship to CorrespondsTo. This enables you to know which qualified CIs correspond to previously unqualified CIs. When the unqualified BMC_ComputerSystem CI is deleted, the orphaned BMC_BaseRelationship instance is also deleted.
Extending the example started in the following figure, Calbro Services gains credentials to access to the unknown devices, and learns that all three IP addresses are used for a single computer system. The administrator creates new CIs and relationships for the computer system and its IP addresses, marks the original CIs and relationships for deletion, and creates new relationships between the old and new BMC_ComputerSystem CIs to indicate that the unqualified CIs have been qualified as a single computer system. The following figure shows the qualified data associated with the unqualified computer systems marked for deletion.
Qualified data associated with unqualified data
Identifying the discovery schedule sequence
The initial and ongoing population of BMC Helix CMDB should be based on the following criteria:
- The requirements of the consuming application
- The amount of data to be collected
- The availability of the data
- The demand on the production environment and other performance factors
- How often the data changes and needs to be updated in the CMDB
After the initial discovery and population of BMC Helix CMDB, the Discovery Manager and Configuration Manager need to set a schedule for discovering changes (new, modified, or removed configuration items (CIs)), importing the changed CIs to BMC Helix CMDB, and merging the changed CIs with the production configuration data. If you use non-BMC discovery solutions, you must determine how best to schedule an ongoing discovery process.
Guidelines for scheduling and running BMC Discovery scans
In BMC Discovery, you must first select one of the following scanning levels to use:
- Sweep Scan — Confirms only that there is an IP device at each endpoint in the scan range.
- Full Discovery — Retrieves all the default information for hosts and complete full inference.
In the Configuration Settings, you can set the number of concurrent discovery requests. As this number gets larger, performance could be negatively impacted, especially in environments where the network is slow to respond. The default value varies for each appliance, and is calculated to achieve maximum performance. However, if you experience a situation where many discovery commands are timing out, you can adjust the default value to between 30 and 150 (in increments of 30). Generally, the more discovery requests you enable to process concurrently, the more you increase network traffic and the absolute time to discover a single host. However, you can use different settings as part of an overall approach to improve discovery processing throughput.
For more information about configuring discovery settings and recommended performance factors, see the BMC Helix Operations Management online documentation You can also download a PDF version of the guide.
Guidelines for scheduling and running BMC Client Management tasks
You can schedule the transfer of data from the BMC Client Management database to BMC Helix CMDB by creating one or more Atrium Integrator jobs. After each discovery task is completed, run a job on a scheduled day and time, at a timed interval, or when triggered by an event such as the triggering an active link or filter. For more information, see Transferring-data-from-external-data-stores-to-BMC-Helix-CMDB.