SCCM Import fails due to future last run datetime

[MGanon]

Our SCCM import fails because the last run datetime updates to a date far into the future. The last run database field is LastHWScan. We can use the import table to identify the server(s) with the future date but we don't want to constantly monitor the integration to identify that the date is set incorrectly. I don't want to write a Business Rule to reset the date if there is a better way. Is there a more automated method? 

[Andrew Westerv4 · Accepted solution]

A Business Rule to "reset" the Last Run Datetime is pretty much the only way I've found a way around this. Below is my example Business Rule on the Data Source table, you may need to update the category to which ever SCCM version you are using. The script will look to see if the date is after today, and if so it will reset it to today at midnight.

Condition: current.last_run_datetime.changes() && current.category=='SCCM 2012 v2 Integration'

Script:

var t = current.last_run_datetime;
var tFormat= t.replace(/'/g,"");
var gdtSCCM = new GlideDateTime(tFormat).getDate();
var gdtNow = new GlideDateTime().getDate();

if (gdtNow.compareTo(gdtSCCM) < 0 || t == ""){
t = "'"+ gdtNow.getDate().toString() +" 00:00:00.0'";
}

current.last_run_datetime = t;

[MGanon]

I suspected as much but was hoping that the integration might be a little smarter than it was 3 years ago. (https://community.servicenow.com/community?id=community_question&sys_id=15cd4b6ddb9cdbc01dcaf3231f9619bf)

[Nicolas Breugn1]

Actually, if the Last Run Datetime is set in the future, it is because SCCM itself is giving you a date in the future.  I had the case with some computers having a bad battery on the motherboard and having the wrong system date and in consequence, sending bad date of HW Scan to SCCM.

[MGanon]

This is true but the only resolution is to accept that ServiceNow will not import records updated before the erroneous SCCM value or code around it in ServiceNow.