In my last post, I showed you how to redirect your IIS logs and SharePoint trace logs to a separate logical hard drive. This is important to prevent system instability if you let your logs get really long (as in up to the size of the remaining free space of your system disk). The thing is: I showed you how to do this via the UI. As we all know, doing this via the UI can be prone to human error. It’s SO much easier to just to put this stuff in a script, so that you can ensure that each setting is committed the right way every time.

For IIS7, the way to control the application is via AppCmd.exe, which the IIS team ships. For SharePoint 2007, STSADM is normally the way to do this. If you go and explore STSADM’s endless collection of operations, however, you will find that the ability to set the log location is not available. Bummer! Particularly if you are trying to script the deployment of your farms and want to ensure that it’s always done the same way.

Never fear! PowerShell is here. If you haven’t already acquired a taste for Windows PowerShell, now is the time to start digging in! Every Microsoft server product and technology will be required to natively support PowerShell in the future. In fact, it’s pretty safe to say (since it’s written in the Windows Server Common Engineering Criteria for FY09) that any product shipping after July 1, 2008 is required to have this support or else explain themselves to our internal executives that closely ensure we follow our internal rules for first-class software engineering. So, even though SharePoint 2007 doesn’t include built-in support for PowerShell, it turns out that you can take advantage of our managed object model and get the benefits right now. The scripts below will show you how.

Note: You must run these scripts within an elevated Windows PowerShell instance. One way to do this is to right-click on the Windows PowerShell icon and select Run as Administrator and approve the resulting UAC prompt. Failure to do so will cause the IIS7 components to fail. For the SharePoint part, you must be running as a user with permission to set this setting within Central Administration, regardless of whether the Windows PowerShell instance is elevated.

Automating IIS7 Log Locations

Continuing with our example from my last post, where we want One log per: Site and we want it located at E:\logs\iis, here’s the simple PowerShell script you can run one every machine in your SharePoint farm:

#
# SCRIPTING THE CHANGE OF THE IIS 7 LOGS

& $env:windir\system32\inetsrv\appcmd set config "-section:system.applicationHost/sites" "-siteDefaults.logfile.directory:""E:\logs\iis"""
& $env:windir\system32\inetsrv\appcmd set config "-section:system.applicationHost/log" "-centralBinaryLogFile.directory:""E:\logs\iis"""
& $env:windir\system32\inetsrv\appcmd set config "-section:system.applicationHost/log" "-centralW3CLogFile.directory:""E:\logs\iis"""

Automating SharePoint 2007 Trace Log Locations

Because SharePoint manages the notion of a “farm,” which comprises multiple machines, you only need to run the script below on a single machine within your farm (though it wouldn’t hurt to run this on every machine, it will just result in setting the property multiple times):

#
# SCRIPTING THE CHANGE OF THE SHAREPOINT 2007 TRACE LOGS

[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c");
[Microsoft.SharePoint.Administration.SPDiagnosticsService]::Local.LogLocation = "E:\logs\uls";
[Microsoft.SharePoint.Administration.SPDiagnosticsService]::Local.Update();

The magic behind how this script above works is that it is leveraging PowerShell’s ability to run against any managed code objects. SharePoint 2007 has an entirely managed object model, so even without built-in cmdlets, you can still get a bunch of benefit from using PowerShell. The first line loads the SharePoint assemblies into the Windows PowerShell instance. Once we’ve done that, we can get to singleton objects easily using the [] syntax. We can then use the :: operator to call methods and properties off of the object. If you look at the SharePoint object model documentation, you will find that the SPDiagnosticsService object with the LogLocation and Update() methods are the keys to setting the trace log’s location. Once these lines have run, you can go to Central Admin and look at Central Administration > Operations > Diagnostic Logging page and you will see E:\logs\uls in the Path box of the Trace Log section.

Pretty cool, huh?

References

I wanted to give credit where credit was due for this post. Without the following blog posts, I wouldn't have been able to figure out everything I showed here:

• Thomas Deml's "Just Another IIS Blog" - Moving the IIS 7 INETPUB directory to a different drive
• Adventures in SPWonderland - PowerShell and SharePoint - Oh Yes