The logical step that follows an ISA prototype would be a Pilot phase, where the functionality tested in the lab is extended into a production environment, but only to a small subset of users. This can prove tricky to set up, in some cases, but easier in others.
Organizing a Pilot Group
The first step in setting up an ISA Pilot is to find a subset of users who would be willing to test out the new ISA functionality. Ideally, the total sum of pilot users would be between 5 and 10% of the total number of users in an organization. These users should also be willing to fill out checklists and reports following their pilot testing. This information can be then used to modify the ISA configuration one last time before it is deployed to full production use.
Understanding ISA Pilot Scenarios
Depending on the purpose of an ISA deployment, it may or may not prove difficult to establish a pilot group. The following scenarios and their pilot considerations are listed below:
ISA deployed as a proxy server This scenario is the easiest to pilot. The list of pilot users' workstations can be forced to use the ISA proxy server for web caching through the deployment of an Active Directory group policy.
ISA deployed as a reverse proxy server Setting up ISA as a reverse proxy server, for such things as OWA publishing and web server publishing, can be piloted by creating a temporary web presence for the new ISA pilot configuration. To take an OWA example as an illustration, if the old OWA access was through mail.companyabc.com, and the ISA server was set up to protect this traffic, then a second host called mail2.companyabc.com could be temporarily created to allow the pilot users to test OWA access through the reverse proxy server. After the pilot has validated the configuration, the mail2 record can be retired and mail.companyabc.com can be directed to the ISA implementation only.
ISA deployed as a full edge firewall When ISA is deployed as a full-blown edge (Internet facing) firewall, then pilot deployments are more complex to administer, given the fact that traffic from the Internet, by default, wants to go through a single patch. If both the old configuration and the new ISA edge firewall are deployed at the same time, it is feasible to test out ISA access in this manner, by essentially having two sets of gateways into the environment until the pilot can be completed and the old environment retired.
ISA deployed between network segments This scenario is similar to the edge firewall scenario. The only difference is that the ISA server is meant to be placed between internal network segments to monitor the traffic going between those segments. Because the network traffic is going to try to go through the standard route, rather than through the new ISA servers, this presents a challenge. The best solutions to this problem involve creating an alternate patch for the pilot users and hard-coding routes on their workstations so that they can test access through the ISA server.
Running Penetration Tests and Attacks Against the Pilot Infrastructure
A pilot infrastructure should ideally be tested for vulnerabilities and overall performance. The best and most effective way to do this is by using third-party hacking and exploit tools to attempt penetration tests against the ISA environment. Because this is likely to occur for any Internet-facing (or often even trusted network-facing) systems, it is important to put ISA through the hoops and test out the design in this manner.