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 ISA01.domain.com as your primary CSS, change it to CSS01.domain.com 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.

image

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 FWCArray.domain.com

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. 😉

Nov 032010
 

For me, the information below is something I was really looking forward too. Currently the books are only for sale at the O’Reilly Media website. The estimated page numbers for the books bothers me though. For TMG it’s estimated at 88 pages. Hopefully this information is incorrect. There is much more to tell about TMG than just 88 pages. 🙂

Maybe I’m a bit impatient since I’m eagerly waiting for the study material to do the exam. Oh well I don’t know. After my ISA (2004/2006) exams I might be ready for the next version, TMG. Also UAG is something which is really interesting me.

Anyhow, the books below are what I found on the http://blogs.msdn.com/Microsoft_Press webpage. Have fun with it 🙂

The new book “Deploying Microsoft Forefront Protection 2010 for Exchange Server” has been released by Microsoft Press.

648913.inddA quote from the blog website:

A new eBook from Yuri Diogenes and Dr. Thomas W. Shinder is now available. Deploying Microsoft Forefront Protection 2010 for Exchange Server (ISBN 9780735648913) presents useful best practices for deploying FPE. Yuri and Tom give a nice overview of what you can expect in the book’s introduction, which is reprinted here.

 

 

The new book “Deploying Microsoft Forefront Threat Management Gateway 2010” has been released by Microsoft Press.

imageA quote from the blog website:

A new eBook from Yuri Diogenes and Dr. Thomas W. Shinder is now available. One of three eBooks they have written about deploying Forefront, Deploying Microsoft Forefront Threat Management Gateway 2010 (ISBN 9780735648920) presents useful best practices for deploying TMG. Yuri and Tom give a nice overview of what you can expect in the book’s introduction, which is reprinted here.

 

The new book “Deploying Microsoft Forefront Unified Access Gateway 2010” has been released by Microsoft Press.

image

A quote from the blog website

A new eBook from Yuri Diogenes and Dr. Thomas W. Shinder is now available. One of three eBooks they have written about deploying Forefront, Deploying Microsoft Forefront Unified Access Gateway 2010 (ISBN 9780735648951) presents useful best practices for deploying UAG. Yuri and Tom give a nice overview of what you can expect in the book’s introduction, which is reprinted here.

Jul 152010
 

Check this out, finally the official eBooks for Microsoft  UAG and Microsoft TMG are on it’s way. Hopefully this is an indication of  that “possible” exams will follow any time soon. The eBooks are expected in the fall of this year.

For my personal interests, TMG and UAG are the most interesting books. Anyhow the eBooks which will be released are:

  • Deploying Microsoft Forefront Protection 2010 for Exchange Server
  • Deploying Microsoft Forefront Threat Management Gateway 2010
  • Deploying Microsoft Forefront Unified Access Gateway 2010

 

http://blogs.technet.com/b/yuridiogenes/archive/2010/07/08/new-forefront-books-by-microsoft-press.aspx 

http://blogs.msdn.com/b/microsoft_press/archive/2010/07/08/forefront-2010-ebooks-coming-soon.aspx

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 10.10.1.0/24 and 10.10.2.0/24 and 192.168.2.0/24 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!