Hello, I'm experiencing the same issue. There are devices that are possibly not functional/online (and one that I'm 100% sure as it's my office without battery ) but the last "LastDiscovered" attribute was changed several times (once per 2-3 months). These devices have the same LD value (two values to be precise - but it differs only by exact one minute). What's even more curious that "my" device is staged and "connected" to different relay server and site but maintains this LD value with other similar affected devices. IMHO it seems to be MSP/SQL related.

I have seen the same behaviour occur, but based on the information provided by Allan, I believe the cause might be found on the Relay Server. Maybe there is a process running on the Relay Server that changes the timestamp of the discovery documents, e.g. a file backup or virus scan.

Brad;
I am a bit confused here.  You mention a "Last Report date/time", but there is no such Device Attribute.  Did you mean the Device Attribute "lastdiscovered"?  If so, then it is important to understand what that Device Attribute does and how it is intended to be used.

The Device Attribute "lastdiscovered" (in the terminology of Chapter 6 of the Understanding MSP document) is a Server Originated Device Attribute.  This means that it is determined by the MSP Server and NOT sent to the MSP Server by the device.  When the device uploads a Discovery Document to the Relay Server, the Relay Server time stamps that file based on the current time of the Relay Server.  When the MSP Server uploads a Discovery Document from the Relay Server, it gets the file AND the time stamp.  The MSP Server also keeps track of the time difference between its own clock and the Relay Server's clock, to handle cases where they may be in different time zones.  When processing a Discovery Document, the MSP Server uses the time stamp of the file on the Relay Server, adjusted to MSP Server time, to set the value of the Device Attribute "lastdiscovered" for the device to which that Discovery Document applies.

As you can see, this makes the value of the Device Attribute "lastdiscovered" completely independent of the time set on the device (or the lack of a valid time on the device) and this is entirely intentional.  For the most part, MSP can and does manage devices whether or not they have a valid time set.  One notable exception to that rule is Data Collection since the data samples are time stamped with the device local time when the were collected and MSP will throw out any that don't make sense.  So, if Data Collection is to be used, the time and date on the device MUST be set reasonably.  Another minor exception is that device Job Logs will be time stamped with device local time.  So, if the time and date on the device are incorrect, Job logs will show weird times.  But that is strictly cosmetic, since MSP does not use those times for anything.

A device CANNOT be discovered by MSP unless it has sent a Discovery Document to the Relay Server.  If a device is non-functional, then it won't be sending Discovery Documents and hence the Device Attribute "lastdiscovered" will not change.  But during Staging, a Discovery Document MAY be sent to the Relay Server.  Whether this happens or not has to do with the nature of the Staging you do.  If your Staging includes a Bundle, then the device WILL be contacting a Relay Server.  And if the Staging does not end up reconfiguring the device such that it loses contact with the Relay Server before a Discovery Document is sent, then MSP will discover that device and the Device Attribute "lastdiscovered" will have a value based on when that Discovery Document was uploaded.  If the device never checks in with a Relay Server again, then the value of the Device Attribute "lastdiscovered" will remain at that time.

If you want to have a Device Attribute that reports the local time or UTC time set on a given device, you can.  You would need to write a custom Control Module to acquire the time using a suitable API and place the value into the Device Registry such that the MSP Agent will report it as a suitable Device Attribute.  This custom Control Module would need to use a Package Check-In Command to ensure that it runs each check-in so it can acquire the new time and place it in the Device Registry just before the MSP Agent sends up the Discovery Document.  One thing to note is that doing this will increase the overhead since the MSP Agent will not by default send up a Discovery Document every check-in unless something has changed.  By adding such code, you will guarantee that every Discovery Document WILL be differnet and hence cause a Discovery Document to be sent every check-in.  So be sure that doesn't increase traffic in ways you can't accept.

The reason why the Device Attribute "lastdiscovered" cannot be used in a Device Saved Filter is because it is a time value and there are no operators that can reasonably operate on it.  So, if it were allowed, you couldn't do anything useful with it.  In MSP 4.0, we HAVE added operators that can operate on time values, for use in things like automatic certificate renewal.  But the time values these operators are designed to operate on are not the same as the time value in the Device Attribute "lastdiscovered".  So, even in MSP 4.0, the Device Attribute "lastdiscovered" will not be usable in Device Saved Filters.  But if you were to develop a custom Control Module to report the time of a device, as discussed above, and if that time were reported in the proper format, then that new Device Attribute COULD be meaningfully used in a Device Saved Filter in MSP 4.0, via the new operators. While the Device Attribute "lastdiscovered" cannot be used in a Device Saved Filter, there is another Server Originated Device Attribute, called Status.Missing, that could be.  If you set of a "Min Contact (hrs):" value for a Relay Server, then MSP will calculate how many multiples of that time have ellapsed between the current MSP Server Time and the value of the Device Attribute "lastdiscovered" and place it into the the Device Attribute "Status.Missing".  So, let's say that you set "Min Contact (hrs):" to 24.  Then "Status.Missing" would show the number of FULL days since the device last sent a Discovery Document that was processed by MSP.  But keep in mind that this behavior is subject to the explanation above about how the value of the Device Attribute "lastdiscovered" is determined. Allan

Allan, Yeah, your right lastdiscovered, I was looking at my custom fields in MSP and just had a 'mis-thought'.  "If the device never checks in with a Relay Server again, then the value of the Device attribute "lastdiscovered" will remain at that time." This is truly not the case.  Some event did indeed change a bunch of attributes for lastdiscovered while these devices were not functional.  I know what your saying makes 100% sense, but could anything cause that phenomenon where a SQL update would/could cause this? Brad

Brad; No, I am not aware of any such mechanism, nor have a I ever seen the "lastdiscovered" Device Attribute change when a device stopped checking in.  In fact, the "Status.Missing" Device Attribute relies on this fact since if the "lastdiscovered" Device Attribute ever did get updated, it would impact MSP's ability to determine how long a device had bee "missing".  I am not saying you didn't see what you say you saw, but I have no idea how it could have come about and it does not match any behavior I have ever seen.  So, until/unless you can reproduce it or provide more information that we can use to try and identify the source of it, it will likely remain a mystery. Allan