SCCM SGC not consistently updating to the target record

Claire Ashdown2 · ‎02-28-2023

Hello!

Continuing to work on our SCCM SGC integration, we have run into an issue with the Computer Identity data source where we run a full load (have limited the SQL statement down to one record), transform that load using the robust transformer, and see the appropriate fields being mapped. However, if I want to just double check the results (e.g. clear the assigned to field that was set) and run it again just to make double sure, following the exact same steps, no update to the target computer record occurs. Usually, we have to wait several hours, or even a full day, before a transform to the target record will go through again. Is this a quirk of the IRE? RTE?

I am making sure to do a full load of the data (even though there is just one record) instead of a test load of 20 because I know that something about doing a test load instead doesn't actually engage full IRE/RTE processing. I am not removing or changing the identifier, so it should be able to find the record just fine. Logs in the field operation scripts appear to come through the same as normal. The target record is just not updated. No errors in the logs. No import logs. Has anyone run into this, or does anyone understand the rhyme/reason behind why the same exact transform successfully maps to the target a first time, and then does not on successive tests for a period of time?

As a side note, just in case it will only allow an update through if the computer has been discovered in SCCM since the existing Most Recent Discovery date, I tried clearing the Most Recent Discovery date, and that also did not resolve the issue. Many thanks for any guidance or advice on this matter. It makes testing customizations to the field transforms and mappings very, very slow to only be able to run 2-3 tests (if that) during a single work day.

mb27 · ‎03-08-2023

Did you blank out the Last run datetime on the data sources before rerunning?

This may be helpful or maybe not.... I had the same thing even though I blanked out Last run datetime. I wanted to customise a couple of the fields being updated and I could only run the SG-SCCM once a day! I was waiting ages to get results.

The integration puts stuff in the sys_object_source table and seems to use that as a reference for subsequent runs. If you remove the entries from that table between runs, you can get SG-SCCM to update again immediately. I don't know if this messes things up in other ways so be careful. I have access to a sandbox SCCM installation with only 23 devices so it's easy for me to run repeatedly - only takes a couple of minutes.

I wrote this script:

---- script starts----

var i = 0;

var gr = new GlideRecord('sys_object_source');
gr.addQuery('name','SG-SCCM');
gr.addQuery('id','CONTAINS','03066860c7122010b56243ac95c26027');

gr.query();

while(gr.next())
{

i++;
gr.deleteRecord();
}

gs.print(i);

---- script ends----

The Guid 03066860c7122010b56243ac95c26027 is unique to your installation. You can see it in the SQL statements on the Data Sources

SELECT '03066860c7122010b56243ac95c26027' as connectionid,
v_GS_COMPUTER_SYSTEM.Name0 as name,
v_GS_COMPUTER_

I'm finding that SG-SCCM does NOT update the audit history on CIs it updates. Are you seeing this as well?

View solution in original post

Keerthi34 · ‎09-14-2023

Did you get any help?

Claire Ashdown2 · ‎09-19-2023

They would probably just come back the next time the SGC ran, since the column built out in IH ETL and mapped as the source native key uses connectionID. If you clear out the sys_object_source records related to that connectionID, that would essentially remove the "caching" layer of identification and force things to come through the IRE fresh. Solved: Help understanding how sys_object_source is used i... - ServiceNow Community helped me understand this.