I see questions about redirecting users in SharePoint all the time. Usually they're in the context of "I want to redirect users, can I do this with an Alternate Access Mapping?" SharePoint admins know that if they don't set their AAMs up correctly that SharePoint will bounce their users around like a SuperBall, so they hope they can harness that power for good, instead of evil. While you can in certain circumstances most likely you will want to use a different approach. In this blog post I will show you several different to redirect users in SharePoint. Then when you find yourself needing to, you can use the method best suited for your situation.
When deciding which redirection method to employ, you need to determine what you're redirecting from and what you're redirecting to. That will determine which method to use. For each of the methods I discuss below I will provide examples of the situation you would use it in. Enough with the introduction, let's get down to it.
Vanity URLs
One of the most common requests I see is for vanity URLs. SharePoint URLs can get long and unmanageable and admins want URLs that their users can remember. They want to use something like http://software and have it forwarded to http://team/sites/software/development. To set expectations correctly, you should just come to terms with the fact that you aren't going to write SharePoint URLs down, you'll pass them along via or IM. If you do want short URLs you can have them forward to deep SharePoint sites. Of course the URL your users will eventually get to will be the long URL, but the jumping off point will be easy to remember. To do this kind of redirection I use IIS directly, I don't get SharePoint involved at all. Create a new virtual server in IIS Manager and give it a descriptive name like "Software Redirect." When you're walking through the wizard you'll take the defaults. You'll have to point it to a local directory. This is only temporary, so you can point it anywhere. After the virtual server is created, edit the properties. Open the "Home Directory" tab and click "A redirection to a URL" then type your SharePoint URL in the "Redirect to:" box. It should look like this:
Figure 1 – Redirection settings
This method works pretty well and is easy for users. It does have a couple of drawbacks you should know about. Each virtual server running takes up RAM on your IIS server. You can take steps to mitigate this. I create a new App Pool and use it strictly for the redirect virtual servers. Then I set that App Pool to timeout if idle for 1 minute. Since this App Pool does not really do much, it does not use much RAM, but this reduces that memory footprint liability to only a minute or two on your web server each time someone uses the redirect. In my experience the App Pool only used 5 or 10 MB of RAM each time someone hit it. With today's machines that's not much of a hit. Overall I've been very happy with this approach.
Figure 2 - App Pool memory settings
Server URL has changed and users have bookmarks
This can happen from time to time, a server name changes or you move your site from HTTP to HTTPS. If your users have bookmarks to the old URLs this can cause problems. One option is to tell your users they're out of luck, but this is a great opportunity to look like a SharePoint Hero. You may be able to use AAMs to work this type of redirection, but they don't work consistently. For instance, the AAM will redirect a URL without a page, but will not redirect one that does. So http://oldserver would redirect but http://oldserver/default.aspx would not. Because most bookmarks will have the page included we can't rely on this. To handle this I employ a technique similar to how I handle Vanity URLs. First you'll need to make sure your existing SharePoint virtual server no longer responds to the old URL. Normally I just change the port to an used port like 8080, so that it's easy to change back. Next create a new virtual server and make sure it responds to the old URL, so you may need to add a host header or adjust the port. Like above, after you've created the redirect virtual server edit its Home Directory property. Instead of feeding it a static URL we're going to employ some redirect variables. Before I explain them, here's what your redirect URL will look like:
Figure 3 - Redirection variables
Two changes should jump out at you. First, the URL ends in $V$Q. The $V represents the original URL the user is trying to access, but without the protocol, servername or parameters. The $Q represents any parameters the URL included. Here's a crude drawing of how the URL breaks down:
Figure 4 - URL breakdown
Since all we want from the old URL is the path and the parameters, $V$Q works well for us. You can find a list of all the supported redirection parameters here. You'll also want to check the "A permanent redirection for this resource." This gives the client back an http 301 reponse which tells it the redirect is permanent. Some clients can understand this and will fix the Bookmark to the new URL. Other clients can't understand 300 level responses at all and will fail completely regardless. Full documentation on this switch and the rest can be found in the IIS Manager help. Once the screen is up you can hit F1 to open the help. After you have this all configured any requests this virtual server handles will be forwarded with path and parameters to the URL you specified.
Redirect from Deep URL
Sometimes you aren't redirecting an entire URL, or even just the servername. Sometimes you're just moving a web and you want users to be redirected to the new location. Since you don't want to redirect the entire web application you can't use either of the previous techniques. Fortunately there is a way. There is much magic in the Content Editor Web Part (CEWP) and this is another example. You can use a CEWP to insert HTML code to send your users wherever you want them. To utilize it add a CEWP to your web part page, usually the default.aspx at the root of your web. Edit the web part properties. Click Source Editor and add a Meta Refresh tag to send your users to the new site. It will look like this:
Figure 5 - CEWP Properties
The "10" in the content tag means the page wait 10 seconds before it refreshes. A longer time is handy if you want to put a message alerting your users to the new location before you forward them. The URL is the URL your users will be sent to. Of course this will only work on the page you put it on, so you may need place it on multiple pages in your web, like your Shared Document library pages. Fortunately since it is just a web part you can export it and import on additional pages, you don't need to recreate it each time.
There are some drawbacks to this approach, and it's generally considered bad form to use a refresh tag to forward users. For one it breaks your users' Back button in their browsers. It can also confuse your users, especially if the redirect is fast and there isn't a note on the page explaining that the site has moved. Finally, make very sure the URL you're redirecting them to is valid. If not they get stuck on a dead page and no way to use Back to get out. Sometimes it is your only option though.
This blog post wouldn't be complete without a mention of MOSS' Redirect Page content type. If you're using MOSS and you're on a Publishing Site you can access to it. Go to your Pages document library and Click new. It will be in your list.
Figure 6 - Redirect Page content type
Once the Redirect Page is created you'll need to Edit its Properties and enter the URL you want it to redirect to. You'll also need to preview the page and check it in before it will work. Unfortunately this solution only works on Publishing sites.
As you can see, SharePoint and IIS provide many ways to redirect users. Each method has its benefits and drawbacks. Hopefully this blog post will provide you with one method that will work for your situation.
tk