eMusing

Any farm administrator will eventually feel the need to restructure when they watch in horrid fascination as their once insignficant sub sites grow to monster sites. Current MOSS limitations such as the 15GB limit for the stsadm import/export operations mean that unless you're using a terrifically expesnive 3rd party migration app you need to act fast before things get out of hand. The obvious solution would be to export the site(s) in question and then reimport them to an empty site collection. Yes, that would seem obvious, but it's not quite as straioghtforward as you might assume. What really compounds the matter is if you happen to have enabled the publishing feature on your source site. After many days of disappointment and incoherent error messages I finally returned to Gary Lapointe's brilliant blog - SharePoint Automation. Gary has developed dozens of custom stsadm commands in order to fill the cavernous and aching void left by the default offerings. One thread in particular, Subsite to Site Collection, deals with this pesky issue and also includes his own hair-pulling frustration with the out-of-the-box limitations to achieve this. BTW, the solutions he provides are not strictly supported - but they work where nothing else will and are very easy to use. In my case I simply deleted every failed test and started from scracth using the gl-convertsubsitetositecollection operation. All I had to do was provide the source site and destination URL and the command did the rest. stsadm -o gl-convertsubsitetositecollection -sourceurl http://mydomain.com/source -targeturl http://mydomain/destination -nofilecompression -owneremail me@home.com -ownerlogin "mydomain\me" -nositetemplate This exports the source site, creates the destination site collection and site (based on source site template), and activates any features. The source site was a Team Site with publsihing and several custom features enabled. The only thing I did was create the managed path but this command even has a flag for that! The only thing it doesn't appear to do (yet) is allow you to specify a new content database. I've already put my request in for this and hope to see it soon. If this helps someone, please thank Gary - not me! :)

Labels: MOSS, Site Collections

It happens when you restore WCM (publishing) sites to another location. The Page Layout source URL is not updated to reflect the new location.

There are several painful options I tried before finally coming across this solution:

http://stsadm.blogspot.com/2007/08/fix-publishing-pages-page-layout-url.html

There’s also a standalone executable and source code available here (the script often requires tweaking and recompiling to work, so having the source is a terrific help):

http://blog.thekid.me.uk/archive/2007/08/20/fixing-page-layout-urls-after-importing-a-publishing-site-in-sharepoint.aspx

One or the other usually provides the fix required.

UPDATE

if you're still having problems, there are a few things to watch for.

• Firstly, checkout-out pages (and quite possibly drafts) will not be affected by these commands, so make sure you approve and check in all pages first.
• If you're still getting the mysterious 'Unknown User' error on some pages chances are that the person who originally created your master/layout pages (or even site template!) no longer exists in the current site/collection. In this case you will have to temporarily add that user back, run the command again, and hopefully all will be good.

Good luck and please add a comment if you've found anything else or are still having problems.

Labels: Backup and Restore, MOSS, SharePoint 2007

Nowhere on any Microsoft website will you find a clear and complete guide on what is obviously one of the most fundamental and critical aspects of any system – disaster recovery.

In order to save others much pain and suffering I have outlined my lessons learnt below:

• It really, really helps if the environments you are working between match as closely as possible.
  • This includes - but is by no means limited to - ensuring that the root site is of the same type in both locations.
• Farm-level backup does not include the following:
  • Items in the Global Assembly Cache (any custom DLLs)
  • Web config files
  • IIS web app settings
  • Customisations and some elements in the 12 hive

These items should be backed up separately and applied to the new location first.

The following is an approach to migrating a farm (single- or multi-server) from one environment to the other. It is provided here free of charge and should be used as a guide only. I have attempted to list and present these items in some form of chronological order but no doubt everyone's needs and tastes here will differ.

1. Web Apps
   • Recreate these on the destination server(s) first. You don’t want to copy anything here because these would usually be using different host headers, URLs etc.
2. Custom DLLs in GAC
   • These can just be copied across. I keep a separate folder of all custom DLLs on another box (dev) and just copy these to C:\Windows\assembly on the target server(s) – all WFE (web front ends).
   • These also need to be registered as Safe Controls in your web.config.
   • You can usually determine what your custom items are from the web.config files.
3. 12 Hive
   • It’s quite possible that developers have made changes here. Usually they add any custom logos, images and page copies in here.
   • The good news is that the 12 hive from one default installation to the next is identical.
   • Modifications will usually have been restricted to the TEMPLATE folder so you can start by just copying that.
4. Web.config(s)
   • You will have a web.config file for each web app on each WFE. Ignore the confusing existence of web.config files in the 12 hive CONFIG directory. These don’t appear to get used at all.
   • What no one bothers telling you is WHICH web.config file(s) need to be changed! There are dozens and it’s bluddy confusing. The ones you actually need to affect changes in are again on the WFEs only, within the relevant IIS folder – e.g. C:\Inetpub\wwwroot\wss\VirtualDirectories\www.yourwebapp.com80
   • Easiest method is to copy an existing one to the new location. Make a copy of the destination file first.
   • If you have a diff tool (there are dozens but I like the one that ships free with TortoiseSVN) you can compare them to see the differences for yourself.

There you have it. Four fairly simple steps (once you know what you need!).

Once all that is in place you should be able to do a Farm or site collection restore on the server and hopefully everything will just work for you. In our case we also had to reconfigure the following because MOSS seems to use hard-coded site roots in some areas:

