SharePoint Dan

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.

Microsoft has released the SharePoint 2007 December 2009 Cumulative Update as of 29 January 2010. The cumulative update like all other updates includes all hotfixes since the most recent Service Pack, in this case SP2.

Information pertaining to this cumulative update is available at from the Update Resource Center at:

http://technet.microsoft.com/en-us/office/sharepointserver/bb735839.aspx

The WSS v3 December 2009 CU infopage is available at:

http://support.microsoft.com/kb/977027

The MOSS 2007 December 2009 CU infopage is available at:

http://support.microsoft.com/kb/977026

When requesting the appropriate CUs, if you’re downloading from an x86 client machine and your environment is x64 or vice versa, please note the “Show hotfixes for all platforms and languages” text next to “Number 1″.

Some insight from Joerg Sinemus regarding the December 2009 CU:

http://blogs.msdn.com/joerg_sinemus/archive/2009/12/16/wss-and-moss-december-2009-cu.aspx

Last but not least… please remember to test all service packs, cumulative updates and hotfixes in a staging or development environment prior to implementing in your system’s production environment.

This weekend I undertook the fun of building out a medium sized farm on my personal development hardware with my trusty MSDN license that I bought for my own personal use to begin testing a few pieces of code I’ve been working on as well as to have a play ground to work through occasional architectures, web part testing and diagnosing issues.  Oh, and the fact that I’ve not had the opportunity to work with Windows Server 2008 all that much, so I figured why not go ahead and build out an environment to get my hands dirty and learn the ins and outs?

So the first part to the madness that should be understood is that IIS 7 (standard for Windows Server 2008) is a lot more granular in nature than IIS 6 which is the standard web publishing application on Windows Server 2003.  From even when you’re starting your installation of the Web Server role to installing the individual components, it’s far more granular and modular, and probably confusing to some administrators that are used to just clicking “IIS” from Add/Remove Program in Server 2003.

So where to begin, well, once you’ve got your Windows Server 2008 box up, operational, patched, service packed, sysprepped (if you’re using Virtuals, you end up requiring that you have different SIDs and computer names right?), IP’d and joined to a domain, the fun begins in installing just the framework prior to SharePoint.

Step 1 – Open up the Server Manager, this typically appears when you power on the server, but if not, you should be able to find it fairly easily from the start menu.  Select and expand the roles label from the tree in the left pane, then select “Add Roles” from the right pane.

Step 2 –   If this is your first time installing a role, this would probably be helpful to read “Before You Begin”.  Definitely read through it at least once, after that, feel free to click the check box to skip it in all future instances.  Click on Next.

Step 3 – Select the Web Server role from the list of server roles. Note that you will be prompted to select additional features for the Web Server role to operate properly.  Select “Add Required Features” else turn and back away, and perhaps reconsider what you’re looking to do.

Step 4 – Once you’ve accepted the need for additional “required” features to be installed, you should see something like the below stating that you have selected the “Web Server (IIS)”.  Click on Next.

Step 5 – The role installation wizard presents an overview of the Web Server (IIS) role which again is fairly useful for an administrator to read through the first time.  Click Next.

Step 6 – Select the individual server roles that you require for your SharePoint installation.  I’ve found that the basic role services that are installed with IIS 7 are barebones, which from a security posture is fairly helpful so as to not have to remove several roles, but it will make you stop and think through what roles you do indeed to make the system operational.

Step 7 – The first thing to select of course to make your platform usable by SharePoint is the ASP.NET development platform.  Once you’ve selected this, you will be prompted to add additional roles that are required for ASP.NET.  Select the “Add Required Role Services” else, much like before, be prepared to have a difficult time installing SharePoint services on your server.

Step 8 – Select the additional roles that will assist in your SharePoint implementation, in my case this also includes “Logging Tools” to diagnose issues that may come up.

9 – Select the appropriate authentication providers that you wish to be able to utilize.  For me, I’m going with a fairly vanilla SharePoint installation and configuration, so I’ll select “Windows Authentication”.

10 – Additionally, so as to not bother with going back and installing later, I’ve selected the “IIS Management Scripts and Tools”.

11 – Lastly, the “Management Service” to be able to better manage the IIS 7 instance on the server from the server or remotely.

12 – After selecting the roles that are appropriate to support your SharePoint services installation, click on Next, which then will bring you to a page that lists all of the components that you are looking to install.  Do a quick read through to ensure that you’ve got the components, roles and features that you require and click on Install.

13 – Observe the installation process as can be seen here:

14 – After a few minutes, the installation progress bar will complete and an installation results page similar to this will be presented.  Click on Close after you’ve observed that your installation results were successful.

15 – After you’ve completed your IIS 7 installation, you’ll see that there are 24 installed role services related to IIS running and operational on the server through the Service Manager roles summary.

Next on Tap:

• SharePoint on Windows Server 2008 – Installing and Configuring SQL Server 2005 on a single node
• SharePoint on Windows Server 2008 – Installing and Configuring Microsoft Office SharePoint Server 2007 Standard Edition
• SharePoint on Windows Server 2008 – Configuring Kerberos based Windows Integrated Authentication