Or, how do you remove /Pages/ from SharePoint URL.

Almost all the hard work is done by Waldek Mastykarz (@waldekm)
http://blog.mastykarz.nl/friendly-urls-sharepoint-site-4-steps-iis7-url-rewrite-module/

These are just my extra notes for SharePoint 2010, I'm going to assume you are reading Waldek's article with this blog as a supplement.

How to install IIS URL Rewrite

The easiest way is via the MS Web Platform Installer

On a good connection you are good to go within 30 seconds - faster if you already have MS Web Platform Installer on the server.

Installed, IIS URL Rewrite 2.0 lives here

IIS URL Rewrite 2.0

I seriously think there's a bug with IIS Url Rewrite 2.0's Regex

Waldek's regex pattern for step 3 is perfect:

^(.*/)?Pages/([^/]+)\.aspx$

and so is step 4:

^(.*/)?Pages/default.aspx$

BUG: IIS URL Rewrite matches badly - see screenshot:

Regex will try to maximize to match as many characters as it can. But this simply does not explain why group 1 match includes Pages/ - Why was Pages/ included in the match? This doesn't make any sense.

You can test the pattern with any other regex library, including .NET (via PowerShell), and you still won't get the stupid buggy match that is IIS URL Rewrite's regex…

(Sorry I'm annoyed that this caused a lot of problem for something that shouldn't have existed...)

$pattern = [regex] "^(.*/)?Pages/default.aspx$"

$result = $pattern.match("Publishing/Pages/default.aspx")

$result.Groups[1]

Success : True

Captures : {Publishing/}

Index : 0

Length : 11

Value : Publishing/

Anyway, to fix this we need to tweak the pattern

^(.*?/)?Pages/([^/]+)\.aspx$

^(.*?/)?Pages/default.aspx$

This will finally force IIS URL Rewrite to work properly.

the extra ? tells regex to try to match as little as it can, while still making a match.

Final result – the order is important – see Waldek’s article

 

TRICKS: Debugging URL Rewrite by enabling trace

When things don't work - this is your only hope. Read trace logs.

Fortunately it's not very hard to read, I mean we read SharePoint logs and survived. It's just tedious to read logs in general.

Open the log in Internet Explorer - which picks up the XSL and gives you a nicer looking UI. Head over to the compact view tab, and look for URL_REWRITE_START

 

HORRIBLE PITFALL: URL Rewrite Cache

I've noticed that when you reshuffle a rule (or add a condition to a rule), it doesn't force the cache to bugger off. So you thought you tweaked the rule but it doesn't seem to have any effect. The trace log will tell you that it actually is ignoring your rule reshuffle because it is listening to the "Url Rewrite Cache".

This is OK, until you have a bad URL cached, then suddenly it's annoying. IIS Reset doesn't cut it.  My tip that I ended up with is to toggle a rule's disable/enable state to trigger the URL Rewrite cache to refresh.

 

SharePoint Authenticated

WARNING: I've had SharePoint on various unknown occasions suddenly raise a login dialogue. I can't reproduce this on demand, but it happens frequent enough that I think it's no accident. It also sometimes goes away when I hit F5 refresh and Windows Authentication just works and I don't see any login prompt at all.

The experience reminded me highly of the days in 2007 where sometimes SharePoint will mysteriously ask you to sign in when you are supposedly browsing the site anonymous.

Please test thoroughly.

 

SharePoint Anonymous

For a public anonymous website, this works absolutely great - no authentication to worry about either.

I didn't do much testing with the postbacks and the ribbon. They do work, but I think I'll need a lot more testing to work out if everything is still OK.

My gut feeling is that SharePoint 2010 relies a lot more on AJAX-based client side calls without a full page postback. While the URL rewrite would have affected the postback somewhat, AJAX calls would be largely immune to this problem.

Summary

Definitely try this out on your SharePoint site and I think you'll be surprised how well it worked (once you get it to work). Thanks Waldek for sharing!