I installed SharePoint 2013 to become familiar with it and to also use the wiki functionality. It is now clear I will not likely be able to maintain SharePoint at the present time because it requires more attention than I'm able to give. But until I can transition my material to another mechanism, I'll need to keep SharePoint functional. I'd like to ask for some 'triage' style help to stabilize the system.

My immediate problem is the disk space used keeps growing. So following advice from multiple posts, I ran WinDirStat to find where the space is being used. But WinDirStat doesn't seem to reflect where the space is being used.

The server is a Hyper-V VM running 2012 R2 Standard, SharePoint 2013. The VHD is currently 99 GB in size, which was increased from 70 Gig just a few weeks ago. I haven't added any content, but 10 more Gig has been occupied, so it's now at 89 Gig full.

But WinDirStat only shows 36 Gig in its analysis. On my other PCs, WinDirStat shows an accurate reflection of disk space used.

So I can't even locate the files that are growing to know what to fix.

I did very little special configuration when I installed it. Just installed, added the wikis and started creating material.

  • Is SQL Server also running on the same VM? That is, is it a single server farm?
    – mannaggia
    Feb 12, 2018 at 12:13
  • Yes, it is. I should have added that above. I'm certain my problems are logging, but I can't locate where the logging problem is. I did set the store log files window from 14 days to 3 days and immediately picked up about 4-5 gig, but I'm pretty certain the SQL logging may be what's causing the big problems. I just don't know how to locate the appropriate database to fix, nor am I certain of what to do.
    – Alan
    Feb 12, 2018 at 12:26

2 Answers 2


First thing to check is the databases.

If you don't have it, download SQL Server Management Studio (SSMS) and install it. Then use it to connect to the SQL Server instance running for SharePoint and right click on each database (except System Databases) and choose Properties, then look in Options. Change the Recovery model to Simple if it is set to Full on each database.

(Note: This means you can't just do transaction log backups.)

If the problem is your database transaction logs, this will "stem the tide" and stop them from growing so quickly, but will not recover the space they took up.

Although some SQL Server purists will cry, if you want to recover the space from those transaction logs, right-click on the database name, choose Tasks -> Shrink -> Database Files. Change the File type to "Log". If the log is very large (in Currently allocated space) and has a lot of free space, use the Shrink action of "Release unused space" and click OK. That will recover the space.

The log will then grow to what is needed but the Simple recovery model will keep it pretty much in check.

  • I do have SSMS installed, will follow your instructions and report back. Just the first few databases I've looked at have Full set. I had checked the WSS_Logging and it was set to Simple. I did not realize databases other than logging would have the same issue. Any thoughts on why WinDirStat is not reading the disk correctly?
    – Alan
    Feb 13, 2018 at 0:37
  • Your guidance recovered 50 Gig on my server. Thanks so much.
    – Alan
    Feb 13, 2018 at 1:20

WindirStat only checks the allocated size in your disk, not the actual size. If your users have files there but these files did not get synchronized to your disk yet, WindirStat will report the file with 0 size or the size you last synchronized it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.