Understanding Test Button Results on Forefront TMG 2010

1. Introduction

The Web Publishing Rule Test Button was first introduced in ISA Server 2006 SP1 with the objective of providing ISA administrators the ability to test a rule before putting it into production. As explained in the ISABlog post ISA Server 2006 SP1 – Problems that Go Beyond the Test Button, this feature had some limitations, including the one described in that post. Forefront TMG 2010 enhanced the capabilities of Test Button by adding more tests and details about the test’s results. Some of those improvements are illustrated below:

1) Better explanation when there is a delegation mismatch:


You should be aware that the test button does not actually test user authentication between Forefront TMG and the published Web site. Instead, the test button issues an anonymous GET request to the Web site and evaluates the response it receives. For instance, if the Web publishing rule Delegation tab specifies Basic Delegation and the Web site fails to include Basic authentication as one of the allowed methods, the test button considers the delegation test to have failed.

2) Pathping results are also included in the test:


Pathping is a tool that has been included in Windows Server since Windows 2000. It operates similar to tracert, but extends this functionality to provide a much more detailed analysis of the network path between Forefront TMG and the published server. The goal of including this in the test button is to help the Forefront TMG administrator in identifying core networking issues.

However there are some scenarios where the test button’s result shows an HTTP error in the description field while the test result indicates a pass state. To explain a scenario where Test Button can be tricky to understand, we are going to use a test rule result against a simple web site that is being published by Forefront TMG using NTLM Delegation. The GUI shows all items in green, however if you select the /Log folder you will see the description below:


Here it is the network trace of this request and response cycle:

Forefront TMG sends the GET Request HTTP HTTP:Request, GET /log/

- Http: Request, GET /log/

Command: GET

+ URI: /log/

ProtocolVersion: HTTP/1.1

Via: 1.0 TMGFW

Host: dc01

UserAgent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Fetch API Request

Connection: Keep-Alive

HeaderEnd: CRLF

IIS replies with the 401 HTTP HTTP:Response, HTTP/1.1, Status Code = 401, URL: /log/ , Using NTLM X-Powered-By: Authentication

- Http: Response, HTTP/1.1, Status Code = 401, URL: /log/ , Using NTLM

X-Powered-By: Authentication

ProtocolVersion: HTTP/1.1

StatusCode: 401, Unauthorized

Reason: Unauthorized

+ ContentType: text/html

Server: Microsoft-IIS/7.5

+ WWWAuthenticate: Negotiate

+ WWWAuthenticate: NTLM


XPoweredBy: ASP.NET

Date: Wed, 17 Feb 2010 15:11:33 GMT

ContentLength: 1293

HeaderEnd: CRLF

+ payload: HttpContentType = text/html

Notice that the response from the Web server is 401 Unauthorized,. The green result in this case is an expected behavior in Forefront TMG 2010. The delegation test state is based solely on the response headers received from the published server. If the Delegation tab is configured for NTLM and the Web server response with WWW-Authenticate: NTLM, the test button mechanism considers this a successful delegation state because the Web server 401 response includes a WWW-Authenticate header that matches the authentication delegation selection in the rule being tested.

Note: the same behavior can also happen if the published server responds with 403 forbidden, the test button result may also shown as green.


Yuri Diogenes

Sr Security Support Escalation Engineer

Microsoft CSS Forefront Edge Team


Nitin Singh

Support Engineer

Microsoft CSS Forefront Edge Team


Technical Reviewers

Jim Harrison

Program Manager

Microsoft Forefront Edge CS Team


Doron Juster

Senior SDE

Microsoft Forefront Edge CS Team