1. Asset ID and CI ID are the same field, just (confusingly) named differently on asset and base class forms. When you define a mapping it will be assetid.
2. Don't map anything to InstanceId. This should be treated as a system attribute/field and left for Remedy to manage. As Curtis says above, use TokenID for SCCM Resource ID, which despite the issue mentioned above (ResourceID can change) is still your best bet for unique identifier in SCCM world. Serial number is probably a bigger risk than ResourceID, in terms of global uniqueness - we have seen plenty of issues across a wide range of items where serial number is not unique. It is usually good if used in conjunction with the manufacturer code, but no so much by itself.
Did you say above you were using the Seamless SCCM integration product for this? It is usually all set up to manage these issues for you, so it shouldn't be an issue??
Thanks for the explaination on this.
Yes we are using seamless connector, As per your suggestion i will use the resource ID for identification activity.
But as a case pointed by one of colleague, can you please suggest what can be done in case if.
Incase the resource ID of CI changes.. As per my knowledge it would result in duplicate CI for same Asset.
1. If you are using the Seamless Connector, it comes with mappings and recon. rules which should mean you don't have to worry about many of these things. So not sure why you are having to do your own mappings and make decisions about recon. identification rules etc. Having said that ....
Can you ask your SCCM team to provide the reasons for a ResourceId changing over time?? I recall from several years back that we were advised that SCCM/SMS had a 'self repair' mechanism (think that was it) that could potentially result in a given item getting a new Resource Id. There may be other situations as well. If you can find that out, we can probably come up with a suitable identification strategy. If that isn't possible, then running with serial number plus manufacturer might be your only option. Otherwise as you mention, you will get duplicate CIs. You will need to do some data sampling from SCCM to confirm that this combination is unique for all your current data. Also, to confirm that ALL items have a serial number and manufacturer, and, to see if you need to do any Manufacturer normalisation first as well.
We have been working on the integration between SCCM and CMDB for a couple of months now. Here are a couple of intricacies may be useful to your specifications.
1. Resource ID changes fairly frequently and can occur for the following reasons, workstation moved to another location (different IP), operating system upgrade, new SCCM client installed and other similar type of configuration change. When that happens, you will find there are two records relate to the same workstation/machine but having a different Resource ID. This duplication occurs as the workstation with the original Resource ID remains in the source and isn't set to 'inactive' until after a number of iterations. Both records will remain until SCCM marks the original ResourceID record as 'Inactive'. So mapping ResourceID to CMDB Instance ID will lead to duplication over time and can get really messy when there are thousands of CIs to manage.
The approach we have taken is combining both the name and serial number and assign it to the Instance ID for each machine. And we found that they are unique.
2. Use the Reconciliation Identifier to match records between the imported and the production dataset, then you don't really need to care about the Instance ID in the production dataset.