Filtering Network Adapters from CORA Registration (Slow Engine Collect of Computer Registrations, Slow Engine Replication & Synchronization)

Document ID : KB000072535
Last Modified Date : 02/03/2018
Show Technical Document Details
Engines processing Collect tasks are slow or crash while processing new or updated computer registration messages.
Client Automation (ITCM) -- any version.
CORA is the Common Registration API, and is the interface used by Client Automation to share computer registration data with other CA products (i.e. CA Service Desk Manager).  Even if you're not integrating Client Automation with another CA product, the engines processing the collect task are still registering computers (and network adapters) with CORA during the processing of registration messages.
When the engine processes a registration message it performs a CORA registration of the computer and its list of network adapters.  When CORA performs a registration of a network adapter that is not unique, i.e. the Microsoft Tunnel Adapter "00:00:00:00:00:00:00:E0", it forces CORA to compare the registration details with all existing records reporting the same MAC address.  Depending on the number of network adapters already registered with this address, this comparison will delay the CORA registration, resulting in a delay of the engine to process registration messages or even cause the engine to crash.
To address this problem, you'll need to identify the non-unique network adapters found in your environment, and create a filter for the engine, to prevent these adapters from getting registered with CORA.  Follow these steps to identify the problematic adapters and create the appropriate filter:
Note: Before proceeding with this solution, a full database backup is recommended, as changes will be made to the database to resolve the issue.
Step 1: Identify the non-unique adapters present in the database.
Run the following against the mdb for Client Automation in SQL:
select mac_address, count(*)
from ca_discovered_hardware_network
group by mac_address
having count(*) > 10
order by count(*) desc
Here's a sample result set you might see:
Based on the output, it seems we need a filter for the following MAC addresses:
Use discretion when determine which addresses to filter.  It is not necessary to filter every duplicate adapter, as some duplication can be expected when computers are re-imaged or upgraded, and not all obsolete computer objects are cleaned up in Client Automation.
Step 2: Create the filter for the engine in the Client Automation comstore.
During engine initialization, cmEngine.exe checks the comstore for a parameter called "MAC_filter" to use for network adapter registration filtering.  You can set the filter using the following command:
Following from the sample data above, type the following to create the filter parameter:
ccnfcmda -cmd setparametervalue -ps /itrm/manager/engine -pn MAC_filter -v "00:00:00:00:00:00:00:E0;00:50:56:86:20:C2;00:50:56:C0:00:01;00:50:56:C0:00:08"
Note: The above command should be given as a single line, without any breaks/carriage returns.
To verify the configuration, type:
ccnfcmda -cmd getparametervalue -ps /itrm/manager/engine -pn MAC_filter
Step 3: Remove the existing duplicates from the database.
Run the following against the same mdb used to identify the duplicate network adapters, in order to cleanup the existing duplication in the database:
Note: The statements below follow through from the sample results in Step 1. Be sure to use the appropriate MAC addresses based on results specific to your environment.
delete from ca_discovered_hardware_network where mac_address in (
delete from ca_logical_asset_property where mac_address in (
Note: Records stored in ca_logical_asset_property do not have the ":" delimiter between the MAC address octets.
Step 4: In order for the engines to read the new network adapter filter from the comstore, CAF must be recycled.
Additional Information:
In an Enterprise Manager environment, the MAC_filter parameter must be set on each Domain Manager, as this comstore parameter is not replicated by Configuration and State Management. 
These filters are not applicable to the Enterprise Manager, as the engine processing replication on the Domain Managers is responsible for registering/updating records within the Enterprise Managers database.  However, BOTH delete statements from step 3 are applicable to be run against the Enterprise Managers database.
There is a second filtering parameter for network adapters by DNS name, called "DNS_filter".  To take advantage of the DNS name filter, use the following SQL statements and comstore configurations:
Step 1: Identify non-unique DNS names being registered with network adapters:
select dns_name, count(*)  
from ca_discovered_hardware_network
group by dns_name
having count(*) > 10
order by count(*) desc
Sample result:
Step 2: Create the filter for the engine in the Client Automation comstore.
 ccnfcmda -cmd setparametervalue -ps /itrm/manager/engine -pn DNS_filter -v "auto-vm;Base-server"
 Validate it: ccnfcmda -cmd getparametervalue -ps /itrm/manager/engine -pn DNS_filter
Step 3: Remove the existing duplicates from the database.
delete from ca_discovered_hardware_network where dns_name in ('auto-vm','Base-server')
delete from ca_logical_asset_property where dns_name in ('auto-vm', 'Base-server')
Step 4:  Recycle CAF.