Dec 032010

Like Microsoft ISA server, the Configuration Storage Server (CSS) from TMG also uses ADAM to store the configuration. When creating a replica of the CSS, ADAM is also used to replicate the data.

But what if the primary fails and you have to reinstall the server? Well, in that case you can still use the replica CSS to connect the firewall to. However when installing a new replica of the secondary CSS you will receive issues with ADAM. One of the issues you might get is something like this:

Event ID: 2091

Ownership of the following FSMO role (Operations Master role) is assigned to a server which is deleted or does not exist.

Operations which require contacting a FSMO role owner will fail until this condition is corrected.

So because of this error the roles needs to be transferred to an other CSS server. There are 2 possible ways to do this. 1) Transferring the role or 2) Seizing the role. Actually it’s just like Active Directory. Seizing is something you only do when the previous FSMO holder isn’t available anymore. If it is still available but you want to replace that server you should use the transfer method.

But how do you do this in a Forefront environment?

Let’s say we have two ISA servers and we want to add an additional CSS on a different computer. Let’s say the computer names are as follows: CSS01, ISA01 and ISA02. The CSS01 will become the primary CSS and we want to decommission the current primary CSS running on ISA01.

First of all, let’s tackle the easy part. In the ISA or TMG client right click the array and simply change the primary configured CSS to the secondary or replica CSS. So instead of as your primary CSS, change it to After this is done you need to change the FSMO roles to CSS01.

Okay, first of all you need to start the ADAM Tools Command Prompt. If you click the start button, go to All Programs >> ADAM and there you can find the ADAM Tools Command Prompt. Basically it opens a new command prompt with a starting point in C:\Windows\adam folder. Those tools are installed when you install a CSS on either computer.

Once you are in the command prompt you need to follow the following procedure:

  1. Open an ADAM tools command prompt on ISA1 or ISA2.
  2. At the command prompt, type: dsmgmt.exe
  3. At the dsmgmt: command prompt, type: roles
  4. At the fsmo maintenance: command prompt, type: connections
  5. At the server connections: command prompt, type: connect to server CSS01.domain.local:2171

The ADAM port used by ISA or TMG is 2171 so keep notice of this. Otherwise it will try to connect to port 389 which is the default port number for ADAM or AD.

Once connected you also need to transfer the roles if possible. To transfer the roles follow the procedure below.

  1. At the server connections: command prompt, type: quit
  2. At the fsmo maintenance: command prompt, type: transfer naming master
  3. At the fsmo maintenance: command prompt, type: transfer schema master

And you’re done! If all went well the roles are transferred. If not you will get error messages in your command line window. Ok this is one part, but what if ISA01 had issues with its CSS? For example, if objects are tombstoned or any way corrupted. Or maybe ISA01 is crashed and cannot be recovered anymore. Or what if you tried to transfer the role and received a warning like this:

Event ID: 1837

An attempt to transfer the operations master role represented by the following object failed.

In that case you can seize the FSMO roles instead of transferring. To do this follow the procedure below:

  1. At the server connections: command prompt, type: quit
  2. At the fsmo maintenance: command prompt, type: seize naming master
  3. At the fsmo maintenance: command prompt, type: seize schema master

If you want to add the ISA01 again as CSS simply install the Configuration Storage Server again as a replica and you’re done.

Dec 022010

Recently I came across something interesting when building a new ISA environment where the Firewall Client will be mostly what is used. Almost all the traffic needs to be authenticated before being sent to its destination. Since the Firewall Client is designed for that (the traffic is not just HTTP(s) and FTP over HTTP) we advised to install the Firewall Client on every Citrix Server and clients.

However during some initial testing I noticed something weird. Although some of the traffic is being balanced, I noticed that the Firewall Client isn’t balanced at all. At first I was really stumped and I didn’t know where to look to troubleshoot. I checked and checked and triple checked the configuration to make sure everything was set correctly. I’d even let a colleague of mine check it again to prevent myself from thinking in circles. Still I couldn’t find any weird configuration issues and neither could my colleague.


Note: The screenshot is made off hours so SecureNat is also imbalanced at the moment. This is not important for this article 😉

So what happened over here? In the end I was pointed by Jason Jones to this Microsoft article where Microsoft stated:

Load balancing is not supported with Forefront TMG Clients or ISA Firewall Clients

Issue: Client machines running Forefront TMG Clients or ISA Firewall Clients may have issues connecting to an array of Forefront TMG servers with any type of load balancing configured on the related Forefront TMG network.

Cause: Load balancing (either integrated or using an external load balancer) is not supported together with Forefront TMG Clients or ISA Firewall Clients.

