From /Press-Releases/Pages/Press-Release.aspx to /Press-Releases/Press-Release – make friendly URL’s for your SharePoint site in 4 steps with IIS7 URL Rewrite module
SEO, SharePoint, WCM
We all know Microsoft Office SharePoint Server (MOSS) 2007 Web Content Management (WCM) solutions for their Pages URL’s. Purist web designers/developers hate SharePoint not only for the fact that it’s injecting something into URL’s but mostly for the inability of changing anything about it. And while many people think that SharePoint and semantic URL’s just don’t play along, it turns out that there is a solution – one that doesn’t involve a single line of custom code.
It’s almost history
It’s not the first time that I was thinking about SharePoint and semantic URL’s. Last year I accepted the challenge and came up with a solution. I developed a custom HttpModule which allowed you to use semantic URL’s in SharePoint WCM solutions. The logic inside the module would rewrite the requested URL to a valid page in SharePoint.
While that module did the job it had quite a few limitations. First of all it used some custom logic to try to determine what page/URL has been requested. The way I created the proof-of-concept you didn’t have any kind of access to that logic from outside the module. Changing anything about the way the URL’s should be rewritten was equal to having to dive into the code and redeploy the module. To mitigate this issue you could provide some kind of storage for the rewrite rules but it would mean quite some development to get it done.
Another serious drawback that the module had was the fact that it was an HttpModule. As far as I know using custom modules in your SharePoint solutions takes the Web Application into unsupported state. That’s because the HttpModules are being registered in the ASP.NET request/response pipeline and can conflict with the SharePoint runtime. As HttpModules are easy to disable (a single line in web.config) the change is not irreversible. Still, wouldn’t it be better if we had something, let’s say, available out of the box?
Semantic URL’s vNext – totally codeless
A couple of months ago Scott Guthrie’s team released the Microsoft Web Platform Installer – a set of components for configuration of web servers and web development. The installer allows you to extend your server with quite a few different tools and applications among which the URL Rewrite module (stable 1.1 and a beta 2.0 available at the moment). It turns out that using the URL Rewrite module you can turn the default /Press-Releases/Pages/Press-Release.aspx into a semantic /Press-Releases/Press-Release URL without a single line of code.
Semantic URL’s with the IIS7 URL Rewrite module – before we start
In the following steps I’m assuming that you have already installed the URL Rewrite module. As the installation is really straight-forward and basically means navigating to http://www.microsoft.com/web/ and selecting the apps you want to install on your server I thought I’d better just get to the point and show you how to make SharePoint URL’s semantic.
In order to make semantic URL’s work in SharePoint you will have to take quite a few things into account. The URL Rewrite module uses Rules to determine whether the URL should be processed and if so, how it should be processed. Basically all you have to do is to create a set of rules to cover all the different sorts of URL’s that make part of your web site.
The rewriting Rules use Regular Expressions to define the URL pattern. If you really want to understand how it all works, you should consider spending sometimes on understanding the basics of Regular Expressions.
Step 1: Rewrite /Press-Releases/Pages/Press-Release.aspx into /Press-Releases/Press-Release
Let’s start off with the basics. The first thing we’ll do is to rewrite a URL of a Publishing Page located under a subsite.
Let’s add a new Rule:
The way the Rules work in the URL Rewrite module is that you get a semantic URL and have to rewrite it so that it points to a valid SharePoint URL. That means that we will be rewriting /Press-Releases/Press-Release to /Press-Releases/Pages/Press-Release.aspx rather than the other way around.
Let’s create the first pattern:
^(.*?)([^/]+)$
This pattern separates the subsites from the page:
It is important to notice that the URL Rewrite module retrieves the URL’s without the leading /, so a URL like /Press-Releases/Press-Release will enter the URL Rewrite’s processing engine as Press-Releases/Press-Release.
Let’s finish the rule by providing the Rewrite URL and applying the changes:
and let’s have a look at the results so far:
Although you can see the contents of the page, there are still some things that need to be configured. At this moment the page misses all the CSS and JavaScript files and images.
As I mentioned before, properly implementing a URL rewriting solution is all about recognizing all the different types of URL’s and patterns that they are using. The pattern we have just provided is too general: it rewrites not only URL’s of Publishing Pages but other resources as well. We need to add some more information to the rule in order to make it work.
The conditions
If you look at the HTML source, you will find quite a few URL’s like /Style%20Library/en-US/Core%20Styles/controls.css. When you test such URL against the expression we’ve just entered, you’ll see that it passes the test: the Rule thinks it’s a semantic URL:
The above URL is an example of a rewriting exception. While working with URL Rewriting rules you will not only have to recognize them but also apply them either as rules or exceptions and set them in the right order to get things working correctly.
The URL Rewrite module allows you not only to provide a URL pattern but also to define some conditions which can help you exclude certain URL’s from being processed by the specific rule.
Let’s add our first condition which will help us exclude all URL’s which end with an extension:
^.*?[^/]+\.[^/]+$
and let’s have a look at the results:
At this point the Publishing Page looks correctly. Next to fixing the branding of the Publishing Page the above rule automatically excludes from rewriting URL’s to application pages (_layouts/.., etc.) and lists forms (Lists/…/… or Forms/…).
There are however still some scenario’s that the first rule doesn’t cover.
Step 2: The Welcome Page
If you type /Press-Releases/ in your browser, you notice that the URL is being picked up by SharePoint which automatically provides a redirect to the Welcome Page. That redirect is quite bad from the SEO perspective as it is a temporary (302) redirect. If a search engine finds such URL it doesn’t follow it as the target might be changing in the near future, meaning everything that is underneath such URL won’t get crawled.
We can fix the problem of the Welcome Page redirect using a simple rule:
^(.*/)?$
If you navigate to /Press-Releases/ now you should see the Welcome Page directly without being redirected to Pages/default.aspx:
The above Rule also covers redirecting from the Site Collection root:
Step 3: The links
So far we have added to our web site support for semantic URL’s. We can access both sites and pages using semantic URL’s. The Rules we have defined rewrite semantic URL’s into valid SharePoint URL’s. But what about all the links included on pages?
From the content point of view
As you might’ve expected this is something you will have to cover by yourself. Most of the links are included inside the content meaning you can edit them yourself to point to semantic URL’s. As for the navigation you would either have to create your own controls or create Control Adapters to rewrite the URL’s rendered by the menu control.
Another approach you might consider is to create a Page Adapter to rewrite all URL’s in the whole page once it’s rendered. The downside is that such approach requires working with Regular Expressions on a large string (HTML source of the complete page) and might have a too large performance penalty to accept. Once again it all depends on your scenario and requirements.
From the SEO point of view
Making your URL’s semantic is even more important from the SEO point of view. At this point in our solution, SharePoint accepts both semantic and out-of-the-box URL’s, meaning a search bot can access the same content using two different URL’s. In order to improve the SEO of your web site, your content should be accessible by only one URL which can be used to distinguish all the different pages.
While rewriting the URL’s for users might get quite challenging, making semantic URL’s for the search engines is a bit easier and can be done using the URL Rewrite module.
The URL Rewrite module allows you not only to define Rules for rewriting URL’s but also to define redirect Rules.
Let’s create a Rule that will redirect all requests to Publishing Pages using the .aspx URL’s to their semantic equivalents:
^(.*/)?Pages/([^/]+)\.aspx$
There are a couple of things you should note here. First of all while defining this rule we have checked the Ignore Case checkbox. Because the Regular Expression we have used to define the pattern contains the Pages word which could be also spelled as pages and IIS isn’t case-sensitive we have to make the Regular Expression case-insensitive.
Another thing is the redirect itself. In the Action properties group there are two fields: Redirect type and Redirect URL (which should be called the other way around). What should be Redirect type and is labeled as Redirect URL allows you to pick a few types of redirects. The Permanent (301) redirect is the one we’re interested in as we want the search engine to index the semantic URL and not the .aspx one.
Let’s apply the changes and have a look at the results. Let’s navigate to our Press Release using the menu:
While it seems to work correctly, try to navigate to the Press Releases site using the menu:
Have you noticed the default word at the end of the URL? That’s because our Rule doesn’t distinguish between Welcome Pages and regular Publishing Pages.
Step 4: The Welcome Page link
Let’s define a new Rule which will help us fix redirecting the links to Welcome Pages:
^(.*/)?Pages/default.aspx$
If you navigate to the Press Releases site right after applying the changes you won’t see any difference. Nothing happens because the previous Rule is above the one we’ve just defined. Because the URL matches the previously defined pattern, it never enters the Rule we’ve just defined.
We can fix this easily by moving the last Rule up:
Let’s have a look at the Press Releases site once again:
And that’s all: in a few easy steps we have turned standard SharePoint URL’s into semantic, web-ready URL’s. And we did all that without a single line of code.
Sites vs. Pages URL’s
Implementing semantic URL’s in SharePoint using the URL Rewrite module is pretty straight-forward. There are however a couple of things you should keep in mind.
One of such things is distinguishing between sites and pages URL’s. The only way to distinguish between a page and a site is by using the trailing / in the URL. After implementing the semantic URL’s /Press-Releases became a page URL. Before that you could use that URL to navigate to the Press Releases site. As the URL Rewrite module has no knowledge of SharePoint being on the other side of the line it’s up to you to provide correct URL’s.
Summary
URL Rewrite module provides you with an easy way to do something many considered very challenging/impossible: making URL’s of Web Content Management solutions built on top of Microsoft Office SharePoint Server 2007 semantic. Using nothing more than a few simple Rules and no custom code you can make your URL’s web-ready and increase the findability of your content.
August 27th, 2009 at 2:05 pm
Fantastic post – was looking for such a tool for long time! Thanks a lot for the detailed explanations!
August 27th, 2009 at 2:06 pm
@Avi: Thanks! Great to hear you found it useful
August 27th, 2009 at 7:11 pm
sure would be nice if there was a switch in the site settings that just said something equivalent to \"don\'t rewrite my urls\"
August 28th, 2009 at 1:46 am
This is a great post! Thanks for trying this out and providing such detailed explanation!
Regarding the step 3 and the links in the response HTML: this is something that can be fixed by using response rewriting feature in URL Rewrite 2.0 beta. Just as you created rewrite rules to change the requested URL, you can now create outbound rewrite rules that can analyze the urls in the response html and change them to a different format. You can get more details on how to do it here: http://learn.iis.net/page.aspx/657/creating-outbound-rules-for-url-rewrite-module/
August 28th, 2009 at 5:48 am
@Ruslan: Nice tip! Have you checked how far this approach affects performance? After all, all we would be doing is performing a Regular Expression search on a large string.
What I like about the idea that it's consistent with the rest of the solution and it doesn't involve custom code.
August 28th, 2009 at 9:41 am
The performance impact can be minimized if you use tag filters in the outbound rewrite rules. With that the regular expressions will be applied only on a certain tag attributes, e.g. href or src, and not on the entire response string.
August 28th, 2009 at 11:40 am
@Ruslan: Thanks for the explanation and the tip
September 1st, 2009 at 5:20 pm
Excellent post. However, can we do the same in IIS-6? Almost all my current customer is stil using 2003 and even more, they just started to build-up their 2003 platform. So this would be a big question for us to do the same in 2003 env.
September 1st, 2009 at 7:23 pm
@Riwut L: You could achieve something comparable in IIS6 in many ways. I suggest you have a look @ http://msdn.microsoft.com/en-us/library/ms972974.aspx. Personally I have worked with Rewrite.NET (link at the end of the mentioned article).
September 2nd, 2009 at 2:47 pm
Sure, with HttpModule we can do the same, but not no-code approach like in IIS7.
September 2nd, 2009 at 4:44 pm
@Riwut L: Rewrite.NET is a no-code solution. You obviously need to install it but all the rewrites/redirects can be configured in web.config though without rebuilding any code. It doesn't have a standard interface as the IIS7 URL Rewrite module though.
September 17th, 2009 at 5:32 pm
Really good stuff!
I was wondering what you would do if the Welcome Page was set to something other than default.aspx? Would you just have to create a rule for each instance?
September 17th, 2009 at 5:57 pm
@Derek P: You could do that. Another solution would be creating an HttpHandler and redirecting always to it. The HttpHandler would contain all the logic to redirect to the page set as the Welcome Page. Please note that it would have negative impact on the performance as the Welcome Page would have to be resolved on each / request.
October 8th, 2009 at 12:32 am
Hi Waldek,
first of all, thank you for this post. it did save me lot of time. I followed your last solution and got it to work as i wanted with slight modifications, I did have some minor problems during initial setup but everything worked well once I got it working. Now we have upgraded to IIS 7 and i saw this post which makes it so much easier. But i am having a small problem after following this technique, I am getting a 404 when i try to edit the page through Site Actions after adding the rewrite rules. is there a way to overcome this?
thanks for your help
Sriraj
October 8th, 2009 at 6:21 am
@Sriraj: I'm not sure whether IIS can distinguish a regular page request from an "Edit" request. While writing the article I had a specific scenario in my mind, where you would have an authoring Web Application and its extended public equivalent with anonymous access. The friendly URL's would be applied to the public Web Application only.
October 8th, 2009 at 6:40 am
Thanks Waldek,
I am not 100% sure but i think there was some workaround in your previous post. anyways the problem is with this method once the rule is set on iis, everytime an author on sharepoint \"public site\" wants to create a new page or edit an existing page , they cannot do it without disabling the rules?
October 8th, 2009 at 6:51 am
@Sriraj: That's the whole idea of the Public Web App: it's read only. All content authoring happens in the authoring Web App.
What might help is to rewrite the hyperlinks. Although it can be done using the outbound filters, as Ruslan pointed out in his comment, it would have a significant performance penalty.
October 8th, 2009 at 7:18 am
i understand, but for a public facing sharepoint site where authors can log and create new pages or make changes to their content (without having to log on to the server and change anything on iis) this solution may not be a good solution? also i was not able to log on to the site with Sharepoint designer after adding the rules to IIS not sure if this is related. Anyways, is it possible to add a condition to check if the url is already rewritten (i.e. without/pages/.aspx)
October 8th, 2009 at 7:32 am
@Sriraj: When you're having only one Web Application things get problematic indeed. The condition you mentioned would I think resemble Step 2, but I'm not really seeing how it would help you fix the problem. If I'm right the problem is being caused either by URL's in HTML which are being used for Postback (edit mode) or too generic rules that include Web Services called by SharePoint Designer.
October 8th, 2009 at 7:42 am
thanks Waldek
heres an example of whats happening
i have a page on the site for example
http://www.mysite.com.au/about/pages/default.aspx
when the page loads with the rules set, i get
http://www.mysite.com.au/about/
when i log in to the site and try to edit the page that gets requested is
http://www.mysite.com.au/about/default.aspx
which results in a 404
October 8th, 2009 at 7:46 am
@Sriraj: Just as I said: if I'm right the postback URL is not changed pointing still to default.aspx. Once the postback is triggered a new request is made. As the URL is being picked up by the rewrite rules, you're getting a redirect instead of Postback.
October 8th, 2009 at 7:56 am
what would you recommend?
October 8th, 2009 at 8:13 am
@Sriraj: Usually, when working with WCM sites, I create two Web Applications: authoring and anonymous. That gives me some extra flexibility and allows me to isolate challenges like the one you have.
Using the outbound filters to rewrite the URL's is also an option you might consider. Please note however, that it can have major performance penalties so it is important that you test it in your environment to see if it's acceptable.
October 14th, 2009 at 9:10 am
Thanks Waldek,
extended my application as you recommended and everything works perfectly now.
October 14th, 2009 at 9:28 am
@sriraj: Great to hear that :)
January 19th, 2010 at 4:45 am
This is a great post. Thanks!
I'm getting a 404 when accessing sub pages of sites in the collection.
I.e.
– old: mysite.com/about/pages/thepage.aspx
– rewrite: mysite.com/about/thepage
Then the old 404 appears…
Would I handle this through the HTTPModule or are there more expressions that I need to add.
January 19th, 2010 at 7:32 am
@Brian L: it should be fixed using the rule from Step 3. Are you sure that everything is configured correctly? Do you have any more details on the errors that you're getting?
January 19th, 2010 at 12:30 pm
Hi Waldek,
I get a blank screen with the text "404 NOT FOUND" when accessing Pages that do not use /default.aspx as the page url. For example /contact.aspx and register.aspx are returning the 404, whereas anything with default.aspx at any level is returning the proper page.
I went back through each step to double check.
Thanks,
Brian
January 19th, 2010 at 12:30 pm
Hi Waldek,
I get a blank screen with the text \"404 NOT FOUND\" when accessing Pages that do not use /default.aspx as the page url. For example /contact.aspx and register.aspx are returning the 404, whereas anything with default.aspx at any level is returning the proper page.
I went back through each step to double check.
Thanks,
Brian
January 20th, 2010 at 6:51 am
@Brian L: the first rule should get this done. Have you tried removing all other rules and leave out just the one from Step 1?
February 4th, 2010 at 1:56 pm
http://www.sharepointoverflow.com/questions/1385/remove-default-aspx-from-the-root-site-moss-url/
April 5th, 2010 at 11:04 am
Our SharePoint 2007 install is on Server 2003 therefore I've had to use the Ionics ISAPI rewrite filter (http://iirf.codeplex.com/) to get this working relative to the IIS7 builtin rewriter.
I'm also using the CSS Friendly Adapters for the menu and have customised this to output SEO friendly urls. The last piece of the puzzle is to "fix" urls within the page content.
I plan to write a guide on this instructing staff on how to write the urls in the content but we all know how many people read guides so I was also planning to create a custom PageAdapter and override the Render method.
I have the code already written to "fix" the url, I just need to extract the url's from the page HTML. Do you have any examples of the most performant way of doing this?
April 5th, 2010 at 11:05 am
Our SharePoint 2007 install is on Server 2003 therefore I\'ve had to use the Ionics ISAPI rewrite filter (http://iirf.codeplex.com/) to get this working relative to the IIS7 builtin rewriter.
I\'m also using the CSS Friendly Adapters for the menu and have customised this to output SEO friendly urls. The last piece of the puzzle is to \"fix\" urls within the page content.
I plan to write a guide on this instructing staff on how to write the urls in the content but we all know how many people read guides so I was also planning to create a custom PageAdapter and override the Render method.
I have the code already written to \"fix\" the url, I just need to extract the url\'s from the page HTML. Do you have any examples of the most performant way of doing this?
April 30th, 2010 at 6:39 am
We have few public websites on sharepoint 2007. I have followed the steps suggested by Waldek and got urls to work exectly as i wanted but since last wee i noticed slight problem within my site.
hyper links on some pages added thru the content editor web part are missing the trailing slash(/). I installed the iis rewrite module 2.0 and used the enforce trailing slash to over come this problem but… now all my previous rules have stopped working.
has anyone had this issue with rewrite module 2.0 ?
May 1st, 2010 at 2:10 am
further to my previous comment. After installing version 2.0 the 4 steps mentioned above do not work anymore. especially the remove pages part.
Anyidea what might be causing this ?
May 11th, 2010 at 8:45 pm
[...] From /Press-Releases/Pages/Press-Release.aspx to /Press-Releases/Press-Release – make friendly URL… [...]
July 12th, 2010 at 4:58 am
Has anyone got these steps working on version 2.0?
July 16th, 2010 at 2:48 pm
@Sriraj: Any specific step that stopped working? I've just tried the first one and it worked correctly using the 2.0 version.
July 18th, 2010 at 6:25 am
Thanks Waldek
it seems to be breaking on step3: i got step 1,2 and 4 working correctly.
i even got step 3 working at one point without the condition ad soo. as i add condition, everything falls apart.
July 18th, 2010 at 6:31 am
correction, the parts that are not working
1.condition in step1
2. The third step (the links)
July 18th, 2010 at 8:47 am
@Sriraj: That's odd, I've just tested the 1st step including the condition and it worked correctly. Have you first configured all the steps and then upgarded to 2.0? If so, perhaps it's a good idea to recreate all the steps?
July 19th, 2010 at 12:02 am
Yes i had it working on version 1.0 then migrated the site to a new server which is running iis 7.5 and rewrite module 2.0 since then i cant get it working. it specifically fails when i put the condition or enable step 3. i am trying to understand how to use failed request tracing hopefully that will give me bit more knowledge of whats going wrong. i have tried recreating the steps again but no luck.
July 22nd, 2010 at 6:27 pm
I believe there is a bug in IIS URL Rewrite 2.0's regex engine.
I had to tweak the patterns to workaround this problem.
For Step 3:
^(.*?/)?Pages/([^/]+)\.aspx$
For Step 4:
^(.*?/)?Pages/default.aspx$
July 23rd, 2010 at 2:40 am
Thanks John
I tried the pattern you suggested but i still get a 404 with step 3 enabled
July 23rd, 2010 at 5:46 am
I tried to blog down the steps and my general impression of getting it to work. But I think you'll need to look at the trace logs
http://johnliu.net/blog/2010/7/22/sharepoint-2010-with-iis-url-rewrite-20.html
August 19th, 2010 at 4:11 pm
Great article! It really works!
March 11th, 2011 at 10:25 am
Please delete or modify this page. You have two articles with conflicting advice. URL rewrite for SharePoint is not supported – as you quite rightly state on the other article: http://blog.mastykarz.nl/4-ways-short-urls-sharepoint-server-2010/
March 11th, 2011 at 11:53 am
@Andy: I guess you missinterpreted the articles. While this article describes the process of creating pretty URLs (eg. removing Pages and aspx) the other is about using short URLs like /mycampaign which does nothing else than a redirect to another location with very likely a longer URL.
March 22nd, 2011 at 10:34 am
[...] The logic for doing example one is easy, but the logic for doing example two will need a little more thought. In this post I am going to go over Example two, Waldek has already covered the rules needed for example one very well here. [...]
March 23rd, 2011 at 7:26 am
[...] In the Pattern field add ^(.*?[^/]+)/(.*?)$ To test if the pattern is going to work click on test pattern and add the URL you want to check. Below I have entered the URL of our test page. You can see that it has been split into R:1 and R:2, we can now add the pages library in between here as well as the ending file extension. Again if your site is just one site collection follow Waldeks guide as he covers the rules for this scenario here. [...]
April 26th, 2011 at 1:53 pm
I think that this counts as asymmetric URL rewriting, something that is not supported by Microsoft in SharePoint. The company I work for has had two MSFT consultants from MCS look at our environment over the last two years, and both have stated that what we are doing, which is what is documented in this article, is not supported. Have a look at this post http://forums.iis.net/t/1170721.aspx.
I'm more than happy for someone from Microsoft to say that this is supported because it would solve a support issue that we have at the moment.
April 26th, 2011 at 2:02 pm
@Adam: I can confirm that the solution that I posted here is not supported and is definitely something you are using at your own risk. Unfortunately at this moment there is no supproted way in SharePoint to get pretty URLs.
May 25th, 2011 at 7:27 pm
I am trying to apply Rule 2. I want to serve the page for http://intranet.company.com with the page http://intranet.company.com/pages/home.aspx. I created a rule ^$ to rewrite pages/home.aspx. But after implementing this rule i keep getting the authentication when hitting http://intranet.company.com but when i hit http://intranet.company.com/pages/home.aspx it works. Any idea or any difference it makes by windows authentication?
May 25th, 2011 at 7:33 pm
@Satheesh: are you sure that you correctly configured the step including the regex?
May 25th, 2011 at 9:12 pm
I believe yes. Here are the steps
1) Install URL ReWriter 2.0
2) Create SP Web application (all default settings) & Root site (verified the same before making following changes)
3) Add new rule on IIS for this web app like
Reg ext: ^$
Rewrite: pages/default.aspx
And if i open the webapp without pages/default.aspx then it keeps prompting for user name and password. If i remove the rule then it works.
What i am targeting is only for root site collection and display default.aspx without showing that in the browser address bar.
May 30th, 2011 at 7:51 am
I think URL rewrite module works well for Anonymous site. But it does not work for Windows authenticated web app. Also it seems, IIS 7 rewrite modules is not supported by SharePoint.
May 30th, 2011 at 12:35 pm
@Satheesh: It's not that SharePoint doesn't support the Rewrite Module. It doesn't support URL rewriting. As long as you're using the URL Rewrite Module for redirections you are all ok.
May 30th, 2011 at 1:42 pm
completely agreeing with you. As you said if we do it for only for redirection or if we have anonymous authentication then it is okay.
June 23rd, 2011 at 5:58 am
Have been thinking of doing this for a while but never had time.
Anyways i have been playing around with the Rewrite module with sharepoint sites for a while since i first saw this post by Waldek and i was able to successfully implement it with our public sharepoint sites. I have also done some minor improvements with the DbProvider option in the rewrite module 2.0. So, just sharing it all you guys incase anyone's still interested >> http://srirajc.blogspot.com/
cheers
Sriraj
August 4th, 2011 at 1:04 pm
[...] IIS 7 URL Rewrite module is not supported by SharePoint in any version. However it works for anonymous authentication and not work windows authentication. (http://blog.mastykarz.nl/friendly-urls-sharepoint-site-4-steps-iis7-url-rewrite-module/comment-page-…) [...]
August 4th, 2011 at 1:04 pm
[...] IIS 7 URL Rewrite module is not supported by SharePoint in any version. However it works for anonymous authentication and not work windows authentication. (http://blog.mastykarz.nl/friendly-urls-sharepoint-site-4-steps-iis7-url-rewrite-module/comment-page-…) [...]
October 28th, 2011 at 8:57 am
I can't get it to work. I get a 404 NOT FOUND then i'am trying to access a Page, like Brian L. Then i access a Site it works.
Anyboy have a solution for this?
I have tried URL Rewrite 1.1 and 2,0.
October 28th, 2011 at 11:12 am
Hi Frank
I guess the first step for you to start troubleshooting would be to find out whats causing the 404. There are few different free tools available on the web which can help you with this. 1. Failed request tracing in IIS 7, 7.5 or 2. http fidler or the simplest one i have seen so far HttpFox (an addon for firefox. any of these can get you to a position from where you can starttroubleshooting the the 404 you are getting.
good luck!
December 27th, 2011 at 3:59 pm
Hi Waldek,
Thanks for sharing knowledge. We followed the article, but we are facing site bindings issue in our setup. Since we have two instances at IIS, one is public facing and second is authoring.
What we get is we need to implement REGEX in the public facing instance. When we get it done it doesn't show any functionality. I dig further to find out what the issue might be and found that authoring instance has site bindings that has an entry of public site.
When we delete that binding from authoring instance we are getting the functionality of first two steps (URL Rewriting) but we still fail to redirect the old URLs to newly set URLs that is last two steps (URL Redirect). We are also getting lots of errors in status bar in IE 8.
Please share us what we did wrong in configuration. Thanks for your time.
January 2nd, 2012 at 1:29 pm
@Zohaib: Are you using extended Web Applications, where authoring and public site are based on separate zones and therefore are separate IIS websites? If so, you should be able to use URL Rewriting when on the public site.
January 3rd, 2012 at 4:20 pm
Yes Waldek these are separate websites in IIS, we thought and did implement these rewriting and redirecting steps in the public site.
The site bindings are made by IT support team, they binded the public facing site in the authoring instance of site. Then even rewriting and redirecting is not working.
Can we still implement the rewriting with these bindings? Looking forward for your valuable input.
January 14th, 2012 at 2:11 am
I have a loadbalanced SharePoint farm, but often want to render pages from a specific webserver to see if that host is working properly. To address a specific host, I can use it's IP to circumvent the loadbalancer.
On the default website, I would like to build a rewrite proxy rule that strips an IP from the URL. For example, taking this:
http://172.22.33.200/pocit/SitePages/Home.aspx
and turning it into this:
http://pocit/SitePages/Home.aspx
which lives on another site and app-pool.
I have host file entries pointing pocit to 127.0.0.1, so the request will remain on the local host.
I can see my rule rewiting the request in my IIS logs
2012-01-14 00:48:10 W3SVC1 GET /pocit2010/SitePages/Home.aspx – 80 – 172.22.33.200
but I always get a 404 back in the browser. Any idea what may be going wrong? My pattern matches seem to be stripping the IP from the URL nicely, but I get back
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /pocit2010/SitePages/Home.aspx
Any thoughts?
August 2nd, 2012 at 1:36 pm
Dear Waldek,
I applied these 4 rules on my website and it worked very fine, but then I faced a problem with pages that postback, for example login page isn't working because it posts back
So do you have any idea how to fix this issue?
Thank you very much!
Good Luck!
August 6th, 2012 at 6:15 pm
URL rewriting isn't really supported in SharePoint and some pages break because of it. I'm not sure if there is a reliable solution to your problem given that SharePoint just hasn't been designed that way.
January 11th, 2013 at 8:57 pm
Is there a way to use this module to do a HTTP to HTTPS redirect for SharePoint 2010? Or is there a better method to do this? I'm new to URL Rewrite
January 14th, 2013 at 7:53 am
Yes, you could do that as well.
January 23rd, 2013 at 11:17 am
URL Rewrite is not supported in SharePoint 2010.. only 301, 302 redirects can be configured.. I heard something like this. Could not find a Technet saying the same…
January 31st, 2013 at 10:39 am
Dear Waldek,
We have implemented your solution with great succes, but one place. It seems that the redirect of our .aspx pages is not working when we add the "check-for-file" condition?
Our order is the following:
1: Remove pages (incl. condition)
2: The welcome page
3: The welcome page link
4: The links
We get a 404 error when running a page.aspx, as the rule thinks it is a file like jpg, css etc.
Have you experienced this, and how to fix it?
Thank you in advance :)
January 31st, 2013 at 5:12 pm
Hi Morten,
What do you mean with 'check-for-file' exactly?
February 1st, 2013 at 9:26 am
Hi Waldek,
As I wrote to you the setup works perfect until we add the conditions that fix design issues such as CSS, jpg, etc..
The problem is that when we activate the conditions, and the try to enter the old URL (press-release.aspx), then we get a 404. It is like the condition thinks the .aspx file is a design file like css, jpg, js etc.
So we can disable the condition and redirects and everyting works perfect, or we can add the condition and the site looks good on the new url (/press-release/) – But typing the old url (press-release.aspx) gives us a 404…
Any idea?
February 6th, 2013 at 3:32 pm
Hi Waldek,
Did you get time to look at the problem?
Kind regards
// Morten
February 11th, 2013 at 4:43 pm
Not really no, although it would be difficult for me to do so without any more details on how you distinct between CSS files and ASPX pages. I guess that's the piece that you should have a closer look at.
February 12th, 2013 at 1:38 pm
Hi Waldek,
What I don't understand is, that in your example, you should have the same problem, as your pages are also called ".aspx" at the end. But your pages are being re-directet and our gets an error.
February 13th, 2013 at 7:48 am
Shouldn't that be covered by the exception at the end of step 1?