Publishing A Web Site Using ISA Server Part 2

In the first part of this two part series, we took a look at some of  the things you need to do before publishing your server. If you missed the first part, go and read it now by clicking here.

In that article, we covered the importance of taking care of the = following issues:

• DNS Configuration
  
• Destination Sets
  
• ISA Server client configuration
  
• ISA Server Inbound Request Listener

After these elements are configured, you are ready to publish your = Web Server.

Publishing a Web Server Located on the ISA Server

Publishing a web site located on the ISA Server entails some special problems you must address before you begin publishing. By default, IIS wants to use Port 80 to listen for inbound web requests. However, since the ISA Server’s Web Proxy service uses Port 80 to Listen for inbound web requests, you cannot have both the ISA Server and the IIS WWW Service both listening on the same port.

To solve this problem, you should configure IIS to listen on the internal interface of the ISA Server. This prevents a conflict with the Web Proxy service’s Inbound Web Requests Listener. However, if you are publishing Autoconfiguration information on the internal interface of the ISA Server, it will use Port 80 by default. You could change the Port number that ISA Server uses to listen for Autoconfiguration requests and try to make it work that way. However, from our experience with ISA Server, it does not seem to want to work on the internal interface’s Port 80. This may be a problem related to the configurations we have worked with, but we have never been able to publish a web site on Port 80 of the internal interface, in spite of the documentation saying this is possible.

So, the first thing you should do is change the IP address and Listening Port number that IIS uses to listen for inbound web requests.

Readying IIS For Publishing

1. Open the Internet Services Manager from the Administrative Tools Menu.
   
2. You’ll see what appears in the figure below.
   
   
   
   
3. In the IP Address drop-down list box, click the down-arrow and select the IP address of your internal interface. In the TCP Port text box type in a Port number that is not already in use. You can determine which Ports are already in use by opening a command prompt and typing netstat -na. This will list all currently open ports. Note that Ports listening on 0.0.0.0 are listening on all interface. You’ll be fairly safe if you use a high number port, because relatively few of those are used by Windows network services. But make sure first!
   
4. After making the changes to the IP Address and Port number, stop and then restart the WWW Service. You can do this via the control buttons in the Internet Information Services console.

Now that IIS is ready, we can get to the job of Publishing our web site.

Creating a Web Publishing Rule

To create a Web Publishing Rule, we can take advantage of the Web Publishing Wizard. Perform the Following steps to publish your web site.

1. Open the ISA Management console, expand the Servers and Arrays node, and then expand your server or array name.
   
2. Expand the Publishing node, and then right click on the Web Publishing Rules node. Click on the New and then on the Rule command. This will start the Web Publishing Wizard.
   
3. On the first page of the wizard, you’ll type in the name of the rule, as we’ve done in the figure below.
   
   
   
   
4. Click Next. On the Destination Sets page, Select the Specified destination set option, and then select the name of the destination set that you want to use for this publishing rule. You will see something like what appears in the figure below.
   
   
   
   
5. Note that I have included in the description of the destination set the URL that will be used to access the published web site. Its always a good idea to include the URLs that are being used in the destination set in the description box. That way, you’ll know exactly what URLs are being used by the destination set when you configure your publishing rules. Click Next.
   
6. This takes you to the Client Type page. If you want everybody in the world to be able to access the web site, select the Any request option. If you want to limit who can access the site, select Specific computer (client address sets) or Specific users and groups option. You might want to limit site access if you are making it available only to partners. The Client Type page should look like what appears below.
   
   
   
   
7. After configuring the client type, click Next. This takes you to the Rule Action page. On this page, you configure how you want ISA Server’s publishing rule to handle inbound requests for the URLs included in the destination set. Select the Redirect the request to this internal Web server (name or IP address). Note that if you use a name, rather than an IP address, the internal interface of the ISA Server must be configured with a DNS Server address that can resolve the name. You might be able to get away with the NetBIOS name resolution sequence, but don’t tempt fate. Make sure your DNS infrastructure is in place before working with ISA Server.
   
   Change the Port number in the text box for Connect to this port when bridging request as HTTP to the port number that you configured in IIS for the web site. You can change the other options if you need to, if you made changes to the other ports in IIS. The dialog box should look like the figure below.
   
   
   
   
