In the file storage business, it's not difficult for the sheer quantity of files and folders you manage to get out of hand very quickly. As well as raw storage can scale for a business, maintenance of the storage becomes more and more cumbersome. Between all of the group and permission settings, files growing disorganized, and mass changes to the structure, anything that we can do to make our lives easier when it comes to storage helps keep us afloat.

This is particularly true with file deletions. Constant monitoring of file and folder deletions is necessary to prevent business disruptions and data loss through a quick restoration of data.

In this article, we aim to answer a pretty simple question: Who deleted those files?

Well, I say it's a simple question, but once we dive in, I'm sure you'll agree with me that it's not as simple as it sounds. We're going to explore two routes of answering this question. The first route we're going down will use PowerShell, and the second will use the Netwrix Auditor. There's a bit of a difference in how these two options work so let's dive right in.


There are a few prerequisites to working with auditing using PowerShell. To get started, we'll need to change a few settings on the file server that we want to monitor. This is a three-step process that will begin by setting the local security auditing policy on the file server, configuring the auditing, and then analyzing the event logs to read the data.

Step 1

To set the local security audit policy with PowerShell, we'll use the secedit command on our file server (which isn't strictly PowerShell, but we can still utilize it from our terminal). Once we export our policy to a ".cfg" file, we will then replace one line, enabling AuditObjectAccess for both successes and failures, and then we'll use the secedit command again to apply the newly configured security policy.

PS>secedit /export /cfg C:\Temp\securitypolicy.cfg
The task has completed successfully.See log

PS> (Get-Content C:\Temp\securitypolicy.cfg).replace("AuditObjectAccess = 0", "AuditObjectAccess = 3") | Out-File C:\Temp\securitypolicy.cfg

PS> secedit /configure /db C:\Windows\Security\local.sdb /cfg C:\Temp\securitypolicy.cfg /areas SECURITYPOLICY

The task has completed successfully.

Step 2

Now that the Local Security Audit Policy has been applied on our File Server, we need to configure auditing on the specific folders that we want. When we do this configuration, it will store the event in the Windows Event Logs. Since we're doing this with PowerShell, we will again be using the Administrative PowerShell terminal on the file server to configure auditing.

## This is the path to the file share you want to configure
$path = "C:\Share" 

## This stores your current settings in case you want to revert
Get-ACL $path -Audit | Format-List Path, AuditToString | Out-File -FilePath 'audit.txt'

## This section creates and sets the audit rule on the Folder
$acl = Get-ACL $path
$AuditRule = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone", "CreateFiles", "none", "none", "Success")
$acl | Set-ACL $path

## This stores your new settings so you can compare to the previous file

Once this is set, it's time to check out the Windows events that are generated!

Step 3

The last thing that we need to do to monitor who deleted what is to start checking out the Windows event logs on our file server. The team at Microsoft have given us a few handy Windows event IDs to monitor these deletion events, so we can create a simple hashtable to be able to analyze the results.

We'll start by creating a start date for our query. Since I only want to analyze the last day's worth of results, I can use the Get-Date cmdlet with the AddDays() method to set a start date of yesterday. We'll then create our filter to look in the Security log while filtering for the ID's related to file access and deletion, finally adding our start date in our filter. Once that's done, we'll run the Get-WinEvent cmdlet to return our Windows events.

PS>$date = (Get-Date).AddDays(-1)

PS>$filter =

PS> Get-WinEvent -FilterHashTable $filter

As you can see, there are a significant number of events returned. Based on what you're looking for (specific files or folders deleted, or specific users doing the deleting you can filter this down even further using the Where-Object and Select-Object cmdlets and the pipeline.

Netwrix Auditor

Now that we know how to do this natively within PowerShell let's check out what we can do with Netwrix Auditor. The fine folks at Netwrix have given us a shortcut on how to enable this auditing without using PowerShell. To get started, visit this link and click on the Download option.

Once downloaded, double click to install, and a short wizard will walk you through any steps necessary for your first installation in your environment. The installer deploys in a client/server model, so you'll start by deploying the "server" portion to your file server, and then you can manage it there or install the "client" on your personal workstation for easy remote management.

From the Main Menu, we can select the "Quick Start" guide for a "New Windows File Servers Plan" which will perform the monitoring for us. Notice how you can do a lot more than file monitoring with this software as well.

Once selected, we'll run through another short wizard, configuring a service account on your domain with the appropriate permissions for this type of file server monitoring connecting a database to store all of the audit details, and finally choosing where to monitor. When complete, you'll be brought to a new screen which will look something like this:

Post-install screen

Now you can start watching the logs pour in! If you go to the "reporting" tab in Netwrix Auditor, you'll be able to see all the different kinds of reports you can run on the auditor.

View Reports

Things like files accessed, files and folders deleted, and permissions changes are all included as pre-defined reports for you. All you have to do is click and run!


Since we've seen them both in action, I thought it would be good for us to take a step back and look at both options. For a quick side-by-side comparison, I've made this table which shows how far the Netwrix Auditor goes beyond "figuring out who deleted what." In the table, you can see that native PowerShell can perform the primary task, but Netwrix Auditor includes several quality-of-life features which will make the job significantly easier.


Overall, though you may be able to perform some of the same functionality with native PowerShell, the number of features you get with the Netwrix Auditor merely is astounding. If you don't currently do any monitoring in your environment, I'd strongly encourage you to deploy the PowerShell method so you can start attaining these kinds of logs today. You never know when they'll come in handy. As you can probably see after a short while, the solution doesn't scale incredibly well into a large environment. That's where Netwrix Auditor comes in.

Learn more about Netwrix Auditor for Windows File Servers!