When building your identification job, deselect the "Use all classes and instances" check box (bottom left corner). This makes the Qualification Set option available. You can now click the 'eliptical' button to the right of the Qualification Set field.
Define your qualification set name, specify your name space then click New Rule - define what class and name space you will use for the rule.
Click Build Qualification something like: $ReconciliationIdentity$ != "0"
In the Identification Job, uncheck the "Generate ID's" check box at the bottom right of the window. Selecting this triggers auto-assignment.
With the above qualification set, if no identity is assigned, The Identification job should ignore the new CI.
Now you just have to have another Identification Job which DOES auto assign an ID which you run manually after you've done what you need to do.
I think that should do it.
Thanks for your reply. I have created a new qualification and configured in my Recon Job. I have also tested this with single CIs and looks like working however I still need to test it for weak relationships. I am using Standard Recon rules. I want to know what will be the case of a CI exists in BMC Asset but not in Import dataset. Later is again imported in Import dataset. will that CI also identified? is not then i am happy.
If the qualificatiion works as I believe it should, the new CI in the import dataset would 'fail' identification. Upon failing, it should end up in the Manual Identification console of Recon where you can manually match it with its BMC.ASSET opposite after you have validated the new ci in import. You may need some precedence rules to protect manual edits in asset and such.
From my Android phone on T-Mobile. The first nationwide 4G network.
Yes, just now I have tested one scenario where a computer system CI was available in BMC Asset with stats = Delete but CI was not available in Import dataset (due to decommissioned). I manually created the same CI in Import dataset then simply Ran the Recon job which has a Qualification $ReconciliationIdentity$ != "0". CI didn’t identified and merged to Asset. That’s what I wanted to achieve. But Still I want to know how this will work for weakly related CIs (HostedSystemCoponent between CompSys - OS, CompSys – Product).
To handle new CIs I have an another reconciliation job. This job need to trigger manually by Asset Team. It is identifying new CIs (RID=0)and merging them to BMC Asset. One Qualification is used here which only looks for CIs where status = ‘Deployed’ and RID=’0’.
-Any job with Standard Rules will have ID groups for all classes which will include the ones you need - Comp-Prod and Comp-OS.
-If the intent is to not have any other classes updated, unchecking 'Standard rules for participating datasets' on a custom job can help you add rulesets for specific classes
- There is also a way in the old cmdb:console to create an ID group with a new rule.
- If it is ok for the rule to be a part of all Standard Jobs, you can also add the rule from the Standard Rules Editor
Sometimes changes to recon configs like this can take some time to kick in. have you tested after a couple of hours?
As a rule, a CI should only get a recon id assigned (assuming generate ids is unchecked) if the id activity made a match against the target dataset. Can you see a ci in the target dataset with the same recon id as you see getting assigned to the source dataset?
Yes, I've wait 24 hours, removed and created a fresh new Identify job and even restarted the AR Server.
The CI in the source dataset does not match any other CI on the target dataset. It's a Computer System in the source dataset with no similar Name, HostName nor DomainName in the target dataset but, despite unchecked 'Generate IDs', it have being assigned a nonzero ReconciliationIdentity.
OK, thats weird and NOT expected behaviour as you have explained.
I think you will need to enable detailed RE logging and find the point in the log where it assigns the RE ID. Around this part of the log you will see what comparison it did for identification (i.e. which rules), what outcome the match checks reached, and whether it assigned the RE ID automatically, even if you are sure it was not configured to do so. The logs will make it very clear what happened and you can work from there.
It was just to be sure that it is not the expected behavior.
I've already set reconciliation log to debug and found the log piece with :
Setting reconciliation identity for instance id <ADF850G68F01F84TVQUAUK8HBQ6PLT>, for class <BMC.CORE:BMC_ComputerSystem> in auto-identity dataset <NXT.IMPORT>
Which is a false statement since the Generate ID is unchecked on this dataset and identify job.