Windows Authentication & IIS URL Rewrite Module 2.0

Question

I'm trying to use the IIS URL Rewrite Module 2.0 to prettify SharePoint 2010 URLs for the Internet zone of an extended SharePoint application. I have the zone set up to allow anonymous users.

As long as everything on the page is viewable by anonymous, everything works fine. But if I try to go to a page containing something that triggers Windows authentication, I get the error "The local device name is already in use" out of the Windows authentication module.

This only happens when authentication happens on a page with the URL being rewritten. If I log in on a page not being rewritten, then navigate to the page with the rewritten URL that requires authentication, everything works fine. (Everything also works fine if I change the rewrite rule to a redirect rather than a rewrite.)

The rewrite rule and two failed request traces are all at https://gist.github.com/1131530.

• Rewrite rule: https://gist.github.com/1131530#file_rewrite.config
• The first failed request trace is trace1.xml. I'm assuming this is what is supposed to happen—that the server responds that it needs to authenticate.
• The second failed request trace is trace2.xml. This is the one with the error "The local device name is already in use" from the Windows authentication module.

Does anyone have ideas about why that error would happen and how to fix it?

Answer 1

I strongly recommend that you do not use URL rewriting if you can possibly avoid it. This is likely to break things in SharePoint and this risk is rarely justified. It is also not supported by Microsoft.

I understand that sometimes business requirements stipulate URL rewriting (even though this is an implementation detail rather than a requirement), particularly for "vanity" URLs. If you are not able to use persuasion to stop this, you might be able to find a solution using URL redirection (still using the URLRewrite Module) which is much less problematic. Alternatively if your users want to change the URL structure, consider whether you actually need to change the structure of your sites and subsites to achieve this - having a URL structure that masks a completely different site structure can lead to endless confusion.

I know that your question is asking for a way to work around this problem, but I am afraid my answer is "just say no".

Answer 2

I second SPDoctor's recommendation. In addition to SharePoint incompatibility, do you realize what kind of administration overhead you would have to incur everytime somebody at your organization want to"prettify" a URL? "Hey if HR can have pretty URLs, we want them too!" Now, not only do you have to manage SharePoint, you have administer IIS more. On migrations, or disaster recovery, not only do you have to worry about the SharePoint content, but also the stuff you did in IIS, which cannot be backed-up nor migrated.