8 Replies Latest reply on Oct 1, 2015 8:42 AM by Rob Presland

    What is Best Practice to Decommission a Server CI?

    Jessiele Rodrigues
      Share This:

      We use ADDM and CMDB in our environment and we are facing reconciliation issues when a server is decommissioned and a new equipment is installed with same hostname of decommissioned server. The decommissioned server is updated with status Disposed and the new equipment with same hostname is not reconciled successfully from BMC.ADDM to BMC.ASSET.


      A proposed solution is to change the decommissioned server name to its serial number.

       

      Is that a good option? Does anyone knows how usually a server decommission update is done in other companies?

        • 1. Re: What is Best Practice to Decommission a Server CI?
          Manish Patel

          Hi,

           

          If your server is decommissioned, then that particular ADDM Server CI should be soft-deleted i.e. MarkAsDeleted=yes which will be merged into Asset dataset and purged.

          This action will allow new installer server with same name to reconcile into Asset dataset.

           

          Thanks,

          Manish

          • 2. Re: What is Best Practice to Decommission a Server CI?
            Jessiele Rodrigues

            The decommissioned CI is actually marked as Deleted by ADDM after a while, but I cant purge it to do not lost the history of this CI and other tickets in the tool (incident, problem, change request)

            • 3. Re: What is Best Practice to Decommission a Server CI?
              Devendra Yadav

              TokenID in BMC.ADDM datset is different for both Servers decommissioned  and newly installed ?

              • 4. Re: What is Best Practice to Decommission a Server CI?
                Carey Walker

                Hi

                 

                So look at all the details above, and understanding the way ADDM works

                 

                1. The new server should have a different TokenID and/or ADDMIntegrationId from the now decommissioned one. Does it?

                How did the status get set to Disposed?? Did you do that or did ADDM do that? I hadn't seen ADDM doing that in the past but it may now do that.

                 

                2. The old server should have been marked as deleted - MAD (if not already, soon ). This MAD field should get reconciled through to BMC.ASSET. I agree you do NOT want to physically remove the old one (by allowing the RE Purge job to delete it because of its MAD field) - for Asset Management, Incident etc you need the old CI to be retained. However you have said that the old server is NOT being merged into BMC.ASSET. Do you know why yet?? Is there any info in the recon. job logs to explain why the old server is failing to either ID or merge??

                 

                3. We took a decision to append the word 'Disposed' to the CI Name of such servers so that reporting and other consumers did not get confused by what they saw. e.g.   AUX2345PR - Disposed

                Something like that.

                • 5. Re: What is Best Practice to Decommission a Server CI?
                  Jessiele Rodrigues

                  There are all situations:

                  TokenID as Zero for both CIs (new one and decommissioned)

                  TokenID as Zero for one CI and defined for the other

                  TokenID different for both CIs

                  • 6. Re: What is Best Practice to Decommission a Server CI?
                    Jessiele Rodrigues

                    1. The status is updated manually in CMDB (ADDM still don't do that)

                     

                    2. The old server should have been marked as deleted - MAD (if not already, soon ) ==> Correct! It is happening for some cases in BMC.ADDM dataset but sometimes the MAD field don't get reconciled through to BMC.ASSET

                     

                    However you have said that the old server is NOT being merged into BMC.ASSET. Do you know why yet?? Is there any info in the recon. job logs to explain why the old server is failing to either ID or merge?? ==> I don't know why, but the new CI is not getting reconciled through to BMC.ASSET

                     

                    3. We took a decision to append the word 'Disposed' to the CI Name of such servers so that reporting and other consumers did not get confused by what they saw. e.g.   AUX2345PR - Disposed

                    Something like that.==> The proposal in my company is to change the CI name to its serial number, do you see any issue that I may have with this solution?

                    • 7. Re: What is Best Practice to Decommission a Server CI?
                      Carey Walker

                      Serial number for the old server is OK, but does that make it harder to find the old servers over time?? Up to you, the main thing is to remove confusion with two CI names being the same.

                       

                      We need to find out why the old CI is not finding its way to BMC.ASSET.

                       

                      Are you running incremental merges (Force update?), can you access the recon. job logs to see if they help us understand what the issue may be? On BMC_ComputerSystem form, there is a filed called FailedAutotmaticIdentification or something like that, for the OLD server CI in the ADDM dataset, what does it say? True or False?

                      • 8. Re: What is Best Practice to Decommission a Server CI?
                        Rob Presland

                        We use a mix of ADDM and manual activity to keep our CMDB up to date. We always have a task assigned to a CMDB team on decom, and one of the activities in updated CMDB is to remove the host name from the CI if the server is being replaced with newer hardware or is being virtualized, to avoid this exact problem (and to enforce the rule that CI names should be unique). Serial number is a perfectly valid CI name for disposed hardware in our view. Also, we update the status to Disposed not Delete or MAD as we need to keep the asset data for audit purposes. To date we have not had any problems with needing to find that disposed CI based on name alone, but it probably helps that it's associated with the task/CRQ that decom'd it (yeah ITIL!).