Exchange 2003 configuration behind BigIP

A quick suggestion is to take a look at our deployment guide for 9.x and Excahnge 2003 - although the exact commands are not the same the general set-up / way you would set it up would be the same.

 

 

The guide can be found here:

 

http://www.f5.com/solutions/deployment/owa_v9_dg.html

 

 

- James

I have gone through the setup guides for OWA. That works just fine. Our problem is that the front-end servers are behind the BigIP and the back-end servers are not. They do not communicate fully. We cannot view SMTP queues on other servers (even the other front-end servers), we can't do message tracking either. I am assuming it is more on the RPC throughput and I haven't been able to track down that documentation.

 

 

any ideas?

... let be back up a bit and make sure I got a view of how things are set-up:

 

 

Clients -> Internet Cloud -> FireWall -> BigIP -> OWA Clients (usally the Mail Servers are also sitting here)

 

 

Where do the mail servers sit? Are they on annother network? If you take out the BigIP can you connect to an OWA client and then get to the back end servers?

Yes, the mailbox servers are on another network. We are using the BigIP's for SSL off-load and load balancing. We have some pools set up to allow for traffic to go through, but I think we are missing at least one.

 

 

The clients connect to the OWA servers through the BigIP, from there the traffic goes back out of the BigIP onto the network where the mailbox servers are. All of the mail services work as they should, but the Exchange tasks don't. message tracking and queue viewer.

How are you getting the FE<-->BE traffic through the BIG-IP's? Are you using a SNAT, IP Forwarding, a VIP (aka virtual server), or a combination of those?

 

 

Also, are you running the Message Tracking and Queue Viewer tools on the BE or FE servers? (I'm guessing BE)

 

 

Ideally, I would normally suggest that you dual-home your FE servers and direct that traffic out another interface that doesn't use the BIG-IPs (or any firewall, etc.) as a gateway, *or* use another router on the same network and just set up a static route to the BE servers that uses that.

 

 

However, if you don't want to change your topology to do that, the BIG-IPs should still be able to pass your traffic. It's been a while since I've working with Exchange 2003 and BIG-IP 4.x in combo, but I believe that SNATing won't work, since Exchange needs to be able to contact each IP address that corresponds *directly* to each server name in AD/DNS.

 

 

If you're simply using BIG-IP as a router (IP Forwarding), this *should* work out-of-the-box, but more info about your config would help. You say "They do not communicate fully" -- does that mean you're setting up selective VIPs, have packet filtering enabled, or something else?

 

 

I don't know all of the traffic offhand associated with Message Tracking and Queue Viewer, but Message Tracking at least requires SMB/CIFS (tcp/445 is easiest) connectivity to the message tracking log file share on each server. I wold assume Queue Viewer does the same thing, just to a different directory.

 

 

You could always run 'tcpdump -i src host ' on the BIG-IP while trying Message Tracking or Queue Viewer from the BE server to see what ports get called.

 

 

Let us know what you discover and we can offer some suggestions about BIG-IP config based on all that info.

 

 

I am not sure if this is what you are looking for but here is the config information for our front-end exchange servers.

 

 

pool ex_80 {

 

persist cookie

 

cookie_mode rewrite

 

cookie_expiration 0d 01:00:00

 

fallback "https://connect.wsu.edu/exchange"

 

member 10.2.0.52:http

 

member 10.2.0.53:http

 

}

 

 

pool ex_443 {

 

persist cookie

 

cookie_mode insert

 

cookie_expiration 0d 01:00:00

 

fallback "http://www.wsu.edu/fallback/connect.html"

 

member 10.2.0.52:https

 

member 10.2.0.53:https

 

}

 

pool ex_993 {

 

lb_method least_conn_member

 

persist none

 

cookie_expiration 0d 01:00:00

 

nat disable

 

member 10.2.0.52:imap2

 

member 10.2.0.53:imap2

 

member 10.2.0.140:imap2

 

}

 

pool ex_593 {

 

member 10.2.0.52:593

 

member 10.2.0.53:593

 

member 10.2.0.140:593

 

}

 

pool ex_25 {

 

member 10.2.0.52:smtp

 

member 10.2.0.53:smtp

 

member 10.2.0.140:smtp

 

}

 

pool ex_135 {

 

lb_method least_conn_member

 

nat disable

 

member 134.121.1.123:135

 

}

 

pool FEX-01_RDP {

 

member 10.2.0.52:3389

 

}

 

pool FEX-02_RDP {

 

member 10.2.0.53:3389

 

}

 

pool FEX-01_8081 {

 

member 10.2.0.52:8081

 

}

 

pool FEX-02_8081 {

 

member 10.2.0.53:8081

 

}

 

pool FEX-03_RDP {

 

member 10.2.0.140:3389

 

}

 

pool FEX-03_8081 {

 

member 10.2.0.140:8081

 

}

 

virtual 134.121.1.30:80 unit 1 {

 

use pool ex_80

 

vlans internal disable

 

}

 

virtual 134.121.1.30:25 unit 1 {

 

use pool ex_25

 

vlans internal disable

 

}

 

virtual 134.121.1.30:135 unit 1 {

 

use pool ex_135

 

vlans internal disable

 

}

 

virtual 127.0.1.30:80 unit 1 {

 

netmask 255.255.255.255

 

use pool ex_443

 

vlans internal disable

 

}

 

virtual 127.1.1.30:80 unit 1 {

 

netmask 255.255.255.255

 

use pool ex_993

 

vlans internal disable

 

}

 

virtual 127.2.1.30:80 unit 1 {

 

netmask 255.255.255.255

 

use pool ex_593

 

vlans internal disable

 

}

 

virtual 134.121.0.52:3389 unit 1 {

 

use pool FEX-01_RDP

 

}

 

virtual 134.121.0.52:8081 unit 1 {

 

use pool FEX-01_8081

 

}

 

virtual 134.121.0.53:3389 unit 1 {

 

use pool FEX-02_RDP

 

}

 

virtual 134.121.0.53:8081 unit 1 {

 

use pool FEX-02_8081

 

}

 

virtual 134.121.0.140:8081 unit 1 {

 

use pool FEX-03_8081

 

}

 

virtual 134.121.0.140:3389 unit 1 {

 

use pool FEX-03_RDP

 

}

 

 

proxy 134.121.1.30:443 unit 1 {

 

target virtual 127.0.1.30:80

 

clientssl enable

 

clientssl key connect.wsu.edu.key

 

clientssl cert connect.wsu.edu.crt

 

header insert "FRONT-END-HTTPS: on"

 

redirects rewrite all

 

}

 

 

proxy 134.121.1.30:993 unit 1 {

 

target virtual 127.1.1.30:80

 

clientssl enable

 

clientssl key connect.wsu.edu.key

 

clientssl cert connect.wsu.edu.crt

 

vlans internal disable

 

}

 

proxy 134.121.1.30:593 unit 1 {

 

target virtual 127.2.1.30:80

 

clientssl enable

 

clientssl key connect.wsu.edu.key

 

clientssl cert connect.wsu.edu.crt

 

 

The traffic from the front-ends to the back-ends goes out through the BigIP's and onto the network that the back-ends are on.

 

We do view the queue viewer and the message tracking information from the back-ends.

 

I will work on getting a tcpdump for that as well.