Assigned to David for prioritization.

Assigning to Matt as I'm not sure what the expected behavior is here.

At present, as explained by support, the expected behavior is when a device is reset/powerwashed, the recent users information contained in the device page is also reset.

This gives users a means of covering their tracks and hiding the most recent users of a device. Admins don't have a reliable method of seeing all recent users of a device.  Within School environments, it is not uncommon for shared devices to come back damaged.  With a proper log, we can check and see who the last users to login to the device were, giving us a list of possible suspects.

What we're finding now is that users can (and do) hard reset and erase our list of suspects.

I have performed this reset on multiple chromebooks within our environment and each time the reset is performed all information ie: recent users, active times, platform, firmware.. are all erased from the information in the console. Each time they reset it which is nearly daily, we lose crucial information in trying to locate a users device that may have been grabbed accidentally and this trickles down to login information being fed to our web filtering system also. 
The expectation is to prevent students from using the esc, refresh and power keystrokes to reset the device, additionally any commands available in the crosh shell that may impact this. I've also noticed that "do not allow users in this OU to enroll devices" is useless in this case when a student resets a device, that policy/permission is gone when the reset occurs allowing them to just to keep resetting/enrolling over and over erasing their activity.

Thanks for the report. After attempting to repro this, we did find that in new builds the fields were being cleared upon re-enrollment which is not the intention (though as a note, the clearing of fields did not happen after just a reset in our tests - only after re-enrollment). Updating title.

Given this is a server side issue (and likely a regression), we are filing an internal bug request to resolve this and will look to update here when we have found and implemented a solution.

@C4, your note about the enrollment permissions is actually working as intended. The policy is intended to prevent unwanted consumption of licenses and therefore prevents the manual enrollment process if the user isn't eligible. However, Forced Re-Enrollment flow ignores this policy as the device was already considered eligible to enroll given it is consuming a license.

I have found that on re-enrollment information regarding Active Times and Recent Users isn't being added at all, leaving the fields blank, in fact all the fields within System Activity are empty.

This information has been collected in the past, it just seems to be now that after a reset and re-enrollment the data isn't being collected.

We obviously need this for security and to track devices which might go missing or get damaged.

Chrome version: 51.0.2704.79  Channel: stable

I would just like to report that this issues now seems to be resolved for us, with Chromebooks now showing data within the System Activity section.

Much appreciated for this.

I would like to report that this issue is not solved yet! 

I just tried to re-enroll my chromebook, and all the logged data about recent users and active time is now empty!

We are still working on a fix for this and given its a server side issue we are tracking internally (ID 28914911). I'll update here when a fix is confirmed to be live. 

Yeah, apologies.
It did briefly start working around mid-June, with activity being reported but has now stopped again.

We really need this.

We are a large University in the UK who plan to have a smallish, but hopefully expanding, Chromebook loan service for the next academic year and testing was extremely positive but I would be loath to introduce the service if we can not track usage, especially to recover any if they should go missing.

The fix is now live in production and recent activity should no longer be cleared when a device is wiped. Please feel free to let us know if you see otherwise.