Solution: Instead of using a load balancer, use DNS round robin to point the clients to the Forefront TMG array member’s dedicated IP addresses.

Hmmm. This is not fun. What’s the reason you should use DNS round robin? Is this by design? Why is that?? After further investigating and talking with Jason Jones I heard the following:

The FW client uses a control channel to facilitate authentication and communication with the TMG firewall. For proper operation, Firewall Clients must therefore be configured to communicate directly with the TMG firewall’s dedicated IP address (DIP) not the VIP.

Jason Jones is a MVP for Microsoft Forefront for a pretty long time and I’ll trust him. Personally I’m not very fond of using DNS round robin to balance such. It might be because the design of the Firewall Client. In my opinion Microsoft should address this “issue”.

Oh, Before I forget, the reason why I have a problem with this is because I see an issue coming up when one node fails. Just imagine this:

A FWC client is configured to use a DNS name to connect to the ISA or Forefront TMG array. Lets say you would use

The client will lookup an IP address for that DNS record and will receive an IP address from the failed host. The FWC tries to connect to the failed ISA server. If the host doesn’t respond you would not be connected. I’m not sure what exactly would happen since this is truly new for me but I guess you’ll never get connected until your lucky enough that the client will receive the IP address of the functioning ISA/TMG node.

I’m forced to use this configuration for one of my clients  but trust me, it doesn’t really feel good. 😉

May 162010

Quite often I get questions about how you should configure your network cards for Microsoft ISA or Microsoft TMG server. Since there is a common misconception about this, I thought I needed to write something down about it. For the moment I will assume that you have configured your ISA/TMG server in a domain environment. Later on I might describe other scenarios where your network card configuration might differ.

First, let’s talk about the external network adapter. Of course, you would configure an IP address and a subnet mask right? But after that, a lot of questions start rising. Should I configure a Default gateway on this adapter? Should I configure DNS servers on this adapter?
First the default gateway. The default gateway is a device where traffic is forwarded to when the machine can’t find the route to the destination IP address in its own routing table. Since adding the whole Internet into a static routing table isn’t a real option, you simple use the machine’s default gateway to forward your traffic to. This is usually your ISP router. So to get back to the question if you should configure a default gateway on the external NIC, the answer is Yes.

So what about the DNS configuration on your external network interface card? Since I assume your ISA/TMG is joined to a domain, this is pretty important question. As you might know, DNS is a very important item within an Active Directory environment. Without a good working DNS environment you might run into loads of problems. For example: authentication issues. So what if you configure ISP DNS servers on your external interface even if you configured DNS servers on your internal interface? There is a big chance that your ISA/TMG server might forward authentication requests to your ISP and of course they don’t know anything about your domain infrastructure. So that would be useless. Actually configuring DNS on the external interface is not necessary.

So to summarize, configure the following on the external network interface card:

  • IP address
  • Subnet mask 
  • Default Gateway

(The image below is from a Windows 7 system but you get the idea)

 External NIC Example

Ok and now we turn our attention to the internal network interface card.
Let’s skip the IP address and subnet mask topics and move on to the default gateway. First of all you can only have one default gateway on your ISA/TMG server. Actually, this is true for many devices. But wait, I just said you should configure the default gateway on your external NIC right? But what if you have multiple different subnets in your internal network? What if you have subnets like and and subnets? Well those subnets should be added on the ISA/TMG servers using static routes to your internal subnets. You can do this with the "route add" command. So no, we don’t add a default gateway on the internal network interface card.

(Example of a persistent route add command)

Persistent static route

But what about DNS? Remember I talked about authentication and stuff? You guessed it, you should add the internal DNS servers to your internal NIC. ISA/TMG is capable of authenticating AD users. Maybe Bob is allowed to use FTP, but Ken isn’t. These users needs to be authenticated and ISA/TMG will query the DNS servers to find the AD servers. So yes, DNS is needed.

Ok, to summarize you should configure the follow settings on the internal NIC:

  • IP address
  • Subnet mask
  • Internal DNS servers

(The image below is from a Windows 7 system but you get the idea)

Internal NIC Example

Well, we’re almost done. The last thing I would like to recommend to you is that you keep an eye on your network binding order. Make sure you keep your internal network on the top and your external network at the end. Anything in between should be your DMZ interfaces if you have them.

Oh! I almost forget to mention DMZ interfaces. The only thing you need to configure for a DMZ interface is an IP address and a subnet mask. Note, if you have multiple subnets behind the DMZ interface make sure you add static routes for it just like you may have done for the internal interface.

Well, this was a pretty long post but I hope that I made it clear how you should configure your network interface cards on your ISA/TMG servers!

Apr 152010

