LastScanDate Attribute specifies the last date and time the instance was scanned by discovery applications.It will reflect the 'scanned date' of a succesfull discovery of that device/host . Do see this different at Discovery side ? Are the last scan date different for these CIs in ADDM dataset and ASSET ?
last modified date may change based on RE activity primarily by Remedy Application Service .
Yes... LastScanDate is different in ADDM dataset and ASSET dataset, also i cant get this CI related instance id in
reconciliation log,,,so wanted to check what could be another reason.
For detailed logging <to go through instance Id > in Re logs , you may need to set the logging level to Debug from Reconciliation > Edit Server Configuration . For changes to take effect you can restart the arrecond process .
As Anand has already mentioned abt the significance of Last scan date and last modified date, I would like to focus more on possibility of why the last modified date is different that last scan date.
If your sandbox dataset is enable and its corresponding sandbox recon jobs also enable, then the CI might have updated by sandbox jobs.
Their are many cases where sandbox job got invoked though their is no direct changes in the Asset. For example an People got related to CI.
To verify if that is because of sandbox job, check the sandbox job history and check its recent start end time, match with the last modified date of CI (which you found is different from last scan date)
thanks..we are running only one Reconciliation job ...all other sandbox jobs are disabled. but found 2 Normalization job was running on the Addm dataset, this could be reason..? but i think Last_Scan_date in Addm dataset is correct. only thing is, it is not getting reflected in Asset dataset where we have only one recon job configured.
Yes, the modified data can be tricky, specially if you are running Normalization.
The CI may be "last scanned" 17/06/2013 10AM, put into the CMDB 17/06/2013 11 AM, and then last modified one day later by a normalization Job running in that dataset.
Normalization Job could be the reason only if your RE job set for Normalized Data Only then only it will pick up the records from source dataset and update the Date attribute accordingly.
Abhijit, regardless of the "Process Normalized Data Only" flag in Reconciliation Engine if the CI is modified, even by normalization, the RE Merge Status changes and the next time the RE job runs it will pick up this CI to move the changes to the Target Dataset, thus the Modified date will be updated.
we are using this option "Process Normalized data Only" in RE job and our concern is Last_Scan_Date field value is not getting passed in Asset dataset even though it is correct in ADDM dataset. so does it mean this CI is getting failed in Normalization phase itself.?
As you have mentioned above -"CI may be last scanned on 17/06/2013 10 AM and put into CMDB 17/06/2013 11AM and then last modified date may be one day later. " this is fine......but in our case CI was last scanned on 24/05/2013 and in CMDB we have last scan date as 11/04/2013 which is more than one month older date...but Modified date is
24/05/2013 in CMDB.
The ADDM RE job has the flag Process Normalized CIs only.If this behavior is attributed to the instance failing normalization that instance would not have reconciled into ASSET dataset or even got identified in the first place should it be failing at NE level .The last modified can be related to remedy application service either during NE or RE .
Are you able to track the lastscandate changes for a new/recently discovered host and confirm if the scan dates are getting updated ?
There's lots of information in the above posts but a little confusion has appeared I think.
First, the Process Normalized CIs option is set in the identification phase of an RE job. If the Normalization Status of a CI during the ID phase says it has not successfully normalized, the RE ignores that CI. It doesn't matter if the CI has been updated or not since the last ID activity, it is still ignored. As Anand mentions above, the CI is already in the ASSET dataset, so we have to assume it has been identified successfully already. Check the RE ID of the CI in the ADDM dataset if you want to be sure.
Second, to confirm these things, can you first check the NormalizationStatus of the CI in the ADDM dataset. It is hopefully 40 or 50 (meaning Normalized and Approved or Normalized but not Approved - either are OK to allow it to be identified). Second can you see that in the ASSET dataset, the LastScanDate value has come from the ADDM dataset? To do this you will need to find what field id LastScanDate is (300927600 for me), then look in the AttributeDatasetSourceList field for the CI in the ASSET dataset. If the field id of LastScanDate is in this list and it is there from ADDM dataset, then you know at least that it was last provided by the ADDM integration.
I'm pretty sure you'll find the the NE status IS OK and that the CI IS getting its value for LastScanDate from ADDM, but at least you are sure.
Please advise on these checks and we can then look further.
thanks for your input..yes, whatever you have mentioned above is correct..RE will ignore the CI if it is not Normalizaed succesfully.(CI is already present in CMDB and Normalization status of the CI in ADDM datset is Normalized and but not Approved). and also LastScanDate field id(300927600) is presnt in AttributeDatasetSourceList which means LastScanDate is provided by ADDM only...so we can say earlier this CI passed both Normalization and Reconciliation phase successfully and that's the reason, it is present in CMDB today. But now since it is not passing Normalization phase itself so LastScanDate is not getting updated in CMDB...
Agree with everything except the last sentence. It IS normalized OK (it IS passing Normalization phase) otherwise NormalizationStatus would something other than 'Normalized but not Approved'.
There are two more things you can try if you are brave!
1. Set the reconciliation ID of the CI in the ADDM dataset (NOT the ASSET dataset!!!!) to 0 and run the Recon job again. This will force the CI to be identified AND merged again. After the recon job finished successfully, check the LastScanDate in the ASSET dataset. Does it change? Also check the 'FailedAutomtaicIdentification' field on the CI in the ADDM dataset. IS it true or false?
2. Change the LastScanDate for the CI in the ADDM dataset to something else (maybe 1 day before or after). Run the recon. job again. The recon job should not need to identify anything, but should merge 1 record. You can verify this in the RE job logs. Does the LastScanDate in ASSET dataset change?