Blog: ISA

When performing a migration from ISA 2000 to Forefront TMG, I set up the perimeter networks as part of the “perimeter” network object.  I ran into a problem when I went to create server publishing rules. They did not work.  I had to remove the subnets from the perimeter group so that the network interface would show up as part of the “external” network object.  Once the addresses on the outside interface were in the “external” network object, I was able to successfully create server publishing rules.
 
Also, Forefront TMG now allows the published port to be different from the port on the internal server.  This is useful when creating publishing rules for multiple RDP servers, for example.

While checking the syslog messages around the times of the Internet disruptions at customer site, I found that the timestamp recorded by the ISA server sometimes did not match the timestamp recorded by the border router.  After some digging, I found that the clock on the ISA server was extremely slow, and would get off by five minutes in a matter of hours.  Since five minutes is the magic number before domain authentication fails, this made me concerned. [more]

I found that the ISA is set to synchronize time with the VMhost, and that the VMhost’s clock had not been properly set.  It had a date of January 26 (on February 17).  VMware time synchronization is a little funny, in that if the guest is behind the host then the guest’s time just gets updated, but if the guest is ahead of the host then the host slows the guests clock until the time gets synchronized again.  Thus, the ISA server’s clock was slow because of the VMware time synchronization, and the native Win32Time process was correcting the problem periodically.

Our current best practice is to a) synchronize the VMhosts to public time servers, b) synchronize virtualized domain controllers to the VMhosts, and c) utilize native Win32Time to synchronize domain members.

I had an issue where wsus on a Windows SBS 2008 system was saying it was synchronizing successfully, but it wasn't downloading updates. All you would get was a message in the event logs from Windows Server Update Services (event id 10032) saying that "The server is failing to download some updates". Clients would show that they needed updates through the WSUS console and via the SBS Console, but the updates would never show up on the server for installation. In the local client WindowsUpdate.log file you would see something similar to the following [more]

2010-10-12  10:39:45:574  784  1a20 PT       +++++++++++  PT: Synchronizing server updates  +++++++++++
2010-10-12  10:39:45:574  784  1a20 PT       + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://...
2010-10-12  10:39:49:011  784  1a20 PT       +++++++++++  PT: Synchronizing extended update info  +++++++++++
2010-10-12  10:39:49:011  784  1a20 PT       + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://...
2010-10-12  10:39:52:433  784  1a20 Agent  * Found 0 updates and 57 categories in search; evaluated appl. rules of 643 out of 1075 deployed entities

So why would the WSUS server recognize the server needed updates and the client not recognize and download them? Further investigation uncovered the fact that the WSUS Content Repository was nearly empty. Total size of the repository was less than 100 MB. Obviously, none of the patch data had been downloaded.

So why was the sync successful? Moving on, after more investigation, I discovered that the ISA server was blocking what appeared to be anonymous web traffic from the SBS server even though there was a access rule set to allow all http, https, and ftp traffic from the SBS server. So, skipping to the solution. First, ISA 2004 has a problem with BITS 7.0 that is used in Windows 2008 and Windows 7. Because the initial synchronization from WSUS ONLY downloads metadata, ISA was letting that out and it would show success in the consoles. Then WSUS turns over processing and downloading of the actual patch files (.cabs, etc.) to BITS. ISA was blocking BITS background download processing so what we had was metadata for the updates, but no updates. WSUS knew the servers needed the updates, but the servers had nothing to download because the actual content for the updates wasn’t there. The fix is to change the processing of update downloads using BITS from a background to a foreground process. ISA seems to allow that just fine.

Do it by running the following query against the WSUS database. The connection can be made via SQL Management Studio Express in most cases…you are just looking to run the query against the SUSDB database.

update tbConfigurationC set BitsDownloadPriorityForeground=1

If you are using Windows 2008 with the Microsoft Internal Database (as SBS 2008 does), this proves to be a little more challenging because you have to connect with SQ Management Studio Express using named pipes instead of TCP/IP. Connect using named pipes by using this as the server

\\.\pipe\mssql$microsoft##ssee\sql\query

Conditions:

1. Machines that used to run ISA Firewall client
2. Uninstallation of ISA Firewall client
3. New PROXY settings configured
4. SEP 11.5 installed.

Many machines began getting errors in the application logs from Event Source: crypt32, Event ID: 8.  The description of the error says “Failed auto update retrieval of third-party root list sequence number from: [more]http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt”.

I eventually stumbled across a few forums that eventually led me towards this issue happening after installing SEP 11.5.  What seemed to be happening is that the machines attempted to update its root certificates from Microsoft Update at two hour intervals.  The machine will attempt to connect using the SYSTEM account, so it is important that this account also has the correct PROXY settings.  It is likely that after removal of ISA Firewall client, the settings for the SYSTEM account were left in the registry pointing to the old PROXY server. 

