BizTalk is one of those unusual products that doesn’t quite fit the usual server paradigm. Let me explain.

• It uses webservices, but its not IIS.
• Its uses SQL Server but its not a typical three tier app.
• It does enterprise application integration (deep in the corporate network) but its also a B2B server as well (on the edge of the network).

So when people look to place BizTalk in the network it can be a tricky task.

But I want to give you one axiom to live by. BizTalk doesn’t belong in the DMZ. This is because by the time you’ve opened up all the ports to make BizTalk work, its no longer a DMZ. Its a just a subnet with a firewall.

Here’s why…

My contention here is that by the time you’ve opened up all those ports, its not really a DMZ anymore. Feel free to discuss this in the comments.

Here’s another lesser axiom. Don’t put a firewall between BizTalk and the messagebox unless you really really have to. Why? BizTalk’s use of SQL Server isn’t the typical 3 tier user of its messagebox. Any network latency between the BizTalk hosts and the messagebox is going to hurt you in performance. But more importantly than that, if there is a firewall in the middle it implies BizTalk hasn’t been positioned in the network using the correct paradigm.

I talked about these two axioms in my Tech.Ed presentation last year. You can see the slide deck from that presentation here

The solution that you should fight tooth and nail for is to have BizTalk deep in the corp network in the same subnet as the messagebox and expose all the endpoints via a reverse proxy (such as ISA Server). Don’t let the security guys tell you it has to be in the DMZ because it has webservices (its not the same as IIS) and don’t let them tell you it should be in its own subnet separated from SQL Server (its not a typical 3 tier app).

This is a vast over simplification of course and there are alternatives to be considered, but I do believe this is the principle and paradigm we should be using to place BizTalk in the network.