Detection of the following properties requires the use of a special virtual web site, referred to as the Port Check Server: SSLEnabled, Firewall, OpenPorts, ImagesEnabled, and SSLKeySize*.
Note: If you are not interested in detecting any of the above listed properties, no Port Check Server is required, and you may skip this section entirely.
Tip: Just starting to evaluate BrowserHawk? Skip this section and come back to it in the future. By default, BrowserHawk comes pre-configured to use cyScape’s Port Check Server. This enables you to test these advanced properties without having to set up your own Port Check Server (set up instructions provided below). This provides great convenience and ease during your evaluation of BrowserHawk and initial development. Before using these BrowserHawk tests in production, however, you need to configure your own Port Check Server.
To perform the property checks mentioned above, BrowserHawk instructs the visitor’s browser to make a transparent request to another virtual web site instance, known as the Port Check Server, in conjunction with its testing.
The Port Check Server is simply a virtual web site instance, which can reside on the same machine as the web site where BrowserHawk is used from, or it can reside on another server altogether. The only requirement is that the Port Check Server web instance must be assigned its own IP address.
By default, and for your convenience, BrowserHawk is configured to use cyScape’s Port Check Server for these tests. This enables you to develop and test BrowserHawk’s full capabilities without having to set up your own Port Check Server first. However, cyScape’s Port Check Server is not designed for fault tolerance and maximum availability, and it is required that you set up your own Port Check Server prior to using these property checks in a production environment.
Note: By default, the OpenPorts check uses cyScape’s Port Check Server. At this time, this server is configured to handle detection of the following ports only: 80, 443, 554, 1755, 7070, 8080, 8081, and 9090. To check the status of any other port during your development and testing you must configure your own Port Check Server.
Important: It is not possible to perform these tests over a secure connection because tests involving the Port Check Server require BrowserHawk to pass data through a specific port. However, HTTPS data must pass only over port 443. Therefore it is not possible to satisfy both of these requirements. If these properties are tested from a HTTPS page it will result in a mixed security warning message from under Internet Explorer.
Follow these steps to set up your own Port Check Server:
Obtain a unique IP address on the server you wish to run the Port Check Server on. You can also set up a fully qualified domain name for this IP address if you would like (i.e. portcheck.companyx.com). It is this IP address (or fully qualified domain name) that you must specify in the PortCheckURL property prior to calling GetExtPropertiesEx. The server that hosts this IP address can be the same as the server you are running BrowserHawk on, or an entirely different server. If you are running BrowserHawk on multiple servers, you can use the same Port Check Server for all of your servers running BrowserHawk if you wish. If you decide to set up a new machine to serve as the Port Check Server, and that server does not already have a BrowserHawk license, you must obtain a BrowserHawk license for that server and install a copy of BrowserHawk on it prior to using the property tests that rely on the Port Check Server.
Create a directory to store a few special files that will be accessed as web content as part of the BrowserHawk tests. For example: c:\inetpub\wwwroot\portcheck
Copy the bhawkp1.gif and sslcheck.asp files from your BrowserHawk installation directory (\Program Files\cyScape\BrowserHawk by default) to the directory you created in the step above.
For each port that you wish to be able to detect using the OpenPorts property, create a new instance of a virtual web server. For the description, use PortCheck_xxxx, where xxxx is the port number. For the virtual server’s IP address, use the unique IP you obtained in the first step above. For the web site’s directory, use the directory you created above. For the port number that the virtual site should run on, use the port number you want to check for, instead of the default of port 80. For example, assume you want to be able to check ports 554 and 1755. You would create two new virtual web sites both based on the same IP address, but each would use a unique port number of 554 and 1755. Both sites would point to the same content directory.
Follow the step above to create an instance of the Port Check Server that is assigned to run on port 80, just as if it was a "regular" web server instance serving requests. Checks on port 80 are used for detection of the ImagesEnabled property, and also serve to indicate when a port check test has timed out (see the OpenPorts property for details on testing for timeouts).
If you wish to use the Firewall property: Follow the above step to create an instance of the Port Check Server running on port 16771.
If you wish to use the SSLEnabled property and/or the SSLKeySize* property: You must obtain another unique IP address, and create another virtual web site based on this IP address. For the description use PortCheck_SSL. For the content directory use the same directory as used above. For the port number specify port 80. Also be sure to specify port 443 for the SSL port. Decide on a fully qualified URL to use for this instance – such as sslcheck.companyx.com. Be sure to specify this value in the SSLCheckURL property prior to testing these properties. This name will be used by BrowserHawk and not by any of your site visitors. Obtain a signed server digital ID certificate based on at least 1024 bits and this URL (common name) – this must be a separate certificate than one you are already using. Import this new certificate into this instance. Next, if you are using IIS 5, you need to disable socket pooling for this server instance, and any other web server instance that has a SSL certificate installed. Socket pooling offers some speed and memory benefits for servers configured with several virtual servers. Therefore if you have many virtual servers on the same machine which use SSL certificates (and therefore all of which need to have socket pooling disabled), or if you are concerned about disabling socket pooling, you may wish to consider creating the Port Check Server instances on a separate web server. If you are using IIS 6 you cannot use this technique and must set up a port check server on a different web server where it is the only web site instance with an SSL certificate. You can learn more about socket pooling by searching the Microsoft support web site. Follow these steps to disable socket pooling with IIS 5 for each virtual server on the Port Check Server machine that uses SSL communications on port 443:
Determine the IIS instance number associated with each web site instance running on the same machine as the Port Check Server that has an SSL certificate installed. This also includes the special web server instance you created for the Port Check Server to run SSL checks on. One trick for obtaining this instance number is to look at the Log File properties for the web site instances – the instance number is in the log file path. For example, if the log path is "c:\logs\w3svc12" then that web site’s instance number is 12.
To disable socket pooling, on the command prompt go to x:\Inetpub\Adminscripts. Then type the following: "cscript adsutil.vbs set w3svc/XX/disablesocketpooling true" except replace the XX above with the instance number. Repeat this step for each instance determined to need socket pooling disabled for in the step above. In the future, should you wish to abandon the Port Check Server, you can turn socket pooling back on by issuing the same statement exception specifying "false" at the end instead of "true".
Note: These instructions pertain only to IIS 5. For IIS 6 and later you must set up a SSL port check server on a different machine where it is the only site running SSL.
* Set up of the Port Check Server for SSLKeySize detection is required only when you use the extended property check approach for key size detection (Approach 2 as described in the SSLKeySize property documentation). If you wish to perform key size detection from HTTPS pages, there is no need to set up or use a Port Check Server in conjunction with your test.
See Also: