ITRants.net

OK! I’ve been out for two weeks recovering from herniated disk surgery and maybe just maybe the pain medications have enlightened me to SharePoint’s purpose. I’ve been dreaming about content deployment troubleshooting along with a myriad of generic usage issues that culminated with me digging under SharePoint’s covers. There it is!! SharePoint simply is a database!!!!! Wow, I really was confused for awhile just concentrating on getting Web Content Management (WCM) working.

What’ so great about using this reference of SharePoint’s purpose in understanding and utilizing this platform of all platforms for delivering IT Solutions? Well, with what Microsoft has coded as a base functionality set is just the beginnings of just about any application you can think of. The only limitation is ripping the covers off and actually approaching SharePoint as a platform.

Cool. Now that I have that off my chest I can sleep for a couple of hours and dream about the content deployment troubleshooting my day is going to be filled with. It should be fun.

I have to give a huge thanks to Chris O’Brien for his content deployment wizard. You can get this life saving tool from his site at http://snipr.com/mossdeploymentwizard

Wow!! This is the tool you can’t live without especially if you are uitilizing a publishing environment for your destination content deployments. I had to use his tool to move a 9GB publishing site from the authoring farm due to content deployment failures. His tool allows you to maintain the GUID’s which is essential for successful content deployments to the publishing farm.

We are waiting for SP3 to see whether Microsoft will really get content deployment bugs manageable or we will go down the route Chris went and create our own deployment engine using the api.

This is going to be fun.  I’ll start with the latest and start working my way back through a long list of failures. Some I have fixes for and some I have workarounds for while others are a mystery.

Latest: “can’t fetch an item that has been previously fetched by another user”

Cause: We had changed the default home page assignment for a site to another page that was unpublished.

Fix: We put the home page for the site back to the previously published page.  I’ve had similar failures around renaming the default home page that resulted in us having to delete the site and recreate in another location.  I don’t think this is one of those scenarios but wasn’t willing to break anything else today.

I will update you on what happens when the new page gets published and assigned as the new default home page.  

I’ll have to dig through my deployment failure notes to confirm the error we were getting when renaming the default home page.

Sweet! Running two load balanced web front-end servers with 64-bit 2003 Server and 64-bit MOSS. They have dual quad-core processors with 8GB of RAM and one pukes! We saw the available memory go from 6GB to 1GB and the dreaded “Server too busy” page displayed for the unfortunate connections on that server. I stopped IIS and restarted without any luck. Luckily the server reboots in under 2 minutes and we are OK. I see nothing in the app log, IIS log, or system log that is any different than the server that had no problems.

Has anyone run into this before?

This is the latest Errors clogging the application logs on the MOSS servers. The error looks like the following:

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Publishing Cache
Event ID: 5785
Date: 3/7/2008
Time: 10:07:17 PM
User: N/A
Computer: Server
Description:
Unable to connect publishing custom string handler for output caching.

I’ve seen the following solutions posted on other sites.
1. This error was resolved by removing the PublishingHttpModule from the ReportServer and Reports sub-sites of my MOSS site.

2. “Looks like it was the Metalogix Team Migration extensions. No errors since uninstall.”

My Plan:

Well we did use the Metalogix extensions but really have no option to uninstall them. I’m hesitant to remove publishing but will probably give it a go if I can’t attribute the errors to the MetaLogix extensions during some after-hours testing. I don’t think these errors are really causing an issue with functionality other than filling the app log. Anyone have other ideas or info on the impact of these event id’s?

I’ll update you in a few days when I figure it out on our install.