- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2017 12:37 PM
Hello everyone,
While testing the SCCM Integration 2012v2 for Jakarta, I've come across an issue I can't figure out. There was a PC that wasn't int the cmdb_ci_computer table as I would have expected, but I can see it as part of the import log. I traced this back duplicate target_sys_id records in the [imp_sccm2012v2_computer_id] transition table. In short, 2 different computer names (ts001-eqlt011b & TS001-EQLT120B) in SCCM, with 2 different ResrouceID have the same target_sys_id in this table (3bef4c8c4fee8f80a4d3650f0310c7e9). When looking at the history for CI, I can see where it is updating the CI back and forth with the two different names.
So 2 questions:
1) Does anyone have any clue on how this would happen and/or how I can go about figuring out how this happened?
2) What is the process for separating these so that we get the separate cmdb_ci_computer entries as one would expect?
Thank you all for the assistance.
Sincerely,
Nathan
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2017 03:42 PM
Are you familiar with CI Identifiers and how the SCCM import uses them? I'd recommend deleting both sys_object_source AND clearing the Correlation ID value for this CI and let the next import locate the CI via serial number or name.
Once you delete the sys_object_source records, the next import will use the CI Identifiers functionality (SCCM > CI Identification > CI Identifiers) to locate the CI to update. In your case, you will have deleted the object source records, and the Correlation ID (SCCM resource ID) from the CI, so it would then fall to Serial Number, then Name, then some other stuff.
Untangling CIs in this kind of situation is rarely clean - see if this gets you back in shape.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2017 01:52 PM
You'll see it in the transform map for Computer Identity but sys_object_source is used to shortcut the identification process. Check this table to see if there are multiple source records that point to this single CI.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2017 02:08 PM
Yes. I see two different ResourceID's tied to the same target_sys_id.
Are you suggesting the record that ties to the machine that isn't getting imported will resolve the issue?
Thanks,
Nathan

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2017 03:42 PM
Are you familiar with CI Identifiers and how the SCCM import uses them? I'd recommend deleting both sys_object_source AND clearing the Correlation ID value for this CI and let the next import locate the CI via serial number or name.
Once you delete the sys_object_source records, the next import will use the CI Identifiers functionality (SCCM > CI Identification > CI Identifiers) to locate the CI to update. In your case, you will have deleted the object source records, and the Correlation ID (SCCM resource ID) from the CI, so it would then fall to Serial Number, then Name, then some other stuff.
Untangling CIs in this kind of situation is rarely clean - see if this gets you back in shape.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2017 07:25 AM
Patrick,
No, I'm not familiar with out the CI Identifiers and SCCM import uses them. Anything you can pass along would be great. To date, I'm finding the SCCM documentation like a kids version of the Hobbit. The Dwaves invite Bilbo on an adventure. The trick some trolls. Fight some spiders. Ride a cool new river barrel ride and help defeat a dragon. Those are the highlights, but the details of how each happens is vague or missing.
The steps above worked. Thank you very much for the help.
Sincerely,
Nathan