Lately I received a couple of questions asking if I could explain a bit more about the Flood Mitigation settings within Microsoft ISA Server 2006. Before we start, you should know that pretty much the same settings are also available in Microsoft Forefront Thread Management Gateway or TMG. I’m not going to tell you exactly how you should configure it since you need to find your own balance. Rather, I’m going to tell you what the settings mean. I think it’s more important to understand what they do then giving you some numbers. 🙂

So let’s start of with a screenshot from Microsoft ISA Server 2006 Flood Mitigation settings:

Flood Mitigation

This is the page which can help you in preventing DoS attacks, SYN attacks or different kinds of flood attacks.  So adjusting those options should be done with care. For example: when you configure the settings to be more relaxed and allow a large amount of connections, it could potentially cause the ISA server to get overloaded with high CPU, disk, memory or network usage and slow to a crawl. On the other hand, if you configure it to be strict and not allow very many connections the ISA server will reject new connection requests for a certain IP. After one minute, ISA Server resets the quota for this IP address and the traffic is no longer blocked. If the client again exceeds the quota, the ISA Server once again blocks the traffic for one minute.

So finding the correct balance is probably the thing to do. Personally, I would recommend that you use the default settings first. When certain IP addresses are exceeding the default values, begin by investigating why this is happening. If it’s a legitimate reason, you can add that IP address to the IP Exceptions tab. For example, in my experience with some clients I’ve noticed that Citrix can generate a high number of HTTP connections per minute. In those cases, I add the Citrix servers to the IP Exceptions list. For one client, I used this list to raise the default connection limit from 600 to 6,000 HTTP connections per minute which was enough.

Of course Microsoft has posted an excellent article about this. The table below, which I copied from the article, tells a lot about the settings. Actually, I think it tells all you need to know. 🙂

ISA Server mitigation Defaults
TCP connect requests per minute, per IP address. ISA Server mitigates flood attacks that occur when an attacking IP address sends numerous TCP connect requests. ISA Server also protects against worm propagations that occur when an infected host scans the network for vulnerable hosts. By default, ISA Server limits the number of TCP requests per client to 600 per minute.You can configure custom limit exceptions for specific IP addresses. By default, this limit is set to 6,000 requests per minute.
TCP concurrent connections per IP address. ISA Server mitigates a TCP flood attack that occurs when an offending host maintains numerous TCP connections with ISA Server or other servers. By default, ISA Server limits the number of TCP concurrent connections per client to 160. You can configure custom limit exceptions for specific IP addresses. By default, this limit is set to 400 concurrent connections per client.
TCP half-open connections. ISA Server mitigates SYN attacks. In a SYN attack, an offending host sends TCP SYN messages without completing the TCP handshake. By default, ISA Server limits the number of concurrent half-open TCP connections to half the number of concurrent connections configured for concurrent TCP connections. You cannot change this default.
HTTP requests per minute, per IP address. ISA Server mitigates DoS attacks. In a DoS attack, an offending host sends numerous HTTP requests on the same TCP connection to victim Web sites. By default, ISA Server limits the number of HTTP requests per client to 600 per minute. You can configure custom limit exceptions for specific IP addresses. By default, this limit is set to 6,000 requests per minute.
Non-TCP new sessions per minute, per rule. ISA Server mitigates non-TCP DoS attacks. In a non-TCP DoS attack, malicious hosts send numerous non-TCP packets to a victim server. The specific non-TCP traffic is allowed by an ISA Server rule. By default, ISA Server limits the number of non-TCP sessions per minute to 1,000, for the specific protocol (rule).
UDP concurrent sessions per IP address. ISA Server mitigates UDP flood attacks. In a UDP flood attack, an offending host sends numerous UDP messages to victim hosts.When a UDP flood attack occurs, ISA Server discards older sessions, so that no more than the specified number of connections is allowed concurrently. By default, ISA Server limits the number of concurrent UDP sessions per IP address to 160.You can configure custom limit exceptions for specific IP addresses. By default, this limit is set to 400 sessions per client.
Apr 142010

Today one of my customers reported that the historical data couldn’t be reviewed when using the ISA console. Since I didn’t the installation I started first to see if any data was actually logged in de SQL 2005 database. While running a query against the database I noticed that data was indeed logged. So why wasn’t it possible to review the historical database?

I thought, let’s modify the ISA installation. I fired up the add or remove programs window and I choose for the ISA software. During the wizard I received this window.

Advanced logging not installed 

Ok, someone decided not to install the Advanced Logging. At first, this seems logical since we don’t need MSDE for logging. But we do need it to review historical log data even if the database is on an remote SQL server. After installing this option we finally could review the historical data. 🙂

Although I just found this option for ISA 2006 it probably also apply for ISA 2004 and TMG.