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

        Sorry Stefan, I can't fully agree with you in that bad data just to have it is not the right choice.  I understand what you are saying.

         

        Let's consider if good process was followed all along.  The virtual system "ABC.domain" came into the system.  It later moved from one host to another and it got a new machine Id and sync with the discovery dataset. It would not reconcile until the old one has aged out in Discovery and becomes logically deleted in the discovery dataset.  It would merge into BMC.Asset and clear out bad relationships.  It does NOT delete relationships to incidents as you indicated.  The Incident would still show the relationship in HPD:Association, just like associations to archived changes also remain even when you remove the original change request.  To follow along, the logically deleted record in BMC.ADDM would / should be purged.  Now the new ABC.domain CI now related to a different physical ESX host would properly identify to the existing BMC.ASSET CI (Same Recon ID) and would merge and update Marked as Delete to No.  Life is good.

         

        So something happened in this environment and these events did not occur and now you are left with duplicates in your environment.  One or both of these is already logically deleted.  They are preventing your active host from reconciling. It's not going to just resolve itself and something has to be done.  Maintaining an active snapshot of everything that used to be there is not the real purpose of the system.  You could invoke a process to "un-delete" old hosts and possibly rename all old hosts as they get decommissioned and update the status to End of Life or Disposed, etc.  As long as it doesn't in turn cause more problems with new discoveries like in this case.

         

        Again.  How you handle deletes is just as important as how you handle new CIs.  Same holds true for installed software, IP addresses, Databases, relationships between CIs, etc.  Things that used to be there need to be allowed to be removed.

         

        If you must keep a record of everything that has ever been in the environment, then make a new dataset and run a copy job to copy over anything with Mark as Delete = Yes prior to running your Purge.  But, bottom line - there is a duplicate here and it is preventing your good data from coming through.  It has to be fixed. 

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

          Todd, we agree to disagree. That's okay.

           

          If you just look at the CMDB and ignore all the other BMC Suite modules like Incident, Change and especially Asset management, you're right.

           

          If asset management is important to your business and you have auditing requirements, so you need to know what hardware is in use AND whiich has been disposed, you are wrong. A purge in the ASSET dataset would destroy this data, irretrievably!

           

          Let Gajanand see what is important for his company. It is too early for a limited view of the CMDB.

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

            Gajanand Patil,

            Please don't let the discussion deter you from asking further. Even though it may not look like it, it's all about you and your problem. Todd and i want to help you!

             

            We just look at your problem differently. It would help me to know if you are using the CMDB data in the suite to avoid accidentally deleting any data that is still needed because of my tip. Do you even use ITSM modules? If not, the cleanup is much easier, because the existing reconIDs are not so important anymore.

             

            Just contact me if you need further assistance. We can do it.

            2 of 2 people found this helpful
            • 33. Re: Recon issue with specific computer system ci
              Nick Caulfield

              Gajanand

               

              In the case where you have two ADDM records, both of which have MAD = No, then check in ADDM whether there really are two entries. If there are then it's very likely that one will age out and a little time will solve this (and one of the records will get set to MAD = Yes)

               

              If there are two records in the ADDM dataset, but only one host (or whatever it is) in ADDM which corresponds to that, then you may need to do a resync so that the shadow copy in ADDM and the records in the BMC.ADDM dataset are brought back into line

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

                Hi Stefan Hall , Ganesh Gore , Todd Lazar , Nick Caulfield ,

                 

                Thank you so much for your response. Sorry for delay in response. 

                 

                Very good discussion. We almost discussed all the scenarios. I also initiated it the same with BMC and suggested to remove the recon rule-4. Basically with the combination of HostName + isVirtual + DomainName, recon engine is getting multiple matches and thats why reconciliation is not happening.

                Once we remove the recon rule-4 and run the reconciliation, it covers such not reconciled cases.

                 

                Once again thank you so much for ALL for your assistance. If you have any thought for removing the recon rule-4, let me know so I can consider that approach as well .

                 

                 

                Regards,

                Gajanand Patil

                 

                22. Re: Recon issue with specific computer system ci
                Stefan HallLevel 12

                • 35. Re: Recon issue with specific computer system ci
                  Ganesh Gore

                  have you completely deleted the rule or just updated it with additional qualification? (Sorry I dont understand how removing rule can fix the issue)..

                  have you removed rule for (Domain+Hostname+Is Virtual)? What will happen if first three rules are failed and 'Domain+Hostname+Is Virtual' is the only unique combination? [I know you have better understanding of the issue; just trying to understand the fix/future implications of it ]

                  1 of 1 people found this helpful
                  • 36. Re: Recon issue with specific computer system ci
                    Nick Caulfield

                    I guess a couple of thoughts about removing the 4th query from one of the standard rules

                     

                    I'm not sure what happens to altered standard rules during a product upgrade but I expect it'll remain as you have it

                     

                    If you raise future cases with BMC support and mention that your job uses the standard rules, then you may also need to include this footnote in case they need to test some issue and are unaware that your installation is just-a-little-bit different from standard

                     

                    The change will affect every job which uses the standard rules and not just this job.

                     

                    If you fully review the standard rules, you may be surprised to find that this is not the only place where a rule will match multiple records. Many components are identified along a weak relationship from a computersystem without ever their own class rule being invoked but when it comes to needing the rule in question it doesn't always uniquely identify the CI anyway. I'm currently considering a set of custom rules for SCCM data but we're only populating 11 classes with that. I may end up looking at how many classes would need a rule for ADDM data as well but it keeps on being one of those "look at it tomorrow" things.

                     

                    Otherwise, once the rules are on your system, then you need to do the right thing to identify your CIs and if that includes editing a standard rule - well, why else would there be a standard rule editor 

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

                      Hi Ganesh,

                       

                      I have completely removed the Domain+HostName+isVirtual identification rule. Input source Discovery for records have the different combination to define the uniqueness of the records like by adding the IntigrationID in the condition.

                      So after removing the above mentioned identification rule, it reconciled all those records which stuck because of multiple matched with the combination of Domain+HostName+isVirtual.

                       

                      Till date I observed the Golden dataset and all requirement of customer is fulfilled. So this is very much helpful for Client to remove this rule.

                       

                      Thank you so much for all of support on this.

                       

                      Regards,

                      Gajanand Patil

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

                        Hi Nick,

                         

                        Completely agree with your statement. But in my case the definition on unique records is not completely based on the combination of Domain+HostName+isVirtual. Hence even after removing this rule, all data is in good shape.

                         

                        I have monitor data closely and also checked with the users who uses asset data and all are in good shape.

                         

                         

                        Thank you so much for your assistance on it.

                         

                         

                        Regards,

                        Gajanand Patil

                        1 2 3 Previous Next