FSRM Quotas suddenly stop auto-expanding — how can I recover them?

Question

FSRM Quotas suddenly stop auto-expanding — how can I recover them?

Smith Oliver 80

Hey everyone,

I’m running into a strange issue with File Server Resource Manager (FSRM) on a Windows file server.

I have auto-expanding quotas configured for users’ home folders. They normally increase automatically when the quota reaches 100%, but recently some quotas have stopped expanding. Once the limit is reached, applications start failing to write files and users receive quota-related errors.

I’m wondering if the FSRM quota database or service state may have become corrupted.

Has anyone experienced something similar? What’s the safest way to reset/re-initialize the FSRM quota engine or rebuild the quota database without losing the existing quota configuration?

Any advice or recommended troubleshooting steps would be appreciated.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello Smith,

The behavior you’re describing usually points to corruption or inconsistency in the FSRM quota database, or the service failing to properly commit auto-expansion events. When quotas stop auto-expanding, the first thing to confirm is that the FSRM service (srmsvc) is running cleanly and that the quota management database is intact. The database is stored under %SystemRoot%\System32\srms\quota.mdb. If this file becomes corrupted, quotas may stop responding to triggers.

The safest recovery path is to export your current quota configuration, reset the quota database, and then re-import the configuration. Use dirquota to handle this. Run:

dirquota template export /file:C:\temp\QuotaTemplates.xml

dirquota quota export /file:C:\temp\QuotaObjects.xml

This ensures you have a backup of all templates and applied quotas. Once exported, stop the FSRM service:

net stop srmsvc

Then rename or move the quota database:

ren %SystemRoot%\System32\srms\quota.mdb quota.mdb.old

Restart the service:

net start srmsvc

This forces FSRM to rebuild a fresh quota database. Finally, re-import your saved configuration:

dirquota template import /file:C:\temp\QuotaTemplates.xml

dirquota quota import /file:C:\temp\QuotaObjects.xml

After this, verify that auto-expanding quotas are functioning again. If the issue persists, check the Event Viewer under Applications and Services Logs > File Server Resource Manager for warnings or errors around quota expansion. In some cases, the problem can be tied to insufficient permissions on the target folders or a mismatch between NTFS volume state and FSRM’s internal counters. Running chkdsk on the affected volume can help rule out filesystem inconsistencies.

If you’re running a clustered file server, ensure that the FSRM role is properly synchronized across nodes, as quota expansion events can fail if the database is not consistent cluster-wide. Microsoft has documented cases where quota corruption requires a full reset as described above, and that’s generally considered the supported method to recover without losing configuration.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HL.

Answer 2

A safe recovery path is to repair FSRM state first, then reapply quota configuration only where needed.

Verify the storage type first. FSRM works only with NTFS. ReFS volumes cannot be managed by FSRM. If the affected home folders are on ReFS, move the data to NTFS.
Check whether the issue is quota configuration drift versus usage out-of-sync.
- If quota settings need to be brought back in line with the template, use:
```
     Reset-FsrmQuota -Path "C:\Shares" -Template "100 MB Limit"
```
  This updates an existing quota with the settings from the quota template.
- If quota usage is out of synchronization with actual usage, run a manual quota scan:
```
     Update-FsrmQuota -Path "C:\Shares"
```
  Use this only when usage is out of sync, because the scan is a long-running process.
Reapply autoapply quotas if template-based expansion behavior stopped updating. In FSRM, verify the quota templates match the intended policy, then reapply autoapply quotas with:
```
   Set-FsrmAutoQuota -Path <path> -Template <template> -UpdateDerived
```
If the FSRM service or quota database state appears corrupted, repair the FSRM files and service state. Warning: renaming or deleting the quota XML can require quotas to be reconfigured afterward, so back it up first.
- Stop the service:
```
     net stop srmsvc
```
- Repair ownership and permissions on the quota database file:
```
     takeown /f "C:\System Volume Information\SRM\quota.xml"
     icacls "C:\System Volume Information\SRM\quota.xml" /grant administrators:F
     attrib -s -h "C:\System Volume Information\SRM\quota.xml"
```
- If the XML is corrupted, rename or delete it only after backup, restart FSRM, and then reconfigure the quotas.

Repair WMI if FSRM still behaves inconsistently.

   winmgmt /verifyrepository
   winmgmt /salvagerepository
   net stop winmgmt
   net start winmgmt
   net stop srmsvc
   net start srmsvc

Reregister the FSRM service DLL.
```
   regsvr32 /i srmsvc.dll
```
Collect state before making destructive changes. Useful data to capture:
- Event Logs: Application, System, SRMSVC, NTFS Operational, custom FSRM logs
- PowerShell outputs:
```
     Get-FsrmQuota | Select-Object Path, Size, Usage
     Get-FsrmAutoQuota
```
- FSRM exports:
```
     dirquota quota list > quotas.txt
```

The safest order is:

Capture current quota configuration.
Verify NTFS.
Reapply template-derived auto quotas.
Run Update-FsrmQuota if usage is out of sync.
Use Reset-FsrmQuota on affected paths if quota settings drifted from the template.
Only then repair quota.xml, WMI, or srmsvc.dll if corruption is suspected.