InfoPath Publishing To Form Server Disabled...

THE PROBLEM:
I ran into an issue a few weeks back that had me puzzled. I was attempting to publish some InfoPath forms to a demo MOSS site as browser based content type InfoPath Forms. When I fired up the publishing wizard the option to publish them as browser enabled forms to SharePoint was disabled. I could not figure out what was wrong and it took me a while to realize the cause.

THE CAUSE:

It turns out I had deleted a necessary form library on the SharePoint server in my desire to "clean" up my demo server. Without that library's existence the InfoPath client will not allow the publishing options to be enabled.

THE SOLUTION:

So the lesson here is that InfoPath Forms Server requires a form library called "Form Templates" on the top/root site of the destination SharePoint Site Collection in order to support publishing. Fortunately I was able to recover mine from the Recycle Bin.

Hope this helps someone else...

In a twinkling...

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

MOSS DCOM Errors in Event Logs...

I have from time to time had to address various DCOM errors in MOSS.
There are several good blog postings out there and I am primarily writing this note to help remind myself and tell others about them.

For the DCOM errors related to launching the object with CLSID {61738644-F196-11D0-9953-00C04FD919C1} with event id 10016 check out this article:
http://soerennielsen.wordpress.com/2007/04/16/fixing-those-pesky-dcom-event-log-error-10016-in-a-sharepoint-farm-environment/

For the DCOM errors related to the search services and caused by the MSFT October hotfix check out this article:
http://share-point.blogspot.com/2007/11/mosswssv3-bug-in-sharepoint-public.html

Sam's Birthday 2008

Sam had a great time on his 2nd birthday. He was (as evidenced in the video) a little puzzled by the candles and the cake!