Sunday 11 November 2007

Change a SharePoint site's URL

Something you may find yourself tasked with at some point, is changing the URL of an existing SharePoint 2007 site. This is a fairly interesting scenario, and it's fair to say the relationship between SharePoint and IIS makes this more complex than for a standard .Net site. However, there are several possible solutions. The first things many of us would think of as potential approaches would probably be:

  • extending the web application onto another URL
  • using Alternate Access Mappings somehow

Depending on your site both could be valid methods, but as with anything SharePoint-related, there are different things to watch out for with the different approaches. As an example, extending the web application wasn't the right approach for our scenario for the following reasons:

  • the site shouldn't actually exist at the old URL, but a redirect was required
  • InfoPath forms don't seem to deal well with the 'extended web application' configuration. (Problem detail - on one URL everything will be fine, but if the two web applications use separate site collections, on the other you're likely to see security errors when opening forms. This is because the form templates are referenced in the other site collection - a document library can only have one URL to the document template, and publishing a form to a content type stores an absolute link in the content database.)

Additionally some quick tests with Alternate Access Mappings didn't seem to give the expected results for me, so I decided on another approach since I knew it would work and didn't have much time for experimentation. So this was my process:

Changing a site's URL by recreating the site (downtime required)

  1. Stop old IIS site.
  2. Create new web application in SharePoint, bind to new IP address in IIS.
  3. Apply SSL certificate if appropriate.
  4. Create new site collection for this web application using the blank site template.
  5. Export content using the SharePoint's content migration API (I have a tool which does this, which will shortly be on Codeplex) ensuring all security data is exported. Alternatives to this step include STSADM -O BACKUP and STSADM-O EXPORT. *
  6. Import content into the new site collection, ensuring to include security.
  7. Amend any absolute URLs in .udcx data connection files used by InfoPath.
  8. Republish any InfoPath forms to the new site.
  9. Configure search:
    1. Ensure new URL is a content source.
    2. Update any crawl rules which use absolute URLs.
    3. Update 'authoritative pages' as appropriate.
    4. Start full crawl.
    5. Update scopes.
    6. Go to Site Settings > Site collection administration > Search scopes, add any custom scopes to search dropdown (if using standard search web parts).
    7. Ensure search web parts use relative URLs/do not reference old site URLs.
  10. If a redirect from old URL is required, create new IIS site to implement this:
    1. Create new site in IIS and bind to old IP address.
    2. On 'Home directory' tab, specify content should come from 'A redirection to a URL' and enter the URL.
  11. Ensure DNS/firewalls are configured appropriately for new URL, remembering to allow appropriate time for DNS propagation.
  12. Perform testing.

* N.B. Between the content migration API and STSADM export, I prefer the former since this allows control over whether object GUIDs are retained (more information in STSADM export, Content Deployment, Content Migration API, Features/Solutions - deployment options compared). STSADM backup/restore is discussed in next section.

Considerations to this approach

  • When using the content migration API or STSADM backup/restore, the following items are not included - alerts, workflows, recycle bin state or site collection properties. These must be migrated/recreated separately.
  • Regression testing is absolutely required since the site is effectively recreated

As a way to improve on the first consideration, another option would be STSADM backup/restore (though I've not tried this approach). Notably this method does collect data for the items which the other approaches exclude, however due to the nature of our site, none of these were significant problems.

So this method was successful, and hopefully this information allows folks to see some of the pros and cons without having to spend the time going through it themselves. However, I also note an approach based on Alternate Access Mappings suggested by Faraz Khan. Since this was only published in the few days before this article it was too late for my scenario, though I'd encourage you to take a look. Note that Faraz also points out considerations such as certain links not being updated to new URL without fix-ups, though this doesn't seem to be a major issue. It does echo my point about there being different things to watch out for with the different approaches, but both methods provide valid techniques for changing a SharePoint site's URL.


Anonymous said...

Depending on your version of MOSS, and the necessary URL changes, such as if you are just adding to the URL at some part, perhaps it would be sufficient to enable publishing on the site collection and site level, then use the site content management explorer like windows (site actions) to do the following:

1. create a new site under the top site, like mycompanysite/HR
2. move the old subsite under the new subsite, if the old one was called HRportal , now it would become mycompanysite/HR/HRportal

In my case at least, I needed to extend by language specific URL in front of the actual subsite URL, like /en/

Chris O'Brien said...


Sorry for the delay in replying, I was on holiday when you posted.

Yes, your approach will work fine for changing the URL of a child web within a site collection will work fine.

My approach is really for changing the 'top-level' URL of a site.



Anonymous said...

Hi hopefully this is simple but how can i go about changing the case of URLS

I created a site as

And i really want it to look like

I really don't want to go through a export and restore for every site.

Chris O'Brien said...

Hi Michael,

Since you're not changing the 'top-level' URL of the site here it should simple - if the sites are MOSS publishing sites, you can do it by editing the settings on the 'Title, Description and Icon' page (/_layouts/prjsetng.aspx).

I'm not 100% sure for non-publishing sites, but imagine there's something similar.



jw5006 said...

I need a WSS3.0 web site to show in the URL

I have been searching for what I feel like is a year and not luck. Willing to pay for help.

Fereshteh said...

In our environment we have a Pages\default.aspx which is attached to a custome PageLayout. Our problem is that our pages doesnt refreshed on changing url.Does anyone have any idea?