Wednesday, 28 September 2011

Forefront TMG Web Publishing Rule Test Results Report Errors on One or More Paths When Publishing SharePoint

A fair few of my working ISA Server and Forefront TMG deployments are used to publish and protect SharePoint environments.

The Problem

Since the gradual move of many customers to SharePoint 2010, I have noticed that the Test Rule button that is available as part of the web publishing rule created by the SharePoint Publishing Wizard, often produces errors, even though external access to SharePoint via Forefront TMG seems to be fully functional. As many customers use this feature as an initial sanity check for publishing rule configuration (as I do myself) this can actually lead many people to believe there is a SharePoint publishing problem, when in fact there isn’t! An example of the errors can be seen in the screenshot below:

image

After being asked by a few bemused customers why this was happening, I decided to investigate the issue at little further. This blog article provides an overview of my investigations, thought process and conclusions.

The Investigation

My first assumption was that this issue was introduced as customers moved from SharePoint 2007 to SharePoint 2010, combined with the fact that the SharePoint Publishing Wizard included with Forefront TMG appeared to defined the paths generically for SharePoint, as opposed to version specific. The paths also appeared unchanged from the same wizard in ISA Server, even though support for SharePoint 2010 wasn’t specifically added until Forefront TMG Service Pack 1 was released. As discussed above, I was confident that in most cases the issue was purely cosmetic and a failure in the Test Rule output didn’t specifically mean SharePoint publishing would fail or was configured incorrectly in any way.

After a bit of testing, it was apparent I could get consistent failures in the Test Rule feature for the following paths:

<Internal Site Name>/_vti_inf.html*

<Internal Site Name>/_upresources/

as shown in the screenshots below:

image

image

Confusingly, both paths didn’t fail consistently for different SharePoint environments I tested. Sometimes just one path would fail, other times both paths would fail. How strange Smile

After a bit more research on the _vti_inf.html* path, I discovered that this is specifically related to FrontPage Server Extensions (FPSE) and is common place on both SharePoint 2007 and SharePoint 2010 environments. However, having compared two different SharePoint 2010 environments I was getting Test Rule path failures for one, but not the other, which seemed very odd and inconsistent. Then I noticed that one of the SharePoint servers (the successful test result) was running on Windows Server 2008 and the other SharePoint server (the unsuccessful test result) was running on Windows Server 2008 R2. After a little more Googling, I determined that Microsoft removed support for FPSE running on IIS 7.5, which is the version of IIS now included with Windows Server 2008 R2. Consequently, I concluded that it would never be possible for the  _vti_inf.html* path check to succeed for a SharePoint server that is running on Windows Server 2008 R2. From further testing, I managed to confirm this theory across multiple customer environments that had this particular operating system platform hosting SharePoint.

After researching the _upresources/ path, it became apparent that there were very few search results that included the _upresources term in the context of SharePoint itself. Sure, there were lots of references to _upresources in the context ISA/TMG and SharePoint. After looking at numerous SharePoint deployments, I couldn’t find a single one that actually had a virtual directory called _upresources; a majority of them did, however, have a virtual directory called _wpresources. I decided to lookup the use of this folder and determined it was a folder that contains a web.config file used in Web Part resources and hence a pretty core part of any SharePoint deployment. This made me suspicious and my instant thought was “No, surely the wizard doesn’t contain an incorrect path statement or typo?” I looked back at documentation I have done for customers running ISA Server over the years, and saw the same _upresources/ path statement in those rules too. Maybe this issue had been around for a long time, and just never noticed and/or publically acknowledged by Microsoft in a KB article. Maybe SharePoint used to use this path, but it has been removed in more recent versions.

Knowing that the likelihood of this path being present on a SharePoint environment was pretty low, I was then intrigued as to why I was receiving successful results on some SharePoint environments; even after confirming the path was definitely not present with IIS.

After reviewing the IIS logs on two different SharePoint environments, I noticed that the path check was successful when IIS returned a HTTP 401 error, and not successful when IIS returned a HTTP 404 error. These results were echoed in the Test Rule output as shown below:

image

image

This made me think about authentication configuration within IIS. Further testing revealed that the SharePoint environment that returned the HTTP 401 error had been specifically configured with Anonymous Access disabled at the site level in IIS, as shown below:

image

The net result of this was that IIS would generate a HTTP 401 response, even though the requested path was not valid (remember _upresources didn't actually exist).

For the SharePoint environment with Anonymous Access enabled at the site level (as shown below), IIS would correctly generate a HTTP 404 response as the requested _upresources path was invalid and authentication was not required to access this resource.

image

So, given the actual configuration of the IIS site hosting SharePoint, we would get a HTTP 401 response or a HTTP 404 response. Consequently, the Test Rule function would indicate a success or failure based upon these error codes, as shown below:

image

image

As the Test Rule function is not able to provide credentials to IIS, I would assume that it is designed to treat HTTP 401 responses as an indication that the path is present and consequently pass the test. However, this logic seems a little flawed if you think about the implications of this logic when the path doesn’t actually exist but IIS requires authentication; but you could argue that one would expect Anonymous Access to be disabled at the IIS site level for a majority of SharePoint deployments that are protected by Forefront TMG. Unfortunately, I don’t really know enough about SharePoint to validate this statement.

The Conclusions

Based upon the above testing and findings, I concluded the following:

  • If you are running SharePoint on Windows Server 2008 R2, then the <Internal Site Name>/_vti_inf.html* path test will FAIL due to the lack of FPSE support in IIS 7.5.
  • If you are running your SharePoint site with Anonymous Authenticated disabled at the site-level then the <Internal Site Name>/_upresources/ path test will SUCCEED as IIS will respond with a HTTP 401 error.
  • If you are running your SharePoint site with Anonymous Authenticated enabled at the site-level then the <Internal Site Name>/_upresources/ path test will FAIL as IIS will respond with a HTTP 404 error.

As it is not possible to easily modify the path statements added by the SharePoint Publishing Wizard, I believe the issue will need to be fixed by Microsoft within the wizard code in order to correct the paths, or logic, and remove the undesired results provided above. For now, I hope this blog article at least puts your mind at rest if you have experienced the problem first hand and then assumed you had done something wrong. The chances are that if at least one of the path tests succeeds, you should be good to go…

Please Note: I am currently trying to confirm my findings and conclusions with Microsoft, so I will update the article when I have more information.

UPDATE: Spoke to a couple of contacts at Microsoft (thanks Jim and Yuri) and it does look like the incorrect _upresources path is indeed a TYPO and the HTTP 401 success behaviour is by design, as discussed here: http://blogs.technet.com/b/isablog/archive/2010/02/24/understanding-test-button-results-on-forefront-tmg-2010.aspx