Create a SharePoint Vanity-ish / Shortened URL and redirect to a site collection

Update!!!!! 1/26/2017
I was wrong. I found a much better way to redirect a user to a site collection actually using IIS URL Rewrite. The Managed Path shorten method below is still great, and if you don’t have the ability to use IIS URL Rewrite, then perhaps the script redirect method here will help, but if you have access to IIS URL Rewrite, check out my new post here. https://techrevmarrell.com/a-better-way-to-redirect-a-site-collection-in-sharepoint-using-iis-url-rewrite/

I’ve recently ran into a requirement where a user wanted basically a Vanity URL and use it for a SharePoint site. Not for SEO purposes, but because they wanted to make an easier url for users to remember how to get to a common site collection. Most of the time a SharePoint site collection that is not the root site will have a url such as http://Contoso.com/sites/teamA or worse if it’s a subsite, http://Contoso.com/sites/teama/wheredidmysubsitego. When what you may really want is a simple shorten url like http://contoso/HR.

My Requirement
In my requirement the page’s url was something like http://contoso.com/sites/videos/pages/helpfulvideos.aspx and they really wanted the user to type in something like http://contoso.com/videos, and get redirected to the actual page above.

So I needed 2 things.

1. A way to create a “Vanity-ish” URL in SharePoint. I say “Vanity-ish”, because it’s not truly ReWrite that you would use in SEO, where the appliance rewrites the original urls so any pages show up with the new url. This is a redirect pointing to a specific page. The URL in the browser would change to reflect the redirected URL. So I guess a better term instead of Vanity-ish, would be a shortened url. Similar to what you’d get with bit.ly or goo.gl .
2. A method to redirect a user
   1. This post shows how to use a script redirect in a Content Editor Web Part (CEWP)
   2. A better way is to redirect the user using IIS URL Redirect, check out my post here. https://techrevmarrell.com/a-better-way-to-redirect-a-site-collection-in-sharepoint-using-iis-url-rewrite/

Shortened Url:

Well unfortunately SharePoint is configured in such a way that after the root site collection in your web application you can have 1 root site collection. Basically it’s   “/”

So if my web application is http://contoso.com
You will have a root site collection at http://contoso.com”/” Now don’t get me wrong you do not have to put in contoso.com/ in order to get to your root site collection, SharePoint takes care of all that. But just know there is a root site collection there. As a matter of fact I’ve seen issues where SharePoint decided to go crazy go nuts because there was NOT A ROOT SITE COLLECTION in the web application. Trust me if there is a will there is a way.

Okay so 1 root site collection /. Then what do we get?

Well after that SharePoint organizes additional site collections in what it calls Paths.
By default you’ll get a /sites/ path and a /teams/ path. So something like http://contoso.com/sites and http://contoso.com/teams  these are called Wildcard Inclusions, or as we admins call them Wildcard Paths. (probably erroneously)

What a Wildcard Path does it allow you to have a site collection at http://contoso.com/sites/teama as well as http://contoso.com/teams/teama you can easily organize your site collections based on that path name. Etc.. Team sites /teams/ and other sites /sites/ maybe a community sites can be /communities/ and project sites are /projects/ etc…
but the thing to remember with a Wildcard Path, is you can’t have a root site sitting at http://contoso.com/projects or http://contoso.com/teams. Your site collections in the wildcard path would end up being something like http://contoso.com/projects/ProjectA or http://contoso.com/teams/HR

So let’s get back to our original issue, what if you want an easy to remember url like http://contoso.com/HR ? SharePoint will not let you create a site that way be default. So what can we do? Well there is another type of managed path called an explicit inclusion, or again as we admins probably erroneously call it an explicit path. If you look at the Managed Paths you already have in your web application, you’ll immediately see one called (root) and notice that it’s set as an Explicit Inclusion type of path.

So In our web app / is actually an explicit path.  SharePoint allows us to create other explicit paths. So supposed we do want a http://contoso.com/HR you can create an explicit managed path called HR. Once that has been added to the web application, you can then create a root site at that path level. (Note the site collection is not automatically created for you when you create a new managed path)

If you were using Central Admin to manually create a site collection, you’d now see the ability to select that managed path of HR and it creates the site collection as the root level. So /HR/ will actually get you to a root site.

Another thing to note. Since this is an explicit inclusion (path), once you create the root site collection at this path, you will see that you cannot create additional site collections at this same path. Now these are not to be confused with subsites, you can create those to your hearts content.

E.g. using the Explicit Inclusion

Okay so we’re good:

Explicit Inclusion Paths
Let us get a site collection at the root of another defined path name. Like /HR/ etc., but we can’t add other site collections to it, such as http://contoso.com/HR/SiteCollection2  (this could not be a site collection, SharePoint would allow it to be created as a subsite of the /HR/ site collection.)

