SharePoint Bugs

When troubleshooting SharePoint, you often have to dig several levels deep to discover the root of an issue. Recently one of my clients was running into an issue where the IIS application pool that was associated with their PowerPivot service application was crashing regularly at a specific time (within a minute or two) every day.

Today I discovered an interesting issue with the new SharePoint Modern Library views on Office 365. One of my clients for whom I had built an application that loads some content within an iframe element on the site was suddenly no longer able to get the Modern Library pages to render correctly – they would simply show up as a blank page.

I just saw this post on the SharePoint forums: http://social.msdn.microsoft.com/Forums/en-US/sharepointgeneral/thread/e9cd9836-5a50-42b3-bf2f-02338a3168f3 – it appears that there’s a possibility for data corruption when using the STSADM mergecontentdb command. The post details a few things you can do to reduce the possibility of corruption when using the command but it would appear that the hidden message is to use Backup/Restore until a fix is released.

Todd Carter just published an interesting post about when to use, and more appropriately, not use the preparetomove command: http://blogs.msdn.com/toddca/archive/2009/01/30/preparetomove-away-from-running-this-command.aspx. Essentially if you have at least the Infrastructure Update (IU) installed then using this command will cause you issues.

If you’re configuring a Windows Server 2008 environment with SharePoint 2007 and are planning on using Kerberos make sure that you do NOT set the default impersonation level for the server to delegate as recommended in this support article: http://support.

I’ve recently done a lot of work with my current client to get SharePoint variations working and as a result I’ve learned that you need to be very patient and persistent and keep a full bottle of Excedrin nearby.

I got an interesting email the other day from Chakir Said regarding a bug that he encountered with SharePoint. He mis-typed the folder path for the web application and unfortunately the UI page has no validation to make sure that a valid path was specified.

I found what I believe to be a bug and figured I’d pass along my findings. If you’re working with the SPLimitedWebPartManager object and call Dispose() on it there’s a minor problem – the Dispose() method does not dispose of the SPWeb object that gets loaded up – if you’re only using one instance this isn’t much of a problem but if you’re doing a lot of looping then you’ll eventually run out of memory on the server.