One of the new capabilities of SharePoint 2010 that comes in handy is the Health Monitoring alerts that pop up on the front page of Central Admin. One thing you might run into is when you start to run out of disk space. You’ll probably see something similar to this:
Always something that you want to see while you’re working on your environment right? Not so much.
For some reason it always seems that just when things are going well, profiles are synchronizing, users are starting to engage the SharePoint platform, and boom, whammo, the file system fills up with log files, trace logs and event logs. So just a gentle reminder to examine where your log files are and consider moving them to an alternate drive than the core OS drive.
How do I do this you ask? Pretty simply…
First off, decide what your disk plan is for your SharePoint Servers – hopefully you’ve got more than just a single drive in your system, if not slap on an extra drive (either physical or virtual) for log files, or if you’ve got a SAN handy, request an extra drive on separate spindles from where your data is stored and have them zone it for your SharePoint server to be added for offloading.
Next, for your IIS logs, simply open up IIS and go to the server name (in my case SP2010WFE-01) and then in the main information pane of IIS, scroll down to Logging underneath IIS.
Locate the Directory location and modify it to the location that you’ve setup for log files, in my case I’ve added an additional drive to my SharePoint server with the logical volume “E:”
Once IIS creates the structure, you’ll want to copy over old log files from your core OS drive (C:\inetpub\logs) to your new location.
Next up, Trace Logs for the Unified Logging System…
Within SharePoint Central Admin, navigate to Monitoring, within Reporting select “Configure Diagnostic Logging”.
Direct Link – http://<NetBiosNameOfSharePointServer>:<CentralAdminPort>/_admin/metrics.aspx
Scroll down to the Trace Log section where you’ll see something like this:
Simply input the drive that you’d prefer to use, in my case replacing %CommonProgramFiles% with “E:\Program Files\common files”, and you end up with something like this:
Go ahead and copy over the contents of the Logs file on the original instance to the new instance to consolidate your log files.
Lastly, moving your event logs to the log drive is definitely a consideration to make – especially the Security Log file as this will grow quickly once you’ve implemented Kerberos and opened your system to your user base (NTLM spawns quite a few security events too). Out of the box you’ll see your event logs like this:
Application Event Logs
Security Event Logs
System Event Logs
Simply modify the “File” location to the new location where you are looking to store your files, in my case I use “E:\Windows Events\Logs\” as the directory followed by the appropriate event log file name. This is documented in: http://support.microsoft.com/kb/216169
Further, to ensure that log files don’t explode, leverage the “AutoBackupLogFiles” property within the Application Events (you’ll have to add this to the Security and System Event Logs, simple DWORD property). Setting the value to “1″ or any value other than “0″ will create backup files in the file location specified.
This is documented in http://support.microsoft.com/kb/312571 (though it’s specific to 2000/2003 server, it works for 2008).
These three simple changes should assist in keeping your core OS drive lighter weight and prevent your system from a hiccup caused by a disk filling up.
. And though the services architecture is a bit more broken out, you can only have a single Application Registry Service per farm, which means that you can only have a single database associated with your farm, which in turn means get ready to watch it grow should you be migrating several BDCs into your farm while you prep them for conversion to Business Connectivity Services candidates.
