Pages

Monday, June 29, 2009

Warning of Missing Template SBSBWEB#0 [SPS 2003 to MOSS 2007 Migration]

Issue Background

I been performing many Gradual Upgrades in the past year. One issue I noticed during several Portal Site Collection upgrades was that you will see an [WARNING] in your Upgrade log following:

[SPWebTemplateSequence] [WARNING] [---Date and Time ---]Template SPSBWEB#0: Failed to find onet.xml for 'SPSBWEB#0' template: tried 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\SiteTemplates\SPSBWEB\xml\onet.xml'.

[SPWebTemplateSequence] [WARNING] [---Date and Time ---]: Template SPSBWEB#0: Failed to determine the target template version for the 'SPSBWEB#0' template, assuming '0.0.0.0'.

Or

[SPManager] [DEBUG] [---Date and Time ---]: NeedsUpgrade [SharePoint Portal Server BucketWeb Template - %LCID%1033 - %GTID%_GLOBAL_#35 - %TMPLID%SPSBWEB#0 Bucket Template.] returned: False.

[SPManager] [DEBUG] [---Date and Time ---]: Skip upgrading [SharePoint Portal Server BucketWeb Template - %LCID%1033 - %GTID%_GLOBAL_#35 - %TMPLID%SPSBWEB#0Bucket Template.

Further you will also notice in the Upgrade Log status that this issue will be counted towards only Warning and Upgrade Status is Successful if there were no other issues encountered.

Issue Analysis

The SPSBWEB#0 is a site definition template for the “Bucket Web” (The /Cx URL addressed based webs particular to SharePoint 2003 Portal Site collection. See my other posting on Bucket Web related posting). In the upgrade scenario the Upgrade Job is looking for the corresponding site definition from the MOSS binary install. From the Upgrade Log, it appears that the folder “SPSBWEB” is missing from 12 hive Site Templates location.

After my investigation it turns out that among several MOSS 2007 installations I have to do in a Gradual Upgrade Mode (with SP2 and post SP hot fixes but before SP3) ranging from Single Server to Large Scale, it appears that the “SPSBWEB” template does not see to have made it to the 12 hive site template folder. I made sure my install source was good and it is. I have also tried both 32x and 64x different sources of installations and they all seem to result with this missing template when installed in a

Solution

From one of my old MOSS 2007 single server installed Virtual Machine, I was able to grab the SPSBWEB template folder. ( I don’t quite have recollection of which version this was, if I come across the source I will update this post…) Now go ahead the deploy the original SPSBWEB to your Gradual Update Front End Web Server 12 hive Site Templates folder (You don’t have to update any WebTemps*.xml file, since this is only meant for your Upgrade Job to pick up). Restart IIS and retry your Upgrade Job. This should take care of your Upgrade Job Warning.

Click below to download the SPSBWEB template folder from my SkyDrive.

Friday, June 26, 2009

For Portal Site Collection upgrade, Quick Launch Settings will not retain the settings after upgrade[SPS 2003 to MOSS 2007 Migration]

Issue Background

Under the SharePoint 2003 Portal Site Collection, if you were to navigate to any documents and lists settings>Change General Settings, you will notice there is a setting called “Quick Launch” settings. Well, out of the box, there is equivalent Quick Launch area like in a WSS V2.0 Site, that can show or hide the link to Lists and Libraries. So this settings is really not relevant in Portal Site Collection.

When you upgrade a SharePoint 2003 Portal Site Collection, no matter which settings your lists and libraries had their Quick Launch setting set to, after the upgrade, the setting will be reset to No for the Upgraded content.

Issue Analysis/ Solution.

Now, in V3, the Quick Launch Setting has same behavior as WSS, as expected to start showing the selected lists and libraries in the Quick Launch Bar.

This settings becomes relevant only if you had any customizations or custom solutions dependent, then this issue is a concern for you.

If you are dependent on this settings, there is no out of the box solution to make the settings propagate automatically. If you have only few areas with few libraries then you might as well set the designed settings manually for the upgraded content. Otherwise for large libraries and lists and/or large number of areas this issues becomes very cumber some to manual process. You will have to write a custom code to propagate the V2 settings to V3. (remember your V2 content is still intact with all the settings. Upgrade job will not change your V2 data in any way)

Apologies for lack of screen shot, when I get my lap up and running I will post back some relevant screen shots.

“New URL for Original Content” setting.[SPS 2003 to MOSS 2007 Migration] (Gradual Upgrade)

Issue Background

If you were are planning for a Gradual Upgrade, as the Upgrade path is dictated you are trying to upgrade the V2 site collections in a side by side environment one or more site collections at a time. You first start by going in to the MOSS Central Administration screen and from the Operations>Set content upgrade status.

image

This will take you to the list of all the V2 Virtual Servers, that can be upgraded. Go ahead the choose your V2 Virtual server from the list to Beginning Setup for Upgrading. (Sorry, don’t have my let setup completely to show the real example screen shots, when I do, I will update with appropriate screen shots). Now you are prompted for “New URL for original content” to choose either a port number or a host header to host the old content.

Lets take moment for second and think about repercussions of doing so. The whole idea of Gradual Upgrade is that you can have the ability to gradually upgrade your site collection(s) one by one as the situation permits (depending on your permissible outage, size, SLA etc)> The Upgrade Job does that, but at the cost of switching your original content to a temporary address and serving the upgraded content with the original URL. At the same time if you were to access your old content that is still in V2 (Not upgraded), the new MOSS Web Application that is now configured to serve the upgraded content, will have a redirection implemented. Which will appropriately redirect based on the content request, such that for any request that points to a site collection that is not upgraded, you will be redirected to the “New URL for original content”. That means your URLs to the old original content is changed.

Now, if you have URL sensitive content such as XML forms, custom solutions based on the URL, you can imagine the changed URL can cause to the entire process.

Solution

One way to approach this issue is serving the Upgraded content with new URL, and retaining the original content with original URL. I call this “Flipping the URL”. How you implement this configuration is by “flipping the original URL” in your V2 virtual server just before you perform the “Begin Upgrade” setting in MOSS Central Administration which leads to the “Set Target Web Application” screen. Follow below steps:

  1. First determine your URL for serving the Upgraded Content. Weather a Host Header based or a Port number (I would think you have nice DNS name thought out, although you can use port numbers but not very elegant). Lets call this as “Upgraded URL”.
  2. If you are serving the original V2 content with either a host header or a port number, then lets update the settings in IIS manager for the IIS Site you are intend to Gradual Upgrade with the “Upgraded URL”. (If you have a farm with more than one front end server, then make sure to update on all the Front End Wed server IIS settings.)
  3. Now go back to V3 Central Administration>Operations>Site Content upgrade status> screen. You will notice that your “URL for previous version” (V2 Virtual Server) is now updated with the “Upgraded URL” you have updated in IIS.
  4. Now choose the “Begin upgrade”. On the Set Target Web Application screen”, for the “New URL for Original content”, based on weather you had port number or a DNS/Host Header, enter the original V2 address (original port number/host header).
  5. Follow through remaining entries (I might cover specifics on the remaining entries on another posting). Click on ok to affect the new settings.
  6. Once the settings are completed (Head attention to weather you will need to perform an IISRESET /noforce )
  7. Now go back to IIS Manager and look for the Port/Host header settings under the original V2 Web Site as well as the new web site the MOSS has created for your with “_Pair” suffix.
  8. You will notice that the change you had temporarily made to the IIS Site that was serving the original content is now set up back with the original Port/Host Header, and that the “_Pair” web application is assigned with new “Upgraded URL”

Hope this posting helps you think through your Gradual Upgrade serving URL. Let me know if you had any difficulty is setting this.

Wednesday, June 24, 2009

Library/List names conflicts with MOSS Publishing Infrastructure related Library/List names (SPS 2003 to MOSS 2007 Migration)[Portal Site collection]

Issue Background

When you Upgrade a SPS 2003 Portal Site Collection, MOSS 2007 will upgrade the Site Collection with MOSS Collaborations Portal Site Template. The Collaboration Portal Site will by default being the Publishing type portal, will have the Office SharePoint Server Publishing feature enabled.

image

Based on the above feature description, the Publishing feature will pre-create below document libraries to support the Publishing Infrastructure.

clip_image002

Analysis

If a SPS 2003 Portal Area contains a Document library or List names same as one of the above name, then upon an upgrade you there would think that there would be a name conflict. Instead what the Upgrade Job does is append a numerical count to the name of the coming Lists and Libraries with conflicting names. The names get renamed such as (V2) Documents->(Upgraded to)Documents0 (Zero) , and so on.

So plan on reporting on your V2 library names that may fall under the Publishing related list names. Do not rename the Publishing lib/list names as the Publishing features work for the default names only.

Monday, June 22, 2009

Error upgrading Site Directory [SPS 2003 to MOSS 2007 Migration]

Issue Background

When you are upgrade a SharePoint 2003 Portal site collection, if you have a sub area that is based on Site Directory template (SPSSITES#0) you might receive an Upgrade Log [WARNING] and an [ERROR] as below:

[SPWebTemplateSequence] [DEBUG] [—date time--]: Template SPSSITES#0: Activating feature a311bf68-c990-4da3-89b3-88989a3d7721 in site with URL "your site dir url", force=False.

[SPWebTemplateSequence] [ERROR] [—date time--]: Template SPSSITES#0: Exception occurred in activating features in site with URL "your site dir url" (SPWeb Id=Your Web GUID, SPSite Id=Your Site Collection GUID). Skipping this site for template upgrade.

Solution

This issue will occur if your site directory’s “Sites” has “Content Approval” turned off. If so enable Content Approval “Sites” list then run the Upgrade Job.

Files/Folder Names Exceeding 260 URL Length [SPS 2003 to MOSS 2007 Migration]

Issue Background

In SharePoint (V2 and V3) you cannot create or have a file name or a folder name and combination of folder and file name (128 characters max) that cannot exceed 260 characters in length in the final resulting URL. Read following Microsoft KB Article for more details http://support.microsoft.com/kb/894630. So based on this you not be able to upload or create fine file/folder under the SharePoint Portal or WSS that would result with an item that exceeds 260 characters in length.

Now, lets look at the Upgrade scenario for SharePoint 2003 based Portal Site Collection. In V2 Portal the Area address are based on the “bucket web” concepts (Go hear for understanding what SPS 2003 did for Web address https://blogs.msdn.com/danielmcpherson/archive/2005/05/18/419160.aspx). When you upgrade a Portal Site Collection to MOSS 2007, the site collection will be upgraded to the “Collaboration Portal” Site Template. What the Upgrade process does is it removes the “bucket web” address nodes and maps each sub webs with the existing web URLs hierarchically. See below table:

Area Path->AddressMOSS Sub Web Address
Home->//
Home: Sub Area 1->/C1/SubArea1/SubArea1
Home: Sub Area 1: Sub Area 2 ->/C2/SubArea2/SubArea1/SubArea2
Home: Sub Area 1: Sub Area 2 :Sub Area 3 ->/C3/SubArea3/SubArea1/SubArea2/SubArea3

For each such webs where the bucket web addresses are changed the Upgrade process will also add a redirector to address the breaking URL. But I will cover this topic with an issue this change introduces in a separate blog. (Refer to http://cregan.wordpress.com/2007/11/16/sharepoint-gradual-upgrade-random-page-error-this-page-is-redirecting/ for more details)

Now what above URL change introduces is the folder and/or documents URLs that were close to exceeding 260 characters in length will start hitting the 260 URL limit threshold as some of the inner sub webs URL is now extended by prefixing with the parent web URL.

If you guessed it, when you upgrade SharePoint 2003 Portal Site Collection (May not apply for WSS 2.0 Site Collection as there are no bucket webs and the URL schema remains same), your Upgrade.Log will report following error:

[PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [----date time---]: Trying to move Area "Sub Area 1: Sub Area 2" from "/C2/SubArea2" to "/SubArea1/SubArea2"...

[PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [-----date time-----]: Could not move web due to the following error, trying to move it to the unmovable web holding area instead. Microsoft.SharePoint.SPException: The specified file or folder name is too long. The URL path for all files and folders must be 260 characters or less (and no more than 128 characters for any single file or folder name in the URL). Please type a shorter file or folder name.

and further you will also see the following error…

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [---date time---]: Instead of moving area to
"/SubArea1/SubArea2 ", upgrade has moved the area to "/z/SubArea2 " due to the above error. Please revisit this area and resolve any issue and manually move the area to the correct location.
[PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [----date time-----]: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

So the Upgrade Job has created a Sub Web called “Unmovable Webs” with the url “/z” under the root and moved the webs that are exceeding URLs. You will also observer the below log message at the beginning of the Upgrade.Log file. So why did Upgrade Job choose “/z”? So as to create shortest Web Path to accommodate webs that had hit the threshold.

[PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [---date time----]: Will use "z" as the web name of the unmovable webs holding area.

The Upgrade Job will move the web even if there is a single item that exceeds the 260 character URL limit.

Analysis Approach

You can follow below pointers to plan for addressing your Unmovable Webs:

  • Searching: Always plan for performing test upgrades before thinking about doing a production upgrade. After running test upgrades review your Upgrade.log file. Look for each instance of “<<<<<<<<<<<<" to find each of the Webs that has exceeded.
  • Target URL: Note each of the Web’s intended destination URL from the Upgrade Log, so that when you have addressed the items that are causing the exception, you can try move back the Web from Unmovable webs to the intended Web Location (You can do this from “Content and Structure” feature of Publishing Site)
  • SQL Query: Now you must wondering how am I supposed to know which item(s) is/are causing this exception. Well, you can try derive a SQL script to run against your SharePoint 2003 Content database (<Portalname>_SITE DB). The V2 content DB will tell you as it is in the V2 state before the Upgrade, that given the state, for each documents and folders (which are stored under the “alldocs” table) and by appending the folder path and the document name and calculating the possible end URL length (remember your from your address, the server name or DNS will not count to words the 260 characters limit). Below is a sample SQL Script that you can try against the V2 _SITE DB. (Caution: Large databases and/or documents heavy sites may take more time to run the query. Always first try in the test environment and may be start with Top 10,100, 500 etc filter)

select top 100

SUM(len(dirname)+len(leafname)) as Total,

len(dirname) as DirLength,

dirname,

len(leafname) as LeafLength,

leafname

from alldocs with (NOLOCK)

where DeleteTransactionID = 0x

and IsCurrentVersion= 1

group by dirname, leafname

having cast(SUM(len(dirname)+len(leafname)) as int) > 260

order by total desc

Solution

Once you have the list of items that are causing the exception, you can plan on managing the items. You can try move the items to higher URL name space, rename the document and/or folder names. If you can perform rename/move management before the Upgrade Job is run, potentially you are letting the Web upgrade and be placed under the respective URL hierarchy. If you cannot then let the Upgrade Job complete, then manage the exceeding times and try moving through the Content and Structure screen. The move function will once again check to make sure the web is 260 URL limit safe based on where you are moving. Other wise the move will fail completely, leaving the web under the Unmovable webs location.

JavaScript Error in Content Editor Web part while entering text (MOSS 2007/WSS 3.0)

If your version of MOSS installation is below 12.0.0.6335 (December 16 2008 Hotfix), you might receive the following JavaScript error for every key stroke while you are trying to edit a Content Editor Web Part.

clip_image001

There are some blogs that suggest a possible fix by copying a LAYOUTS\1033\FORM.JS and LAYOUTS\1033\BFORM.JS from a working server. (http://blog.mastykarz.nl/javascript-error-while-entering-text-in-the-content-editor-web-part/ Thanks to Waldek Mastykarz for this great workaround) But the problem was I did not have a machine where this functionality was working.

But took the benefit of latest December 16th 2008 Hotfix for MOSS 2007 and WSS 3.0 and after installing the hotfix, the issue seems to be resolved.

Refer below link for the latest hotfixes.

http://blogs.msdn.com/josrod/archive/2008/12/17/latest-wss-and-moss-patches.aspx