Wildcard Inclusion Paths
Let us get a site collection underneath the defined path name. Like /teams/siteA, /teams/siteb. E.g. http://contoso.com/teams/siteA and http://contoso.com/teams/siteB. Again these can be separate site collections underneath the managed path. You could also create subsites under these site collections like http://contoso.com/teams/siteA/subsite1 or http://contoso.com/teams/siteB/subteam.

So which do I use? It depends on your situation. The majority of the sites you’d create OOB in SharePoint are going to in the Wildcard Path. Of course my requirement meant I should use the Explicit Inclusion Path.

Redirect a user:
So there are several tools you can use to redirect a user. The easiest is to have someone on your network team setup a redirect for you and you go enjoy a brisk cup of coffee. But well if everyone asked for network folks to create redirects for their applications, there would be millions of redirects on their system. Okay maybe not millions, but possibly thousands. Okay maybe not thousand, but I could for sure see hundreds in a busy enterprise environment, once words gets around that IT can redirect anything for you. Can you setup a redirect call http://contoso.com/lunch to display the lunch menu calendar at café A? etc.

You could also use IIS URL Rewrite, which has the ability to do a lot of cool redirects and rewrites based upon rules you can specify, but for reasons beyond this particular blog post, the type of redirect I was wanting is not supported by Microsoft. (America I was wrong! Check out my blog post that shows how to redirect with IIS URL Rewrite ) As a matter of fact in my testing I managed to create a pretty awesome redirect loop on one of my sites. So let’s just say that method was not ideal for my particular requirement. Here are some way’s to use URL re-write in SharePoint when working with different domain names. But there are changes to AAM’s, IIS, etc. and this was more configuration that I was willing to do for 1 redirect.  https://social.technet.microsoft.com/wiki/contents/articles/23074.sharepoint-2013-url-rewrite.aspx.

Since it was just 1 page I needed to redirect the user to, I decided to just use a really simple meta refresh redirect.
<meta http-equiv=”refresh” content=”0;url=http://contoso.com/sites/videos/pages/helpfulvideos.aspx”/>
Really very simple to use, the Content=”; is the number of secs you want it to wait before redirecting the user to the value in the url.

The plan was to just put this code into a CEWP on a web part page in the “shortened url” site collection. And sent the user to the actual page.

One thing I learned from experience is if you’re working with scripts and dropping them into CEWP’s, is throw that script into a text file. Upload that text file into a library on the site collection like Site Assets. Copy the url to the text file. Edit your CEWP and place the link url to the text file into the CEWP. DO NOT PUT YOUR CODE DIRECTLY INTO THE CEWP. Older versions of SharePoint sometimes had a habit of “cleaning up your code” for you, and causing other issues. Such as  <script type=”text/javascript”> becoming <script type=”&quot;text/javascript&quot;”> etc. Another advantage of putting your scripts and code into a text file (note the file doesn’t have to be a .js file, a simple .txt will be fine) is suppose you have a redirect with a value set at 1 second in your script. Once you add that to your page, after 1 second your page is going to redirect. It doesn’t matter if you’re in edit mode or not. So if you’re trying to add some complimentary text to your page… welp if you can’t get it updated and saved within 1 second, SharePoint is like “bye Felicia!” to the page you were working on. If your script was added directly into the CEWP, you’re up a creek. I mean there are ways,  but not quick and simple.  (If you know some quick and simple ways, lemme know) But if you have a separate file, you can just go to site assets library, edit the file for like 5minutes or comment it out completely. Make your page change, and then when you’re happy with your page, reset the value of your script.

So, create a new web part page, link your redirect script or code into a CEWP on this page. Lastly you’ll need to make this redirect page the homepage of the site.  After that you should be good to go. A shortened URL Page. (Vanity-ish), and a redirect to take a user to a specific page on a site. Make sure you give all your users Read Access to this site collection so they can actually access the redirect page and be redirected. No sense in users getting access denied or this site hasn’t been shared with you on a redirect site. If they don’t need access to the site it’s redirecting them to, let’s let that site take care of it there.

Now that we have a way, here are some other things to be concerned about. Each Explicit Path is going to have a site collection underneath it, and at some point you’re going to hit a SharePoint limit on number of site collections in a database or in a farm etc.… so this redirect method isn’t unlimited. Even more so, you should only have 20 managed paths per Web Application. Since out of the box you get /, sites, and teams, you really have 17. And each managed path gets cached on the web server so CPU Resources are used to process incoming requests against the managed path list. So exceeding 20 managed paths could cause performance issues with the web servers.
https://technet.microsoft.com/en-us/library/cc262787.aspx#WebApplication
https://technet.microsoft.com/en-us/library/cc262787.aspx#SiteCollection

Advice is to use this method sparingly, although I think you could get creative and spin up a single server farm and all it does is redirect users to URL’s on other farms…. (hmm….)

Feel free to let me know if anyone see’s any other gotcha’s or has other thoughts!

Happy SharePointing
-TRM

(2814)