The official blog for Windows Server Essentials and Small Business Server support and product group communications.
[Today’s post comes to us courtesy of Damian Leibaschoff and Wayne Gordon McIntyre from Commercial Technical Support and Chris Puckett from Product Quality]
SBS 2008 installs all of its features using a single volume (C:), there are tools available to move some of the data to other locations, but a number of folders that remain in the C: volume can continue to grow if left unchecked, this can potentially eat all the available disk space on the C: drive. Once the C: drive reaches certain low space thresholds, some services will stop functioning properly on the server, while others will change their behavior to prevent data loss. Usually, administrators realize they have a problem when e-mail flow is impacted, under low disk space conditions, due to the Exchange Back Pressure features, mail flow will stop. Users may experience some of the following errors or non-delivery-reports: Error 0x800CCC6C, SMTP_452_NO_SYSTEM_STORAGE, or 452 4.3.1 Insufficient system resources. These are some of the steps that can be performed to help recover and prevent these issues.
(This is expanding on the existing post “Reclaiming Disk Space Lost to IIS Logs on SBS 2003 and SBS 2008”)
By default, all IIS hosted web sites have logging enabled, this can lead to some large folders in C:\inetpub\logs\LogFiles (Review this post in case you have moved your log files). You may also want to specifically stop logging all together for certain web sites, in particular, the “WSUS Administration” web site (Site Id 1372222313). For this, perform the following steps:
Some of the SBS 2008 log files can grow to very large sizes, all SBS logs are stores in this folder (and subfolders): C:\Program Files\Windows Small Business Server\Logs\. Some of the logs that will grow the most and may need trimming are:
If you are using the POP3 Connector, you may end up with emails that failed to be delivered (rejected by the local Exchange server) in C:\Program Files\Windows Small Business Server\Data\badmail. This folder will be automatically trimmed to 400mb once it reaches 450mb once a week.
This is discussed on the Windows Small Business Server 2008 Release Documentation You can delete the events in the Windows SBS 2008 licensing log to free up additional space on the hard disk drive.
To delete events in the Windows SBS 2008 licensing log
You can also use Registry Editor to disable the licensing log.
In WSUS, you can delete unused updates and update revisions, computers not contacting the server, unneeded update files, expired updates and superseded updates. In order to accomplish this, you have to manually go through the WSUS Server Cleanup Wizard. To run the Server Cleanup Wizard :
Please read the following KB article for an explanation and instructions on how to prevent this: 2000544 SBS 2008 BPA Reports that The Windows SharePoint Services configuration databases log file is getting large (currently over 1gb in size)
When completing a critical or system state backup of the C: volume, a new transaction log will be generated under the c:\windows\system32\certlog\ folder. Removing these logs is only safe as long as the CA database file is consistent. In order to remove these logs and reclaim disk space, follow these steps:
The Windows Component Clean Tool (COMPCLN.exe) can be used to remove the files that are archived after Windows Vista SP2 or Windows Server 2008 SP2 is applied. It also removes the files that were archived after Windows Vista SP1 was applied, if they are found on the system. Running this tool is optional.
Installing Windows Server 2008 service packs increases the amount of disk space that is used by the operating system. This space is used to archive files so that the service pack can be uninstalled. Typically, you should run COMPCLN.exe if you want to reclaim this disk space after applying SP2 and if you will not need to uninstall SP2.
NOTE: You cannot uninstall Windows Vista SP2 or Windows Server 2008 SP2 after you run this tool on an image.
We are not going to focus on these wizards on this post, but as a reference, SBS 2008 provides an automated way of moving the following:
Update #1 3/3: Added reference to WSUS Administration web site ID (Site Id 1372222313)Added reference to Exchange 2007 BackPressure NDRs and errors due to low disk space
Thank you for an excellent post, which I really needed.
Can you please explain how to "trim" the following:
i. Console.log, this log will continue to grow while the SBS Console is running.
ii. *.evtx files, these are the event logs before the setup of the server completed, they can be safely removed if the server has been in production and had no setup issues.
iii. W3wp.log, in the C:\Program Files\Windows Small Business Server\Logs\WebWorkplace folder. This is the log for Remote Web Workplace.
iv. The C:\Program Files\Windows Small Business Server\Logs\MonitoringServiceLogs folder. These are the logs for the Windows SBS Manager service.
Can you please also confirm whether or not by disabling, for example, WSUS logging that the log files are purged automatically ? or is this a manual step ?
Very nice. Run into low space on C: drive frequently. For those clients who are still on SBS 2003, is there a similar set of guidelines available?
This post is absolutely fantastic. I had a few posts in the newsgroup ages ago about the log files issue and most people thought I was crazy.
You will have to clean up the WSUS IIS logs manually. With regards to the actual SBS logs, the *.evtx can be manually removed after a good installation. The others would need to be manually removed or compressed as needed, keep in mind that if the file is in use you are not going to be able to delete it.
With regards to SBS 2003, some of these things apply, IIS logging would be different (IIS 6), but same concepts. Also, Exchange log files if Exchange aware backups are not being completed.
I've performed the commands in KB2000544, but cannot compact the database. I get this error:
sqlcmd -S \\.\pipe\mssql$microsoft##ssee\query\ -E -i c:\batch\ps\logshrink.sql
HResult 0x2, Level 16, State 1
Named Pipes Provider: Could not open a connection to SQL Server .
Sqlcmd: Error: Microsoft SQL Native Client : An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections..
Sqlcmd: Error: Microsoft SQL Native Client : Login timeout expired.
First, thanks a whole heap for all the info in this post!
You post the link on how to fix the Sharepoint log file that keeps growing beyon 1GB in size. Two things: (1) many SQL experts say that truncating a file in such a way is NOT considered best practice; and (2) does anyone have a reason for why it keeps growing?
In my case, I have a customer on SBS2008 Standard. They were on it for 3 months before we even started doing anything with Sharepoint with them, but yet, this Sharepoint log file was already over 1GB in size.
Re; the COMPCLN.EXE utility -- you do not specify how to run it. Should it be run from a command prompt? And if so, do you need to start command prompt with 'run as administrator' priveleges?
I just ran ComplCln on one of my SBS2008 servers ... ran it from elevated command prompt. When it finished, it reported: "Not all files were removed." ??? What does that mean?
That is the general recommendation is for recovery purposes. I agree it's not a best practice - for enterprise databases. We're talking about an operational database here that grows because of a number of transactions that essentially don't add any meaningful data. How often do you need to recover the SBS SharePoint database to a specific point in time? I have never seen an SBS managed to that level - almost everyone backs up the entire server (if they do backups at all). You're right that you lose the ability to roll back the database at that point. If that's really how your installations work, then you know not to run the script. For most installations, reducing the size of the log file makes sense.
To answer #2 - The actual transactions being logged so often are timestamp updates from the timer service. They don't add much value, but they're also not configurable AFAIK.
0x2 is a standard "not found" error
First make sure that you have a microsoft##ssee instance. You can test connectivity by running "OSQL -S \\.\pipe\mssql$microsoft#
Try typing the entire command rather than copy/paste.
Also, make sure you're logged in as the administrator account you installed SQL with (to make sure you have rights), and run from an elevated command prompt.
Yeah, found it. I knew the best way to solve a problem on my own is to post it--I will find it right after posting! Shortly after, I remembered something similar to your post. I work in PowerShell exclusively so I should be aware that characters like $ and ## collide with its parser. Got it going, thanks again.
@Kevin you might want to try enabling verbose logging to see what packages it couldnt remove and why. It should be run from an elevated cmd prompt.
My guess is that the there was a lock on the file by another process so it couldnt remove it (AV perhaps) but the verbose log should help in identifying which package and why.