Part 3 of How I Successfully Upgraded eBay – Previous Blog Post
So what does it mean for you to "retire" an older web application for branding purposes? It is a simple change in Central Administration, but a nasty proposition when it comes to content in the site and most consultants will take the easy way out and say, no you can't do that (because they know how much work it is and don't really know what will break). What am I talking about? Let me give you an example:
- In 2007, the web application host header was http://abc.contoso.com
- In 2010, you want it to be http://xyz.contoso.com
- Moving a content database from one web applicaiton to another with a different name (for service delivery reasons)
- Moving a site collection from one content database to another content database in a different web application
Again, it is easy to do via Central Administration. It is easy to do the DNS and add an AAM, but did you think about content? Huh, what about the content…here's what you didn't think about:
- Non relative links used in 3rd Party applications (Corasworks)
- ASPX pages with non-relative links
- Content Editor web parts with non-relative links
- Update custom web part properties with non-relative links
- Navigation nodes with existing non-relative links
- Excel and InfoPath with Data Connections
The problem is non-relative links. It was a big problem in 2007 and in most vendors products that they didn't check the URL of where the code was running and convert the saved content into relative links! This is a major pain in the ass! Now you will see in 2010 and in most vendor products, they have learned a VERY valuable lesson. ALWAYS USE RELATIVE LINKS!
How does one upgrade 10s of 1000s of pages, 1000s of content editor web parts and navigation nodes with the new URLs? You build a tool of course! The tool is simple in its requirements:
- Take an input file of old url to new url
- Update all aspx pages with the new links – CHECK
- Update Content Editor web parts with the new links – CHECK
- Update custom web parts with links – CHECK
- Update Navigation nodes with new links – CHECK
- Update….wait…how to you update Excel and InfoPath? – OH MY…(the topic of the next blog post)
The tool is easy to build, but add in 1000s of sites, 1000s of pages and web parts…you have some problems:
- It will take too long for it to update all your resources before the upgrade is finished. So what do you do to meet your upgrade window?
- You have external links that still point to these older urls
The problem has a simple solution. HttpModules. All you have to do is intercept the HTTP request and redirect to the proper place. How do you know where to redirect them? Same as the tool, use the input file for the tool. Create a SharePoint list that the HttpModule pulls from that will redirect the request to the proper place. Here is a coule of examples:
- Redirect http://abc to http://xyz
- Redirect http://abc/HelloWorld to http://def/HelloWorld
There is an issue here. You would have two entries in the configuration list:
In this case, the order of replacement matters. If the first entry is applied, they will incorrectly get redirected to http://xyz/HelloWorld. This is not the desired outcome. You must redirect in order of most specific first, then to the most generic. You must also be careful with generic entries. Suppose you have two web applications:
If you have the following in your configuration list:
You can expect that the requests to http://abc will be redirected properly, but the http://abcdef, will also get redirected and not the way you want. Also in the case of http://abc->http://abcdef, you would be in a continuous loop of adding http://abc to the redirect and of course, you will eventually overrun the address line in the browser!
Enjoy,
Chris