One of the features released in ISA Server SP1 is the Test Button feature. Its major purpose is to test the compatibility between an ISA Web publishing rule and the published Web server. Test Button works well in common deployment scenarios; however, in some fairly uncommon cases it might report inconsistent results, when it reports success to an ISA Server computer, while a user will fail to connect to the published server[i].
The main reasons for these inconsistencies are:
1. Test Button doesn’t check rule conflicts. For example, when ISA Server has a “Deny All” rule prior to the publishing rule, a user won’t be able to access the published server even when Test Button reports success.
2. Test Button doesn’t check the listener configuration. For publishing to succeed both rule and listener configurations must be valid. However, since Test Button checks only the rule configuration, the listener may have a wrong configuration (expired certificate, listening on a wrong network, etc).
3. Directory content is published by means of a wildcard. For example, there is a directory (e.g. pics/) containing some files (e.g. photo1.jpg, photo2.jpg) which are accessed from outside by direct links (e.g. http://www.contoso.com/pics/photo1.jpg). The publishing can be done in two ways:
· Explicitly – by means of two publishing paths: pics/photo1.jpg, pics/photo2.jpg. In this case Test Button won’t have issues.
· Implicitly – by means of a published path which includes all files and subfolders using /* (e.g. /pics/*). In this case Test Button will explicitly test the directory and even though it may report success, the user can still encounter problems related to the existence/access permissions of the content itself (e.g. photo1.jpg returns an HTTP response 403 or 404).
4. HTTP response 403 (forbidden) for a directory published with wildcard. When testing a directory published with trailing /* (e.g. /pics/*) an HTTP response 403 is always regarded as success, assuming that the real publishing target is not the directory, but rather its content. However this approach can be misleading: when the Web server directory requires secure channel (SSL), but the ISA Server attempts to access it by means of HTTP, the response will also be 403. In this case Test Button will also report success, although the publishing will fail.
5. Published path can’t be verified if one of the parent directories requires authentication. For example, if the published path is /ExistingDirWithAuth/NonExistingDir/*, the published server will respond with an HTTP response 401 (Authorization required) with no hint about NonExistingDir existence or permissions. In this case if the authentication delegation scheme meets the published server requirements, Test Button will report success, but a user might fail to access the resource.
6. Client information is required.
a. Forward original host name option is selected in the web publishing rule, but no public names are defined. In this case Test Button will forward FQDN of the ISA Server, which might be different from the name a user might use. (A user may use any host name which successfully translates into the IP address that ISA Server listener is listening on.)
b. Requests appear to come from the original client. This option is currently ignored by Test Button, while it can affect the publishing success for different users IP addresses.
7. FBA is supported only for Exchange 2003 and Exchange 2007. While Test Button recognizes Forms Based Authentication (FBA) for Exchange 2003 and Exchange 2007 and warns a user when an incompatible authorization delegation scheme is used, it is currently unaware of FBA in other products (e.g. SharePoint 2007).
These limitations should be considered by the ISA Server administrator when there is inconsistency between Test Button results and an actual user experience.
Software Development Engineer, ISA Server Sustained Engineering
[i] There are rare cases when a published Web server may be configured to accept some host name unknown to Test Button. In such cases Test Button might fail, but a user will still succeed in connecting to the published server.
Wouldn’t it be easier to explain what the test button can test? ;)