Fix 0x00001194: Volume Not SIS Enabled on Your Drive
This error pops up when Windows tries to use Single Instance Storage (SIS) on a drive that doesn't have it enabled. It's common on older Server systems or after a drive migration. Here's how to squash it fast.
The 30-Second Fix: SIS Already Off? Check the Volume
First, figure out if this volume even needs SIS. Single Instance Storage was a Windows Server feature back in the Windows Server 2003 R2 and 2008 days. If you're on Server 2012 or newer, SIS is deprecated—you probably don't need it, and the error's just a leftover.
Open a command prompt as Admin and run:
sisadmin /listIf it returns nothing, SIS isn't configured anywhere. The real trigger here is often a migrated drive from an old server—like I had a client who moved a file share from Server 2003 to 2016, and SIS calls were baked into the volume's metafiles. The quick fix: run this to see what's up:
fsutil volume querydisk \\.\X:Replace X with your drive letter. If it throws the 0x00001194 error directly, you're dealing with a volume that once had SIS.
If you don't need SIS—and you almost certainly don't on modern systems—just ignore the error if it's not crashing anything. But if it's blocking backups or a service from starting, move to the next step.
The 5-Minute Fix: Enable SIS on the Volume (If Required)
If some legacy app insists on SIS—like an old backup agent or a deduplication tool from 2008—you can enable SIS on the volume. This is safe on NTFS volumes, but it's a one-way street: once enabled, you can't disable it without reformatting. So be sure.
Enable it with:
sisadmin /add \\.\X:Where X is your problematic volume. Then start the SIS Groveler service:
net start "SIS Groveler"Wait a minute, then check if the error clears. If you still see 0x00001194, the volume might be corrupt. Verify with:
chkdsk X: /fHad a client last month whose entire print queue died because of this—they'd migrated a drive from a 2003 server, and the print spooler service kept hitting the error. Enabling SIS fixed it in under five minutes. But if you'd rather not enable SIS, skip to the advanced fix.
The 15+ Minute Fix: Disable SIS and Remove the Error Permanently
If you don't want SIS at all—and you're running a modern server—the only clean way to kill this error is to disable SIS across the board. This requires removing the SIS filter driver from the volume.
Step 1: Stop the SIS Service
net stop "SIS Groveler"Step 2: Remove SIS from the Volume
There's no built-in cmdlet to remove SIS cleanly after it's been enabled without reformatting. But if it's not enabled yet (you skipped the 5-minute fix), you can block the driver from loading. Edit the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SISSet the Start DWORD to 4 (Disabled).
Step 3: Reboot and Verify
After reboot, the SIS filter won't load, and the error should vanish. If it doesn't, the volume might have a stale SIS metafile. Use Process Monitor to track what's calling the error—it's usually a backup agent or an old deduplication service.
Worst-case scenario: migrate data off the volume, format it as NTFS cleanly (no SIS flags), and move it back. That's a nuclear option, but I've done it for a domain controller that held a legacy file share—took about 20 minutes with robocopy.
When to Call It Quits
If none of this works, the volume's on-disk SIS structure is toast. On newer Server 2012+ systems, just ignore the error if it's not causing crashes—it's a relic. On older 2003/2008 systems, enable SIS as a stopgap. Either way, you've got a fix. No need to nuke the drive.
Was this solution helpful?