• Content Query Web Parts (and others based on it) – sometimes but not in all cases these need to be reconfigured
• Send To links – this field only accepts an absolute URL so any values you’ve applied here need updating
• Publishing Layout Pages – inheritance paths for these sometimes still point to the old server.
  • You can check this by trying to edit the Page Settings for any publishing page.
  • If you get an error then you are affected by this bug. It can be resolved using one of two methods described in another blog entitled Page Settings: Bad Paths - MOSS Restore Issues continued.

Once you’ve got the new environment up and running then using Content Deployment seems to be the easiest way to get new content across. The main issue I ran into here was that we wanted to use the same GUIDs but Content Deployment doesn’t like this.

Seems pretty strange when you consider that any custom solution, workflow, site definition etc., all use GUIDs natively to determine what content is being referenced!

Labels: Backup and Restore, MOSS, SharePoint 2007

What bugs me most about SharePoint is that there is almost always an application ASPX page that can provide exactly the functionality you're looking for.

Take Web Part pages for example, they have their own maintenance page but the only time you'll ever get to see the link for it is when one or more web parts on a page is causing problems. When this happens you get the usual generic error message we've all come to know and love, and a link to the holy Web Part Maintenance Page.

But what about when there is no error and you just want to manage the web parts for a given page - Close, Reset or Delete one or more? Fear not. Like many hard learnt solutions in MOSS, simply knowing what ASPX page to call (and with what parameters).

Simply add /_layouts/spcontnt.aspx?&url=[url] after your domain/server root with the appropriate path to the page you want to manage.

e.g. http://mysite/_layouts/spcontnt.aspx?&url=/subsite/Pages/mypage.aspx

Happy managing!

Labels: MOSS, SharePoint 2007, Web Parts

People seem to get so needlessly confused by this topic. I blame most of it on the lack of any reliable definitions.

Many articles discuss the use of InfoPath for this purpose - indeed even the option in the SharePoint UI for creating a custom template launches InfoPath! But unless your customisations extend to things that cannot be achieved OOTB it's actually so much simpler than that.

There are two fundamental pieces of information which can help explain all this and save you from a world of pain.

1. Your customisations to the Document Information panel found in the big-3 Office apps are made in SharePoint - not the target application.
2. The Document Information panel presented in documents created from a SharePoint library are nothing more than the fields defined in your content types (or an InfoPath form if you opted for this route).

If you're lucky enough to have InfoPath and feel like introducing more complexity then you can create a custom form to manage field validation and other advanced functionality.

For the rest of us, try the following:

1. Add a custom column or two to one of your Document content types.
2. Add the content type to a Document Library.
3. Click the New tab to open a new document (Word by default) and view the Document Information Panel. (Office Button -> Prepare -> Properties. You can also set this to open automatically in your content type settings under Document Information Panel settings .)

You should see all your custom columns. Columns marked with a red asterisk (*) represent mandatory fields. Yes, it's that easy.

Labels: Content Types, MOSS, SharePoint

This seems to be a topic that stumps even the most highly paid SharePoint experts but needn't. After all, the MOSS UI offers everything most enterprises would need, it's just a case of knowing where to look and exercising some not-so-common-sense.

Despite being called MOSS 2007, the base document content types actually use the old Office file formats. Confused? Yep, this is where most people get tripped up. The easiest way to replace these is to create a new document in each of Word, PowerPoint and Excel and upload them for each relevant content type under Advanced Settings -> Document Template.

This will provide you with a good base for any future content types that inherit from these.

DON'T save them as templates, as one might expect. Just as plain .docx, .pptx and .xlsx files. This is another common mistake.

These files will automatically get copied to the content type and every existing and new library to which it has been applied. If you're really curious you can verify this by looking in the hidden Forms folder within any library using the content type.

Labels: Content Types, MOSS, SharePoint

Despite the lack of a setting in the Site settings interface it can be done. It's been documented quasi-officially here and elsewhere but it's actually far simpler than most people make out. Instead of going to all the trouble of disabling and re-enabling the publishing feature, just navigate to the site you want to create the template from and append the following to the end of the URL: /_layouts/savetmpl.aspx Apart from saving time, the benefit of this is that your template will already have publishing features enabled.

Labels: MOSS, Publishing, SharePoint, Site Templates

As if anyone needed another reason to hate the 'great undocumented' within MOSS 2007. Who would have thought that something as simple as renaming the Title column (for re-use within a custom content type) could cause so much woe. I'm not going to go into the plethora reasons why this is bad. Neither will I comment on Microsoft's official explanation that this is by design. [Yeah right!] I'm just going to say DON'T DO IT, m'kay? However, in the event that you already have, there's a simple block of code you can run which will fix the problem. At least it did for us. You may find similar code posted elsewhere. The one difference to note here is the last line. A small but crucial addition that will push the changes through to all content types, lists and libraries that use this column.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;

namespace RenameSiteCol
{
   class Program
   {
       static void Main(string[] args)
       {
           if (args.Length <>  ");
               return;
           }

           SPSite site = new SPSite(args[0]);
           SPField f = site.RootWeb.Fields.GetFieldByInternalName(args[1]);
           f.Title = args[2];
           f.Update(true);
       }
   }
}

Labels: MOSS, SharePoint 2007, Site Columns