8. On the last page of the wizard you can confirm your settings. If all looks good, click Finish.

Now, when we type in the URL www.isa.tzo.com we see the following:

Note that I’ve changed the default page on the ISA Server that I published. This helps me know what web site and server I am accessing. Changing the default page to give server identification information is a good idea if you’re working with a number of publishing rules and servers and you need to get a grip on “which is which”. After everything is configured and working correctly, you can change the default page on your IIS web sites to reflect the actual content you want to present to the public or your partners.

Note that you can see the connection request in the ISA Management console, as seen below.

In this example, the domain name for the published server is isa.tzo.com. TZO allows you to dynamically register your domain name if you happen to be stuck with a connection that uses a dynamically assigned IP address. Each time your IP address changes, the TZO client software registers your new IP address with the TZO dynamic DNS server. This is quite helpful for those of you with DHCP assigned IP addresses on your external interface. Another cool thing about TZO is that they assign a wildcard entry for your host name. That means you can use www, mail, ftp, or nntp or any other host name you want, and it will resolve to the external IP address of your ISA Server. Note that if you wish to use the TZO service, you will have to create a packet filter to support the service on the ISA Server.

For more information about TZO and their dynamic DNS service, check out:

www.tzo.com

Publishing an Internal Server

In the previous example we went over the procedure for publishing a web server located on the ISA Server itself. This time, we’ll publish an internal web server; that is, a web server located on our private network. Publishing an internal server is not quite a difficult, because you can use the default Port number of the internal server, if you wish. You can publish multiple sites on the internal web server by placing them on different ports, and then using a different destination set and web publishing rule for each one. Another option supported by ISA Server is to publish multiple sites using different host headers.

Perform the following steps to publish an internal web server:

1. As in the last example, open the ISA Management console, and right click on the Web Publishing Rules node. Click New then click Rule.
   
2. On the first page of the Web Publishing Wizard, type in a name for your rule, then click Next.
   
3. On the Destination Sets page, select Specified destination set and then choose the destination set you want to use. In this example, we have configured a destination set that we will use to connect to our internal web server EXETER. Your dialog box should look something like that seen below.
   
   
   
   
4. On the Client Type page, select the appropriate client type and click Next.
   
5. On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address). Then, type in the IP address of the internal web server. If you are using Host Headers to create multiple sites on your IIS Server, be sure to select the Send the original host header to the publishing server instead of the actual one (specified above). What this means is that the host header will include the name in the original request, rather than the request containing the name or IP address of the internal server. In this way, multiple web sites that are configured by using host headers on the internal server will work correctly. Your dialog box should look something like that below.
   
   
   
   
6. Click Next. Confirm your choices and then click Finish.

Confirm that your Web Publishing Rule is configured correctly by typing the URL in the destination set for your server in your browser. You’ll see success as we see below!

Parting Thoughts:

Publishing a web site using ISA Server is a simple process can be done using the Web Publishing Wizard. While the actual publishing of the site is easy, there are a lot of places that you can mess up if you haven’t done the footwork in advance to prepare the site for publishing.

One thing that catches a lot of people is DNS configuration. Remember the Firewall Clients will use the DNS entry on the external interface on the ISA Server, but SecureNAT Clients use the DNS configuration on the SecureNAT client itself. The vast majority of the servers you publish should be configured as SecureNAT clients, so be sure to configure them with a DNS server that can resolve Internet names.

Another thing that often catches people is how destination sets are used in publishing rules. The reason is that we spend most of our time creating destination sets to control outbound access. However, when we configure destination sets to support web publishing, we have to look at it from the other way around. We have to look at the destination from the viewpoint of the person on the Internet making the inbound request. You must use the FQDN that external users will use to access your published web site.

In a future article, I’ll cover some issues related to processing path statements, and we’ll go through examples of how you publish sites that include path statements. Until then, happy publishing!