If I have 2 Monitoring Plan objects for FileServers, and I want to consolidate them into 1, is there a way to move an item from one plan to another? Or do I have to delete the existing items, add them to the other plan, and wait for it to do its thing?
Marc,
While there’s no way to consolidate the existing plans, we can absolutely ensure all future data goes into a single plan without losing what you’ve already collected.
Before you proceed, keep in mind that combining both File Servers into one plan can impact performance. When plans are separate, each has its own database, allowing for faster searches and reports. A single plan means all data shares one database, which can slow things down—especially if one server is significantly larger.
Also note: when two items are part of the same File Server plan, collections won’t start again until both finish. So if one takes longer, it can delay the other.
That said, if the File Servers are relatively small and you’d like to proceed with combining them, here’s how:
- Open the monitoring plan you no longer wish to use.
- Select Edit Data Source and turn off the Monitor this data source and collect activity data toggle.
- Do not delete the plan. Keep it until the data it holds has aged out per your retention settings (viewable under Settings → Audit Database). For example, if retention is set to 180 days, wait 180 days after disabling monitoring before deleting the plan.
Next, add the same File Server to your preferred plan. Make sure to use the same format (e.g., FQDN vs. NetBIOS) that was used in the original plan to ensure consistency.
For searches, it’s important to start with:
• Data Source → Equals → File Servers
• Then: Where → Equals → [Name of File Server] (match the exact name as shown in the plan)
This approach ensures you’re searching across both the active and historical data sources effectively.
When running reports, behavior will vary. Some allow selection of multiple plans; others may require running the report separately for each.
If you have any questions as you go through this, feel free to reach out—I’m happy to assist.
I only have 24 VMs total, 12 in each plan, and I am only collecting successful access activity and state-in-time data. The issue really lies with reports that only let me select 1 Plan at a time. Currently I am using the solution for permissions auditing/management. Maybe I use a plan just for state-in-time data.
Marc,
Thanks for the additional context—that definitely helps.
Yes, you can separate the Activity Records from State-in-Time data if that works better for your reporting needs.
One approach would be to edit both of your existing plans, go to Edit Data Source, and disable the State-in-Time option at the bottom. This way, both plans would continue collecting Activity data only, without duplicating or spreading State-in-Time data across multiple databases.
Then, you can create a new monitoring plan specifically for State-in-Time. Just be sure to configure it carefully:
- Do not enable Changes or Read Access options.
- Most importantly, make sure “Adjust audit settings automatically” is turned off to prevent any conflicts with your existing Activity-based plans.
Here’s a screenshot showing how I’d recommend setting up the State-in-Time-only plan. Note that the Compression Service is optional but the Compression Service is most helpful during State-in-Time collections.
Let me know if you’d like help configuring this or have any questions along the way—happy to assist.
1 Like
For the plan that is just collecting state-in-time data, I am still getting errors around incorrect audit settings. Is that normal? I didn’t think I needed to add the same exclusions to these Computer items since no audit data was being collected but it looks like I might have to.
Marc,
It depends on the specific error you’re seeing.
If the error mentions excessive audit settings, that’s expected behavior. Since all of the checkboxes at the top of the plan are unchecked, Netwrix assumes no auditing is required. But because auditing is still enabled due to your other plan, it flags the extra settings as unnecessary.
That kind of warning can safely be omitted. To do that, you’ll need to edit a file located in the Netwrix installation directory. The exact path may vary depending on where the product was installed, but the default location is:
C:\Program Files (x86)\Netwrix Auditor\File Server Auditing\omiterrors.txt
However, if the error is about missing permissions, that’s different. Collecting State-in-Time data alone shouldn’t require any audit policies to be enabled. If you’re seeing permission-related errors, feel free to send those over and I’ll help you review them.
Let me know what you find.
Marc,
Since you have the checkboxes correct, it should not be producing those error messages. Can you let me know what version of Auditor you are running so I can do some testing on my side?
Michael Purdin
Technical Support Manager
I have version 10.7 (Build 13822)
Marc,
I did some testing and I ended up with the same errors you did. I did some research and discovered that Auditor by default requires the audit settings for Successful Changes. In regards to the shares you are omitting, we still check those, even if we don’t check the data so that is why you are also getting a message about those shares.
Since you do not want to collect Successful Changes with this plan, I would recommend simply omitting any errors regarding auditing settings for this plan.
In the omiterrors.txt file, you could add the following lines.
Monitoring plan FileServer SIT,*,*auditing*
This will prevent those errors from showing up on that Montioring Plan.
One important note though. If those shares are part of your plans that are collecting the Activity, you do need to ensure that you have the object level auditing enabled to collect successful changes. By this SIT only plan giving you that error, it means that those settings are missing from those share. If those shares are omitted on the Activity Plans as well, the it’s fine but if you are not omitting those shares, you do want to ensure that you have the Object Level Auditing enabled.
I will give this a try.
Those items are already excluded in the other monitoring plans.
Marc,
Something in your screenshot caught my eye and I think there is 1 setting you can change to.
In the scope of your File Server plan, you are omitting the share like this
\\obbfs1\eigshared\Epic Project\*
However, it should be this
\\obbfs1\eigshared\Epic Project
By adding the * to end, you are saying you want to ignore all of the files in the Epic Project folder but not the Epic Project folder itself. I just tested and confirmed that I got the same error message on the excluded folder when I added the * to it but I didn’t get it when taking that part out.
1 Like
Ahh, good catch. I will make that change. Thank you!
@mpurdin : Is there a way to delete the SIT snapshots for those monitoring plans that are now only used for access auditing?
Hi Marc,
Technically, yes—this is possible, but I’ll need to make a few assumptions to guide you through the process. If any of these are incorrect, just let me know, and I’ll walk you through identifying the correct Monitoring Plan GUIDs.
The State-in-Time (SIT) snapshots are stored in the same location as your Long-Term Archive data. You can find this path by going to Settings > Long-Term Archive in Netwrix Auditor.
Inside that folder, you’ll see a subfolder named StateInTime, which contains one folder per File Server plan. These folders are named using GUIDs, which is where things can get tricky. This directory only holds SIT snapshots for File Server plans.
Here’s where my assumption comes in:
If you currently have just one active File Server plan generating SIT snapshots, identifying its folder should be straightforward—it will likely contain the fewest snapshot files. The other folders, with significantly more data, likely belong to older or decommissioned plans. You can safely delete those folders if you’re confident they are no longer needed.
However, if you have multiple active File Server plans still generating SIT data, I’d recommend scheduling a session so we can safely identify which GUID folders are safe to remove.
After clearing out those old SIT folders, there’s one more step: you’ll need to delete the file that stores metadata about these snapshots. To do that:
- Open services.msc and stop the service named: Netwrix Auditor Configuration Server Service
- Navigate to your Working folder. By default, this is:
C:\ProgramData\Netwrix Auditor(Note: this path may differ if it was customized during installation.) - Inside the working directory, go to:
AuditCore\ConfigServer - Delete the file named
SITStatus.xmland any associated .lock files. - Restart the Netwrix Auditor Configuration Server Service .The
SITStatus.xmlfile will be recreated automatically.
If you’re unsure about which folders are safe to remove or if you have other active plans, feel free to reply here and I’ll be happy to assist further.
Thanks,
Michael Purdin
Technical Support Manager
1 Like
If the only SIT data in the database is the latest snapshot for that Plan (with the exception of manually adding others, which I have not), then I am less concerned about cleaning up old snapshots. My main goal was to try to get this Account Permissions report to be more efficient (separate topic).
Marc,
I see, you are wanting to know about clearing out the SIT out of the old databases. Yes, that is possible. However, I would ensure that you make a backup of your File Server databases before running the following commands.
In SQL Server Management Studio, you would run the following commands on the databases that you wanted to clear the old State-in-Time snapshots from.
DELETE FROM [DATABASE_NAME].[dbo].[ConfItems]
Wait for the completions and then run:
DELETE FROM [DATABASE_NAME].[dbo].[ConfSessions]
Depending on how large the snapshots are, these may take awhile to run, that is expected. As always, please let me know if you have any questions about this.
Michael Purdin
Netwrix Technical Support Manager