The SYSTEM account can always be found in the registry at HKEY_USERS\S-1-5-18. I found that on machines that were not working, the registry keys under HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings were pointing to the old PROXY script whereas the working ones were pointing to the correct PROXY wpad.dat configuration file.  I had to pull the settings from a newer system because this registry key is a binary key, so you cannot simply type the value.

Be sure that the machine also has unauthenticated user access allowed through any web filtering appliance to www.download.windowsupdate.com also.  
 
More information can be found at http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/1f626f1854285036802574e4002de4c7?OpenDocument

The HTTP standard (http://www.ietf.org/rfc/rfc2616.txt) specifies an Accept-Encoding field in the header that allows the browser to specify, among other things, what kind of compression the server can use to compress pages sent back.  Our ISA server seemed to never set this field even if the user's browser did.  In the ISA filters, there is a compression filter that must be enabled before it will accept compressed pages.  If this filter is disabled, then the browser will just get an error from the ISA server instead of displaying the page.  Audible.com is an example site that wants to send its data in gzip format and this site will not be accessible if the compression filter is disabled.

Working on an ISA server the other day I had to change the LAN IP addresses.  I was RDP’d into the server from the internal network when I made the change and applied it.  I waited a few seconds and tried to reconnect to the server (by name).  DNS has updated properly with the correct IP address, and I could ping the address, but I couldn’t RDP back to the server.  The server was virtual, so I used VI to connect to the server console.  I didn’t see any issues, but rebooted the server to be sure.  When the server came up, I still couldn’t RDP.  I checked the Terminal Services service and it was not running.  I tried to start it, but it failed.  I checked the event log and it mentioned something about the service binding.  I ran the Terminal Services Configuration console, checked the Properties of the RDP-Tcp object.  On the Network Adapter tab, the “All network adapters configured with this protocol” was selected (which is the default, but wasn’t working).  I manually selected the LAN NIC and hit Apply, and RDP started working again. [more]

I was recently configuring an ISA server for a network support customer including automatic configuration using WPAD.  The customer had a 2008 SBS server and a 2003 ISA server (running ISA 2006).  I added a "wpad" alias (CNAME) to the DNS server on the SBS box to allow clients to automatically detect the new ISA server.  However, when I tried to resolve the entry on the SBS server as well as other hosts on the network, it never would resolve.  I tried other CNAME entries on the server, and they all worked fine.  I tried removing the entry and reading it, but got the same behavior.  I decided to let it sit overnight to see if it was a timing issue.  The next day, I still couldn’t resolve "wpad" or "wpad.bofc.local".  I started digging and found that the DNS service on Windows Server 2008 has a built-in "block list" for some potentially dangerous DNS names.  The default list includes "wpad" and "isatap".  Gotcha!  Since I wasn’t concerned with blocking any DNS names, I decided to turn off the "block list".  I used the following dnscmd command: [more]

dnscmd /config /enableglobalqueryblocklist 0

Other helpful commands when dealing with this include (from http://technet.microsoft.com/en-us/library/cc995158.aspx):

To check whether the global query block is enabled, type the following:
dnscmd /info /enableglobalqueryblocklist

To display the host names in the current block list, type the following:
dnscmd /info /globalqueryblocklist

To disable the block list and ensure that the DNS Server service does not ignore queries for names in the block list, type the following:
dnscmd /config /enableglobalqueryblocklist 0

To enable the block list and ensure that the DNS Server service ignores queries for names in the block list, type the following:
dnscmd /config /enableglobalqueryblocklist 0

To remove all names from the block list, type the following:
dnscmd /config /globalqueryblocklist

To replace the current block list with a list of the names that you specify, type the following:
dnscmd /config /globalqueryblocklist name [name]…

By default, ISA only allows outbound SSL over port 443.  To add additional ports you have to run a script.  This script is documented at http://support.microsoft.com/kb/283284.  The ISA firewall service must be restarted for this change.  There are several example scripts available online, but be careful because some of these scripts may restart the firewall service for you.

Sequential processing got me this week when I was configuring a rule in ISA to allow outbound traffic on port TCP 3000. Traffic kept getting blocked, but I didn’t know why. The rule configuration was correct. After putting a monitor in place, I noticed that the traffic was getting blocked by a rule that was higher up in the rules definitions. This rule was configured with same destination IP and port number. The gotcha is that ISA will match traffic to the first access rule that is processed (in order) from top to bottom. If two rules happen to define the same destination IP and port, the first one is the only one that ever gets processed. ISA considers the first a “match” and never proceeds with processing subsequent rules.