Setup: Hyper-V 2012 R2 host, primary guest is TFS single server installation w/ SharePoint (includes SQL for TFS ops)

The SharePoint install is used solely to support TFS operations for a very small development effort. The single server setup has been working terrifically for some time. This server is used for nothing other than TFS and TFS supporting SharePoint operations.

The problem is that the server VHD filled up, which I'm guessing is a straightforward issue of saving logs from one or all of the following:

Server OS, TFS, SharePoint

I am posting on other stack exchanges regarding the server OS and TFS, but posting this with regards to SharePoint. I was able to easily expand the VHD size, but I suspect the problem will return again. I'd like to fix the underlying cause.

Do I have to set parameters to keep SharePoint from over running the disk space with logs, or is SharePoint likely innocent of the disk usage problem I am experiencing? I have full access to SharePoint setup.

3 Answers 3


SharePoint has no limit on logs' total size by default, but limits lifetime (in days). See https://technet.microsoft.com/en-us/library/ee748656.aspx

I usually use WinDirStat to find out those problematic folders. The tool is free.

enter image description here

  • 1
    Thx for WinDirStat tip. Working to download it at this time. One comment/question: At the TechNet link above it mentions "Restrict Trace Log disk space usage " and allows a GB setting. As you say, it's not on by default, but am I correct assuming I can limit the space used with this?
    – Alan
    Mar 10, 2016 at 20:22
  • Right, by default SP stores logs for last 14 days no matter how big they get. But you can set additional total size limit in GBs Mar 10, 2016 at 20:27
  • Downloaded and installed WinDirStat. That's certainly one of the handiest tools I've ever seen. Thanks! My culprit seems to be SharePoint_Config_log.ldf, So I guess this may be a SharePoint log problem? It's using 50 GB.
    – Alan
    Mar 10, 2016 at 20:29
  • I'm glad you like it. I once found 700 GB of IIS logs that way. ldf is SQL Server database log, not SharePoint. See stackoverflow.com/questions/4403970/… Mar 10, 2016 at 20:38
  • 1
    Usually SQL Server is deployed to OSE with a lot of space, and DBAs take care of everything. To solve your problem just set recovery model to simple at SharePoint_Config database, and shrink it once. This is supported configuration. This is not a 'gotcha' or error of any kind, cause ldf stores information that can be used to revert database to state at any given moment of time - very useful in disaster recovery scenarios. In 2016 storage is super-cheap, downtime is super-expensive Mar 10, 2016 at 22:06

We have the SharePoint logs set to go to external storage, as well as to automatically delete after a certain number of days to avoid the situation you're describing.


Is the server also running SQL? If so, check to ensure that either the sql logs are being backed up properly or just switch it over to simple recovery mode. I've seen many SQL servers supporting sharepoint that are set to full recovery mode where the log file is many times the size of the database.

Otherwise, follow Erin's advice and check on the SharePoint log settings.

  • Yes. TFS uses SQL to store all its project data, so I guess technically I should have included that in my original post. Will do that. Starting to look into how I set the SharePoint log parameters WRT Erin's post. Haven't done that before.
    – Alan
    Mar 10, 2016 at 19:36
  • 2
    It's in central admin: technet.microsoft.com/en-us/library/ee748656.aspx
    – Mike2500
    Mar 10, 2016 at 19:43
  • +1. Your guess was correct, @Alan found _log.ldf of config DB Mar 10, 2016 at 22:12

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.