SharePoint Tracing Service Error

I seem to be posting a lot of event viewer erorr fixes lately.
Oh well here is another one.

THE PROBLEM:

You are getting a repeating Event Log error 5400 stating the following:

Tracing Service failed to create the trace log file directory 'd:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\'. Error 3: The system cannot find the path specified.

THE CAUSE:

The problem is related to the permisisons on the tracing and diagnostic log directory for SharePoint services. This is configured in Central Administration under the Operations tab.

In our case what precipitated the problem was that we moved our diagnostic logs from the C:\ drive to the D:\ drive by just switching the drive letter in the path in Diagnostic Log settings window in Central Administration.

While the new path is taken just fine by SharePoint it does not inspect the path for the correct permissions and or allocate the correct set of permissions.

THE SOLUTION:

1. Modify the permissions on the following folders giving Local Service the List Folder Contents rights:

D:\Program Files
D:\Program Files\Common Files
D:\Program Files\Common Files\Microsoft Shared
D:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
D:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12

2. Modify the permissions on D:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs giving “Local Service” Modify rights.

Troubleshooting MOSS Excel Services synchronization job event log errors

On a production server we kept getting the following event log error 6483 every minute:

Application synchronization failed for Microsoft.Office.Excel.Server.ExcelServerSharedWebService.
Reason: System policies must have Full Control.
Techinal Support Details:
Microsoft.SharePoint.SPException: System policies must have Full Control.
at Microsoft.SharePoint.Administration.SPPolicy.SPPolicyRoleBindingCollection.AddById(Guid id)
at Microsoft.SharePoint.Administration.SPPolicy.SPPolicyRoleBindingCollection.Add(SPPolicyRole policyRole)
at Microsoft.Office.Server.Administration.SharedResourceProvider.EnsureWebApplicationPolicy(SPWebApplication webApplication, String userName)
at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeWebApplicationPolicies()
at Microsoft.Office.Excel.Server.ExcelServerSharedWebApplication.Synchronize()
at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeApplications(SharedComponentSecurity sharedApplicationSecurity)

It took me a long time to debug the error as it was alone and I could not figure out what the text System Policies Must Have Full Control meant. Finally I stumbled across another newsgroup posting that suggested it might have to do with the Web Application Policy settings. When I changed those the errors in the event log stopped.

What I Changed:
I went into Central Administration and under the Application Management tab I clicked on the Policy for Web Application link under the Application Security section. Then for each of my web applications I checked to see if any account had the Account Operates as System checkbox selected. (Which I did for one account on each web application) Once I unchecked that box for that account on each web application the error ceased.

Confession:
I checked that box thinking that the account in question (which was a farm admin account) would somehow benefit from it but I did not really understand what it did. The verbage provided on the page is not very helpful it seems only to indicate that the account's name (display name?) information won't be registered in logs, permissions & etc but instead it will appear as a system action. Anyway I guess this qualifies as one of those don't use a setting if you don't understand how it works situations.

So I have another question to take with me to the SharePoint Conference in March to get a better understanding of what that checkbox does and when to use it or not use it.

Moving SharePoint 2007 Content Databases (MOSS)

One of the things that is not discussed well at all in Microsoft's documentation on MOSS 2007 is the steps you have to go through to properly move a content database. If not done correctly you can get lots of fun errors like this:

Failure trying to synch web application A duplicate site ID was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The word is starting to get out about using the preparetomove command but what do you do when you have already moved the database? That is when this great posting from Cory Burns comes in handy. Cory does a great job of explaining some little known stsadm commands that can help you get your SSP synchronization straightened out and remove those repeating event log errors.
http://blogs.technet.com/corybu/archive/2007/06/01/detaching-databases-in-moss-2007-environments.aspx