SharePoint 2010 – Drive Space Conundrum

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:inetpublogs) 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&gt;:<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 Filescommon 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 EventsLogs” 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.

TaxonomyPicker.ascx bug (SP2010 RTM)

Please note the update!

So apparently others have stumbled upon this but when doing my rebuild of RTM over the weekend I noticed a nifty little error popping up in the event log that raised a little concern with regard to the TaxonomyPicker user control.

Looking at the error, you’ll notice that it states the TaxonomyPicker.ascx user control can’t register an assembly ‘Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker’ from assembly ‘Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’.

If you’ve seen something like this before it’s typically because either a user control was edited incorrectly such that a character was incorrectly added to the assembly register string, or someone removed the assembly from the server and the user control is “freaking out” (never a good thing).  In this case it’s just a typo in the user control – but wait, this is out of the release to manufacturing right? Yeah, about that…

So the fix, simply navigate to the 14 root at: %systemroot%Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATECONTROLTEMPLATES where you’ll find the TaxonomyPicker.ascx user control.

If you haven’t created a short cut to the 14 root yet, you may want to as I’m sure you’ll be visiting there often 🙂

First – make a copy of the file and save it as perhaps TaxonomyPicker.ascx_backup or something along those lines – what works for you, run with it.

Next using your favourite text editor (TextPad for me), open the user control and observe in the first line the error.

Interesting that “TaxonomyPicker,” made it through quality assurance testing, but alas, not a huge detail right? Simply replace the “,” with a “,”

Save the user control and restart the app pool and presto, the error should be no more.

Permissions still as they should be? Should look like this…

Also, check to ensure that you’re still inheriting permissions properly by opening the file properties -> security -> advanced

And with that, you’re done. Happy tuning.

Update – Apparently the error will continue to persist even after making the correction to the file.

Looking in the Microsoft.SharePoint.Portal Assembly it looks like there is no actual TaxonomyPicker class, so in reality you can just keep the copied file (TaxonomyPicker.ascx_broken) and remove the fixed version. That being said, until the TaxonomyPicker class is implemented within the Microsoft.SharePoint.Portal assembly, you’re safe in not worrying about this user control.