So I’ve been moving my web sites all around, completely changing the hierarchy, creating new site collections, etc., and I discovered that whenever I hit a link that still pointed to an old bucket web (http://intranet/c16/ebusiness instead of http://intranet/topics/divisions/ebusiness) it loaded up a page called spsredirect.aspx which was supposed to redirect me to the new, correct link.
Unfortunately because I’ve moved things around the page was returning a 404. After disassembling the spsredirect page (Microsoft.SharePoint.Portal.WebControls.SPSRedirectPage) I found that what is happening is that the page is looking at a special hard-coded list that gets created when you are doing an upgrade. The list has a fixed name: "98d3057cd9024c27b2007643c1". Joel Oleson has a brief article which touches upon this list: http://blogs.msdn.com/joelo/archive/2007/03/17/areas-bucketwebs-upgrade-and-redirects.aspx. The list contains the old bucket web links and the new links. What I found was that if I updated the V3ServerRelativeUrl field I could now move my webs around (within the same web application – more on that in a bit) and then simply update the corresponding field entry in this list and now any old bucket web links will still work.
What’s irritating is that the spsredirect.aspx page expects all the URLs to be server relative so if you’re moving a web to a new web app then you’re out of luck (unless you create your own custom redirect page and then set the links to use that page and pass in the actual URL – that way spsredirect will redirect to your custom redirect page which will then redirect to the actual page – I decided to just limit my command to working with a single web app rather than try to deal with this scenario).
Of course changing the entries within here doesn’t actually fix the links, but it will enable you to move things around and have the old v2 links still redirect correctly. I’ve created this new command to handle changing the new V3 URL and I’ve also modified my gl-moveweb and gl-convertsubsitetositecollection commands to utilize this functionality as well so if you run either of those two commands it will attempt to fix the links in this list if it can. The core code to do all this is detailed below:
The command I created is detailed below (the name is really verbose but I couldn’t think of anything shorter that would be clear as to it’s intentions).
The command, gl-updatev2tov3upgradeareaurlmappings, is very straightforward – it expects the web application that the upgrade list resides on and the source and target URLs. Keep in mind that these URLsthough can be specified as absolute they will be converted to server relative and they must correspond to webs on the specified web application (note that I made the code sensitive enough so that you could specify a non-existent source or target in the event that you have already moved your site or are about to move it – it’s always better though if the target actually exists so that it can set the web ID properly).
The syntax of the command can be seen below:
C:\>stsadm -help gl-updatev2tov3upgradeareaurlmappings stsadm -o gl-updatev2tov3upgradeareaurlmappings Updates the server relative URL corresponding to the source URL to reflect the new target URL in the Upgrade Area URL Mappings list: "http://portal/Lists/98d3057cd9024c27b2007643c1/AllItems.aspx". All sites below the site are also updated. Parameters: -webapp <web application> -sourceurl <source V3 url (this is not the V2 bucket URL)> -targeturl <target V3 URL>
Here’s an example of how to change the redirect URL for a given web:
stsadm –o gl-updatev2tov3upgradeareaurlmappings -webapp "http://intranet/" -sourceurl "/topics/divisions/humanresources" -targeturl "/hr"