1 2 3 Previous Next 38 Replies Latest reply on Apr 17, 2020 12:46 AM by Gajanand Patil Go to original post
      • 15. Re: Recon issue with specific computer system ci
        Stefan Hall

        Gajanand,

        I assume all three CIs are the same device, right?

         

        Then it's "normal" behavior. ADDM does not always recognize that they are the same CI and creates another entry in its dataset without immediately setting the "old" one to MAD=yes. ADDM has the aging process for this.

         

        It is a manual task of the ADDM responsible persons to find these duplicates and destroy the old ones.

         

        Then the identified CI gets MAD=yes, the job merged it into the asset and after a purge in the ADDM dataset the new entry can be identified cleanly with your existing rules. The following merge sets MAD in ASSET back to no. There is no 100% fully automated solution for this scenario.

         

        It is important that the recon id for this CI in the asset dataset does not change. So that your links in Incident, change etc. continue to work.

        2 of 2 people found this helpful
        • 16. Re: Recon issue with specific computer system ci
          Gajanand Patil

          Hi Stefan,

           

          Very good approach. In the purge job I will try to add _Old in the hostname.

           

          Regards,

          Gajanand

          • 17. Re: Recon issue with specific computer system ci
            Stefan Hall

            I don't understand. Purge only deletes entries with MAD=yes, you cannot add a string there.

            1 of 1 people found this helpful
            • 18. Re: Recon issue with specific computer system ci
              Todd Lazar

              The CI is not identifying because of a duplicates issue.  The original one that was identified is marked as deleted.  Recon isn't giving the new one the same Recon ID.  To remedy this, purge the logically deleted entries and the new one will then identify.

              1 of 1 people found this helpful
              • 19. Re: Recon issue with specific computer system ci
                Stefan Hall

                Todd, thanks for explaining. I know the Recon well.

                 

                Gajanand's problem is that the old entry in the ADDM dataset did not get MAD=yes because ADDM recognized a "new" device! This is a big difference.

                 

                I just want to make sure that Gajanand has understood the workaround and the effect correctly, so that nothing else is broken. Hence my request.

                1 of 1 people found this helpful
                • 20. Re: Recon issue with specific computer system ci
                  Todd Lazar

                  ok, looking back at one of the initial postings and it shows where there are 2 in BMC.ASSET with MAD=Yes and the one in ADDM dataset has MAD = No.  So it's still a similar duplicate situation in that identification doesn't know which one to associate with.  Handling the logical deletes is really important.  So in BMC.ASSET, get rid of the one that shouldn't be there or change its host name (as suggested).  Or Purge BMC.ASSET.

                   

                  Anyway, looks like we are all narrowing in on getting it fixed!

                  1 of 1 people found this helpful
                  • 21. Re: Recon issue with specific computer system ci
                    Ganesh Gore

                    Hello Gajanand,

                     

                    I haven't gone through all the posts/details but from the error message, it seems there are multiple data-sources feeding data to CMDB and it looks like identification and merge rules in your system are not properly designed and hence there are multiple records in golden dataset.

                     

                    e.g. Data-source 1 has created Computer System "ABC" in staging dataset and merge to ASSET.

                           Data-source 2 has created Computer System "ABC" in its respective dataset and instead of merging it with existing ASSET CI, it has created "another" instance of "ABC" in golden dataset.

                    Now Data-source 3 (say ADDM) discovers same computer and try to push it to ASSET but as there are already two computer systems with same details, ReCon engine fails to set the REID.

                     

                    I would check 'AttributeDataSourceList' attribute of these duplicate ASSET CIs and try to find out the source and then compares below listed attributes with the ADDM computer system. One of below mentioned rule should 'identify' the computer (based on the priority) so compare data of these multiple instances.

                     

                    based on the analysis, you can identify faulty CI and hence the source dataset of that CI. ultimately you need to fix the data source feed and update corresponding identification rules to avoid such issues in long run.

                     

                    1 of 1 people found this helpful
                    • 22. Re: Recon issue with specific computer system ci
                      Stefan Hall

                      Gajanand, Ganesh might be right if your CIs in the asset actually come from multiple sources. That's not what I understood.

                       

                      His advice does not apply to your second scenario (2 in ADDM, 1 in ASSET). I had explained that a little bit above.

                       

                      Please be careful with your cleanup. The solutions are not identical for both scenarios. You get mixed up quickly.

                       

                      Good luck!

                      1 of 1 people found this helpful
                      • 23. Re: Recon issue with specific computer system ci
                        Ganesh Gore

                        Just to be clear, I was talking about duplicates in ASSETS and not in ADDM. There can be duplicates in ASSET if you have multiple datasources and your identification and merge rules are not enough to maintain data consistently across the datasets and hence the situation.

                         

                        For any particular ADDM computer system (which is failed during recon), get the information in below table format and compare.

                         

                          

                        CI NameDatasetAttributedatasourcelistTokenidHostNameDomainSerialNumberIsVirtualPartitionidMAD
                        ABCADDM
                        ABCASSET
                        ABCASSET
                        2 of 2 people found this helpful
                        • 24. Re: Recon issue with specific computer system ci
                          Gajanand Patil

                          Hi Todd,

                           

                          So it means we have to purge the Asset cis as well ?

                           

                           

                          Regards,

                          Gajanan

                          • 25. Re: Recon issue with specific computer system ci
                            Gajanand Patil

                            Hi Ganesh,

                             

                            I understand. In our system, data source is Discovery only.

                            There are 2 recon job configured, one with Identification, merge activities which runs on daily basis and another recon job purge activity which run in a month.

                             

                            Below are the scenarios i observed:

                            Case-1: 2 Asset and 1 ADDM. For both asset records are with MAD=Yes ( its ADDM entries get purged. Asset entries are in Golden dataset because for the reporting purpose). Now New ci get discovered and this needs to reconcile. In the rule screenshot you mentioned, the fourth rule is failing.

                             

                            Case-2: 2 ADDM records 1 Asset record. One ADDM and associated ASSET record are active. New ADDM record get discovered and the change between the old and new one is of serial number / tokenID. And in this case also the rule-4 is failing.

                             

                            Case-3: 2 ADDM records 1 Asset record. One ADDM and associated ASSET record are with MAD=Yes (Purge job will delete the ADDM softdeleted record when next purge job run). New ADDM record get discovered and the change between the old and new one is of serial number / tokenID. And in this case also the rule-4 is failing.

                             

                            So one approach suggested by Stefan, if i can do changes in the hostname of softdeleted Asset cis with CINAME_Old something like that, then this may work. But I am thinking is it a good approach ? As BMC has given these 5 rules, one ADDM&Asset get softdeleted, then what is the way to reconciled the other discovered server which have same Hostname , Domain and isVirtual ?

                             

                            I am sure, you already seen these kind issues, so what is the good approach in such kind of cases ?

                             

                            Regards,

                            Gajanan

                            • 26. Re: Recon issue with specific computer system ci
                              Gajanand Patil

                              Hi Stefan,

                               

                              So is it possible to add _old in hostname cis which have Mad=Yes using AI job ?

                               

                               

                              Regards,

                              Gajanan

                              • 27. Re: Recon issue with specific computer system ci
                                Stefan Hall

                                Important basic information

                                I understand. In our system, data source is Discovery only. There are 2 recon job configured:
                                • one with Identification, merge activities which runs on daily basis and
                                • another recon job purge activity which run in a month.

                                 

                                Corrections are not easy, depending on the scenario and of course the cause of the errors must be found. Let's start with the solution:

                                Your main problem seems to be the changing serial numbers, with the same hostname. Only you can evaluate the content.

                                 

                                Why does the serial number change if the hostname is the same? Is it a hardware replacement?

                                Do you want to treat these CIs as one CI from ASSET point of view or not? The final solution depends on your answer.

                                • yes - the serial number in the rules is wrong, but is your hostname unique enough
                                • no - the serial number must be included in every rule

                                 

                                Now to your cases, good preparation by the way

                                 

                                Case-1: 2 Asset and 1 ADDM.

                                For both asset records are with MAD=Yes ( its ADDM entries get purged. Asset entries are in Golden dataset because for the reporting purpose). Now New ci get discovered and this needs to reconcile. In the rule screenshot you mentioned, the fourth rule is failing.

                                This is an error case that should not exist in this way. But there are some situations that can cause it. But to explain this here would go beyond the scope.

                                 

                                The cleanup depends on the use of the ASSET entries. If both CIs have not been used in any way, you could delete the entries in ASSET. You can test this on DB level with the SQLs I have documented here CMDB Recon Tips (Part 2) - Find and Fix faulty CI associations in ITSM tickets

                                 

                                If only one CI was used, you could add "_old" to the host name of the other CI in ASSET. Then your ReconJob would identify and merge the other CI.
                                Attention: Here your answer is important! Do you want to keep all CIs or is every new CI with the same hostname also the same CI.

                                 

                                Case-2: 2 ADDM records 1 Asset record.

                                One ADDM and associated ASSET record are  active. New ADDM record get discovered and the change between the old and new one is of serial number / tokenID. And in this case also the rule-4 is failing.

                                 

                                Case-3: 2 ADDM records 1 Asset record.

                                One ADDM and associated ASSET record are  with MAD=Yes (Purge job will delete the ADDM softdeleted record when next purge job run). New ADDM record get discovered and the change between the old and new one is of serial number / tokenID. And in this case also the rule-4 is failing.

                                Case 2 and three are practically identical. They differ only by a time component. The aging process in ADDM means that hosts that are no longer found will be deleted after some time (even 7 days and 10 attempts or something like that). This leads to MAD=yes in the CMDB.

                                 

                                As I have already written above, a completely normal scenario. ADDM recognizes a new CI due to the new serial number and creates a new CI in the ADDM dataset. Here it depends on your answer above!

                                What do you want to achieve in ASSET? Should the existing CI be updated or should another entry be created in ASSET. Both is possible.

                                 

                                Conclusion: Let's first discuss the intended solution before we adapt the rules. Together we can do it!

                                1 of 1 people found this helpful
                                • 28. Re: Recon issue with specific computer system ci
                                  Todd Lazar

                                  In your case, yes - you should purge BMC.ASSET.  In short, you have duplicates.  And you have items that are marked for deletion that are no longer valid.  While you "COULD" change the name of a CI so that you no longer have duplicates, it still misrepresents your environment. 

                                   

                                  As stated earlier, when you are identifying and the standard rules that will automatically give a new Recon Id for a new CI.  The only thing that will prevent this from happening is when there are duplicates.  It works both ways.  If it finds 2 or more matching CIs in your BMC.ASSET dataset, it doesn't know which one that you want to use.  So fix that data.  Get rid of the bad data.  The other is that the discovered CI does match something in BMC.ASSET, but it cannot issue the same Recon ID to more than one active CI in your discovery dataset.  That happens mostly when moving virtual hosts and discovery treats it as new with a new machine ID and sometimes a new serial number or token Id depending on how it was moved.  The old record must be allowed to process out and the new one to process in.

                                   

                                  In either case, how you handle these logical deletes is important.  Ignoring them just leads to more issues such as this.

                                  1 of 1 people found this helpful
                                  • 29. Re: Recon issue with specific computer system ci
                                    Stefan Hall

                                    Todd, I can't agree with you entirely. From a CMDB standpoint, you may be right, from an asset standpoint, not necessarily.

                                     

                                    If you delete in the asset dataset, you lose the reconIDs and thus the connection to your tickets. This damage would be irreparable!

                                     

                                    So first consider what is important and right from an asset point of view and then act. Never purge first and then ...

                                    1 of 1 people found this helpful