- The article explains how to delete NTFRS logs in Windows Server, which are generated by the File Replication Service (FRS) that replicates files and folders between domain controllers and member servers.
- The article also provides instructions on how to check the FRS replication status, how to control the number and size of NTFRS logs, how to backup and restore the FRS database, and how to migrate from FRS to DFS-R for SYSVOL replication.
If you are running a Windows Server domain controller that uses the File Replication Service (FRS) to replicate system policies and logon scripts, you may encounter a situation where your server runs out of disk space due to the accumulation of NTFRS logs. These logs are located in the %Systemroot%\Debug folder and have names like NtFrs_001.log, NtFrs_002.log, and so on. In this article, we will explain why these logs are generated, how to delete them safely, and how to prevent them from growing too large in the future.
Table of Contents
- Why are NTFRS logs generated?
- How to delete NTFRS logs safely?
- How to prevent NTFRS logs from growing too large?
- Frequently Asked Questions
- Question: How can I view the NTFRS logs?
- Question: How can I backup and restore the FRS database?
- Question: How can I migrate from FRS to DFS-R for SYSVOL replication?
Why are NTFRS logs generated?
The File Replication Service is a multi-master replication engine that replicates files and folders between domain controllers and member servers that host the same Distributed File System (DFS) roots or child node replicas. FRS also replicates the SYSVOL folder, which contains Group Policy objects and scripts that are applied to domain computers.
FRS uses a database called Jet to store information about the files and folders that it replicates. The Jet database is located in the %Systemroot%\Ntfrs\Jet folder. FRS also uses a journal database called USN to track changes to the files and folders on the local disk. The USN journal is maintained by the NTFS file system and is located on each volume that FRS replicates.
FRS logs are generated when FRS performs replication operations, such as sending or receiving updates, resolving conflicts, or recovering from errors. FRS logs contain detailed information about the replication events, such as file names, paths, attributes, versions, GUIDs, checksums, and error codes. FRS logs are useful for troubleshooting replication problems or monitoring replication performance.
How to delete NTFRS logs safely?
Before you delete any NTFRS logs, you should make sure that your FRS replication is working properly and that there are no errors or warnings in the FRS event log. You can use the following command to check the FRS event log:
Get-EventLog -LogName File Replication Service
You can also use the following command to check the FRS service status:
Get-Service -Name NtFrs
If you see any errors or warnings in the FRS event log or if the FRS service is not running, you should resolve them first before deleting any logs.
If your FRS replication is working fine and there are no errors or warnings in the FRS event log, you can safely delete the NTFRS logs in the %Systemroot%\Debug folder. You can use the following command to delete all the NTFRS logs:
Remove-Item -Path "$env:SystemRoot\Debug\NtFrs*.log" -Force
Alternatively, you can use Windows Explorer to navigate to the %Systemroot%\Debug folder and delete the NTFRS logs manually.
Note: You should not delete any other files or folders in the %Systemroot%\Debug folder, as they may contain important diagnostic information for other Windows components.
How to prevent NTFRS logs from growing too large?
By default, FRS creates a new log file every time it restarts or when the current log file reaches 10 MB in size. This means that if your FRS service restarts frequently or if your replication traffic is high, you may end up with many log files that consume a lot of disk space.
You can control how many log files FRS creates and how large they can grow by modifying some registry values under the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters
The following table describes the registry values that affect the NTFRS logging behavior:
| Registry value | Data type | Default value | Description |
|---|---|---|---|
| Debug Log Files | REG_DWORD | 5 | The maximum number of log files that FRS creates. |
| Debug Log Severity | REG_DWORD | 2 | The level of detail that FRS logs. The possible values are: 0 (None), 1 (Fatal Errors), 2 (Errors), 3 (Warnings), 4 (Information), 5 (Verbose). |
| Debug Maximum Log Messages | REG_DWORD | 10000 | The maximum number of messages that each log file can contain. |
| Debug Log File Size in MB | REG_DWORD | 10 | The maximum size of each log file in megabytes. |
You can use the following command to modify these registry values:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters" -Name "<Registry value>" -Value <New value>
For example, if you want to reduce the number of log files to 3 and the size of each log file to 5 MB, you can use the following command:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters" -Name "Debug Log Files" -Value 3
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters" -Name "Debug Log File Size in MB" -Value 5
Note: You need to restart the FRS service for the changes to take effect.
You can also change the path to the logs directory by changing the following value at the same registry key:
| Registry value | Data type | Default value | Description |
|---|---|---|---|
| Debug Log File Directory | REG_SZ | %Systemroot%\Debug | The path to the directory where FRS creates the log files. |
You can use the following command to modify this registry value:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters" -Name "Debug Log File Directory" -Value "<New path>"
For example, if you want to change the logs directory to D:\FRSLogs, you can use the following command:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters" -Name "Debug Log File Directory" -Value "D:\FRSLogs"
Note: You need to create the new directory and restart the FRS service for the change to take effect.
Frequently Asked Questions
Question: How can I view the NTFRS logs?
Answer: You can use any text editor, such as Notepad, to open and view the NTFRS logs. You can also use the Ntfrsutl tool to dump the contents of a log file to the console. For example, to view the latest log file, you can use the following command:
Ntfrsutl dump $env:SystemRoot\Debug\NtFrs_0001.log
Question: How can I backup and restore the FRS database?
Answer: The FRS database is not included in the system state backup of Windows Server. Therefore, you need to use a different method to backup and restore the FRS database. One method is to use the Ntbackup tool with the /SNAP switch. This switch creates a snapshot of a volume that contains FRS data and then backs up that snapshot. For example, to backup the C: volume that contains FRS data, you can use the following command:
Ntbackup backup /SNAP C: /J "FRS Backup" /F "D:\FRSBackup.bkf"
To restore the FRS database from a backup file, you need to stop the FRS service, delete or rename the existing Jet folder, and then restore the Jet folder from the backup file. For example, to restore from D:\FRSBackup.bkf, you can use the following commands:
Net stop ntfrs
Rename $env:SystemRoot\Ntfrs\Jet Jet.old
Ntbackup restore /SNAP /J "FRS Restore" /F "D:\FRSBackup.bkf"
Note: You need to restart the FRS service after restoring the FRS database.
Question: How can I migrate from FRS to DFS-R for SYSVOL replication?
Answer: If you are running Windows Server 2008 or later, you can migrate from FRS to DFS-R for SYSVOL replication. DFS-R is a more efficient and reliable replication engine that offers many advantages over FRS, such as bandwidth throttling, compression, differential replication, and conflict resolution. To migrate from FRS to DFS-R for SYSVOL replication, you need to follow a four-step process that involves preparing your domain controllers, creating a global state file, changing your replication mode, and verifying your migration status.
Disclaimer: This article is provided for informational purposes only and does not constitute professional advice. You should always consult a qualified Windows Server expert before making any changes to your system or network configuration. Use this article at your own risk.