Work around for deployment of MOSS site with variations

One way to deploy MOSS (or SharePoint) sites is via stsadm export/import. There are, however, a few known problems, for example items hidden in navigation reappear and the first time you deploy your custom master pages are not applied. Fixes are possible; manually re-hide the items, and deploying a second (or more) time resolves the master page issue.

(Aside: I suspect the master page issue is a dependency problem — during the deployment it tries to set the master page before it has been deployed, i.e. before it exists, and fails. The dependency is then resolved if you deploy again, as this time the master page does exist.)

However — running the deployment (stsadm -o import) twice causes issues if you have variations (multilingual) enabled for your site. We found this out the hard way trying to deploy a large multilingual site into our test environment. When you try to access the site after the second deployment, you get the following nasty error (you need to turn off friendly errors and enable debugging, etc to troubleshoot):

Source Error:
Line 47:         private string GetRedirectTargetUrl()
Line 48:         {
Line 49:             ReadOnlyCollection<VariationLabel> spawnedLabels = Variations.Current.UserAccessibleLabels;
Line 50:             if (spawnedLabels.Count > 0)
Line 51:             {

Source File: c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES\VariationsRootLanding.ascx    Line: 49

Stack Trace:
[NullReferenceException: Object reference not set to an instance of an object.]
   Microsoft.SharePoint.Publishing.Variations.InitializeUserAccessibleLabels() +199
   Microsoft.SharePoint.Publishing.Variations.get_UserAccessibleLabels() +33
   ASP._controltemplates_variationsrootlanding_ascx.GetRedirectTargetUrl() +44
   ASP._controltemplates_variationsrootlanding_ascx.OnLoad(EventArgs e) +18
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Control.LoadRecursive() +131
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061

Even worse, some of the administration pages also break, for example trying to access /_Layouts/sitemanager.aspx results in the following error:

Object reference not set to an instance of an object.   at Microsoft.SharePoint.Publishing.Internal.VariationsPublishingOperationValidator.EstablishLabels()
   at Microsoft.SharePoint.Publishing.Internal.VariationsPublishingOperationValidator.Examine()
   at Microsoft.SharePoint.Publishing.Internal.WebControls.SmtWebEcbMenu.<>c__DisplayClass5.<setupTypeSpecificMenu>b__0()

The site itself should work if you manually go direct to one of the individual language sites, e.g. /en (or whatever your variations are). You can also still access /_layouts/settings.aspx, and if you look at the variation labels setup you will see that all of the variations are appearing twice!

If you deploy a third time, say a new build from the development team, then you will find that all the variation labels are now appearing three times!

The problem has been communicated to Microsoft, and they are working on a hotfix, but in the meanwhile poking around in the SharePoint content database we came up with the following SQL workaround.

Note: This is not complete; you will need to execute each statement and update the GUIDs into the next. It’s safer to check it as you go rather than just start deleting parts of your database.

— Select the target content database
use xxxxxxxx

— Get Id of top level web
select top 100 Id, *
from Webs
where ParentWebId is null

— Get tp_ID of the ‘Variation Labels’ list for that web
select top 100 tp_ID, *
from AllLists
where tp_WebId = ‘[Id of top level web]’
and tp_Title = ‘Variation Labels’

— Check the data items in that list.
select top 100 *
from AllUserData
where tp_ListId = ‘[tp_ID of variation labels list]’

— Remove the duplicate labels (created after first import)
select * — delete
from AllUserData
where tp_ListId = ‘[tp_ID of variation labels list]’
and tp_Created > ‘[some date/time after first deployment]’

After you figure out the GUIDs, just run the delete after every time you do a deployment (presuming you haven’t added any new items).


A while later we discovered also that there were similar problems with duplicate cache profiles and content reports. The extra items can be deleted, but the report filters still don’t seem to work. The investigations are continuing, but at least we can deploy now.

To see the other duplications after import, use the following SQL:

— The same applies to caching and reporting setup
select *
from AllUserData
where tp_ListId in
  select tp_ID
  from AllLists
  where tp_WebId = ‘[Id of top level web]’
  and (tp_Title = ‘Cache Profiles’
       or tp_Title = ‘Content and Structure Reports’)

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: