I am new to Netwrix Auditor Solution and we have received a request from GRC Team to Implement a file activity/integrity monitoring control on SQL Server Instances to monitor Critical Config Files & Folders of SQL Server Instances. so, which solution & method I should use it to achive this. With Many Thanks!
Great question! To achieve this, you’ll need to use Netwrix Auditor for Windows File Servers — not the SQL Server data source.
Here’s why: SQL Server’s critical config files and folders (data files, logs, binaries, backup directories) reside on the Windows filesystem, so the Windows File Servers collector is the right tool to monitor read/write/delete/permission change activity on those paths.
This will give you visibility into who accessed or changed those files, when, and from where — which should satisfy your GRC team’s file activity/integrity monitoring requirement.
Please correct me if I’ve misunderstood your requirement — happy to clarify further!
Hello Dear, Thank you for the response. you correctly understood the question/requirement.
However, I have a Question here. Since, SQL Server Is not typical file share/server & there won’t any SMB OR file server services would be running ? though Netwrix Auditor for Windows File Servers can capture the required activities ? With Many Thanks!
SQL Server is not a typical file server and doesn’t run SMB/file sharing services in the traditional sense.
However, Netwrix Auditor for Windows File Servers can still monitor it by leveraging the Windows administrative share (C$). You simply point the monitoring scope to the admin share path of your SQL Server host, for example:
As long as the Netwrix Auditor service account has the necessary permissions to access that path, it will capture file read/write/delete/permission change activity on those directories — no SMB file server role required on the SQL Server machine.
That said, this is more of a general principle — in practice, I’d recommend being as specific as possible about which paths and file types you actually want to monitor. Pointing at a broad directory tends to generate a lot of noise. It’s better to narrow the scope down to the specific files and folders that are truly critical rather than monitoring the entire SQL Server directory tree.