Blog: ISA

A few weeks ago, I was trying to backup the configuration for a Symantec Mail Security Appliance for one of our clients. The appliance sits in the DMZ and FTPs the backup file to another server on the internal network. To do so, I had to create an Access Rule to allow the FTP traffic through the ISA 2004 server. You would think that creating an inbound Access Rule to allow the FTP protocol to pass through the ISA server it would enable all inbound FTP traffic. However, this is not entirely the case. When you use the New Access Rule Wizard, you can choose the pre-configured protocol “FTP” to be the type of traffic that you are allowing. This is what I did in this particular instance. However, whenever I would try and transfer the SMS Gateway backup file, the write would fail. After checking folder and FTP account permissions 5,000 times, I happened upon a setting  the following setting by right clicking the the access rule I had already created and selecting the "Configure FTP" option: [more]

To make a long story short, when I added the preconfigured “FTP” protocol as the protocol I wanted to allow to pass through the ISA, it only enabled FTP Read access. There is nowhere in the creation of the rule, in the ‘Properties’ of the rule, or in the properties of the default FTP object to specify read/write access. Nor does it inform you that the default permission is being set as read only. You have to click right click on the rule you created and choose “Configure FTP” (not ‘Properties’) to uncheck the Read Only status of the rule. I suppose that this follows the general IT best practice of enabling only minimal required privileges, but some documentation or forewarning would’ve been nice! Consider yourself forewarned!


We were having some problems getting Windows Server Update Services (WSUS) to download new updates at one of our customer's sites.  The ISA server was denying the connections, but was saying that "an existing connection was forcibly closed by the remote host".  I made several changes on the ISA server to try to fix this.  I tried using an HTTP rule without the web proxy, disabled caching, etc.  Nothing seemed to fix the problem.  When I checked the Application event log on the server, there was a WSUS error saying, "Content file download failed. Reason: The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header."  I did some research on this and found a fix that involved making a change to the WSUS database. [more]

I stopped the WSUS service and ran the following command:
osql.exe -S PNB-TS\MICROSOFT##SSEE -E -b -n -Q "USE SUSDB update tbConfigurationC set BitsDownloadPriorityForeground=1"

I then restarted the service and it worked great.


The Symantec Mail Security Appliance software uses passive mode for ftp when backing up the configuration. Since this device is usually installed in the DMZ, an ISA server publishing rule needs to be created to publish your internal ftp server.  This rule needs to be edited to support passive mode with a port range to be used. [more]

When backing up the configuration, a path is required and it puts a / in front of the path specified.  Specifying "." for the path works, but it drops the file name and creates a file named ".".  I found the best solution is to specify "./" for the path and then it will transfer the backup file into the ftp server's user's default directory.


In the past, we had removed the Firewall Client Management Tool (fwcmgmt.exe) from the Startup folder for All Users during Terminal Server setup. This was done to prevent the icon from showing up in the system tray for all users.

It appears that this tool must be running in order for firewall configurations to be pushed out from ISA. Recently we configured the firewall client to disable web proxy in order to force all applications (IE, etc) to use the firewall client. However, these settings were not pushed out for users because the Firewall Client Management Tool was not running. [more]

Adding this tool back to the All users Startup folder enables this process to run for all users. In addition, you can modified an ini file (Documents and Settings\All Users\Application Data\Microsoft\Firewall Client 2004\management.ini) on a server so that the system tray icon will be hidden for all users.


Use caution when installing and SSL certificate for OWA or OMA on a clustered Exchange server. When you configure Microsoft Outlook Web Access to use a Secure Sockets Layer (SSL) connection to a Microsoft Exchange Server 2003 computer, you may notice a dramatic increase in CPU usage by the Lsass.exe process and by the Resrcmon.exe process. The only way to get the process back in check is to reboot the server. This problem occurs on an Exchange 2003 computer that is running in a Microsoft Windows Server 2003-based cluster. [more]
Additionally, an Error event that is similar to the following is logged in the Application log:
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services 
Event ID: 1014
Date: Date
Time: Time
User: N/A
Computer: Computer Name
Description: Exchange HTTP Virtual Server Instance - (GENESIS): IsAlive checking for this resource failed due to timeout

The solution is to install Exchange 2003 SP2 or you can call MS for the hotfix. I actually like the SSL termination on the ISA server approach a little better. If the SSL tunnel is terminated on the ISA server, you can reinitiate another SSL tunnel with another internal certificate OR you can redirect the traffic to port 80 on the inside interface. Terminating the SSL connection on the ISA server offloads processing from the Exchange server, which is usually a good idea.


When working with ISA 2004, be very careful when disabling unneeded functionality. I had an issue arise after disabling VPN access to a customer's ISA proxy server. After the configuration was changed, ISA promptly uninstalled RRAS which disabled all routing capabilities of the box. Unfortunately, from what I have been able to gather, ISA is NOT able to dynamically build the routing table based on network ranges specified in the "Internal Network" area. I think this partly because you must specify addresses ranges not subnets and not all address ranges can be converted to a proper classless networks. In, it explains that the ISA server must be able to reach each network that is specified in the "Internal Network" area via its routing table. So, from what I have been able to gather you must either use RRAS to create the static routes or put persistent routes into the routing table using "route add <network> mask <subnet mask> <gateway> -p"