SCCM Integration Data Source LastHWScan

[stevencerbie]

We are using Microsoft SCCM 2012 integration and appear to be seeing some oddities in LastHWScan dates that is used to drive our SCCM extracts.

Our data source SCCM 2012 Computer Identity is using Last Run Datetime and Last run database field LastHWScan. The LastHWScan that drives our extracts is based of the maximum LastHWScan of the previous run.

i.e in the above example we ran our extracts at 02/24/2019 10:00 pm but we are seeing LastHWScan values of imported rows up to 12 hours in the future, i.e. 02/25/2019 10:27:42 am. According to our team that supports our SCCM product the LastHWScan in SCCM is actually in the local time of the system. The issue is that the LastHWScan for the subsequent run is being set to the max LastHWScan of the previous run and I believe we are dropping some due to time zone differences.

Has anyone else seen this behavior and if so how did you get around this.

[Paul Miller2]

Hi Stephen,

I am currently experiencing the same issue with our SCCM integration. Did you ever find a solution to this?

Thanks in advance!

Paul

[stevencerbie]

Sorry, never got a resolution to this.

[Robert McDonne1]

I am running into the same issue.  I suspect that the best way to resolved this is one of the following:

• A business rule correct future time stamping of the Last run datetime
• Turn off Use last run datetime
• Change the Last run database field

Just to be clear, this is not a ServiceNow problem, this is an SCCM problem.  THis is what I suspect is happening:

• An SCCM client has a bad time clock value when it runs Hardware Inventory (assuming you are using the default value LastHWScan as the Last run database field).
• This value gets written to the SCCM database
• Your ServiceNow SCCM integration runs and consumes this information and sets the Last run datetime to the "future date"
• The ServiceNow data source doesn't collect updated values until the "future date" has passed

The other SCCM data sources are all using TimeStamp as the Last run database field value.  I am going to try and use that for the SCCM 2012 v2 Computer Identity data source and see how it works.

[Nick Fajardo]

An SCCM client has a bad time clock value when it runs Hardware Inventory (assuming you are using the default value LastHWScan as the Last run database field).

As mentioned in the original post, SCCM sets LastHWScan to the local time on the machine, not UTC or some other normalized time. 

The solution that we're moving forward is (after the initial load), we modify the actual SQL statement to include a WHERE statement, and uncheck the "Use last run datetime" field

WHERE v_GS_WORKSTATION_STATUS.LastHWScan >= DATEADD(day,-1,GETDATE()) 

DATEADD() documentation the function subtracts a single day from the date on the server and pulls everything after that.  There will probably be some overlap of records pulled, but not enough that we're concerned about it