*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.



If you’re an administrator responsible for managing user data, you have undoubtedly been faced with a situation where a user reports that some of their files have gone missing. While files deleted from servers are usually easy to restore due to the differential and incremental file backup solutions so common in today’s enterprises, finding the deletion root cause is often much trickier.

The Problem
As is so often the case when faced with mysterious file deletions, the affected user may not be able to recall exactly when the files went missing, or what might have happened to trigger the deletions. Built-in file server auditing is generally not sufficiently granular to track deletions of individual files, and even auditing solutions that can show the time the deletion occurred (and perhaps even connecting client address) usually can’t help to establish what occurred on the user’s client machine to invoke it.

DataNow to the Rescue
To establish the file deletion cause, you need to examine the historical data on the affected client machine. However, because you need to reproduce the issue to capture its occurrence, verbose filesystem logging solutions like Microsoft’s ProcMon won’t help.

Luckily the AppSense DataNow Windows Client has a feature that can not only help administrators to find the source of missing files, but also prevent them from going missing in the first place.

Windows Client Delete Auditing
So—a user has reported that their most important work-related file ‘fantasy-football.xlsx’ has gone missing from within one of the DataNow map points on their Windows client. To understand where it went, all you need to do is open the Windows application event log on their machine and look for events from source “DataNow”. The following screenshot shows the DataNow delete auditing event for the missing file.

Windows Client Delete Auditing

As you can see, several useful pieces of information are written to these events, namely:

  • File – The full path and filename of the deleted file
  • Process – The name of the process which deleted the file
  • User – The SID of the user account context under which the process was running
  • Time – An accurate UTC timestamp of the time that the deletion occurred

Since the DataNow client is concerned with auditing any events which cause a file deletion to be sent to the DataNow server, you’ll need to check on additional scenarios, for example, if a file has been moved from within a DataNow managed location to an unmanaged location on disk. A delete auditing entry for such an event is shown below. Note how the event explains that the file was moved to its new destination in the recycle bin:

Windows Client Delete Auditing

There is a third scenario for which Delete Auditing offers a helping hand; if in the case of a shared DataNow map point another user deletes a file, or the file is deleted directly from the file-server backend.

The following audit event shows that a file has been removed from the local DataNow cache because it was removed from the server directly. In this case, note that DataNow cannot identify the user that deleted the fil or process by which the file was deleted. The event time represents the time at which the file was removed locally, not the time at which it was removed from the server:

Windows Client Delete Auditing – IMG3

In this case, you’d need to review the server logs to see if another DataNow client performed the deletion, then inspect that client’s event log to establish the circumstances surrounding the deletion.

I hope that this article has demonstrated how useful Delete Auditing could be in troubleshooting missing user files. For further information on Delete Auditing and other great DataNow features, please head over to support.appsense.com and review some of the technical documents and videos available in the DataNow section.