It never ceases to amaze me how many people can start off with bad experiences with BizTalk (which is why I do this blog and share my experiences). It really is an amazing product, but most people don't (or often can't) give it the time or respect it really deserves / demands to make it work correctly. I suppose because it does have a nice installation and configuration UI most people just think it does what they want. I know people make this mistake with SQL Server as well. The following are what I consider some of the minimum best practices for configuring a BizTalk Server.

Separated Hosts

I see this one a lot. If you just configure BizTalk out of the box you will have one Host and Host Instance: BizTalk Server Application (isolated hosts don't really count for this). I don't even really like the name of this host, but it is what you end up with (although you can change it in the configuration tool). At the very least I recommend the following host configuration:

Receive

Send

Orchestration (you can leave as BizTalk Server Application if you like)

Tracking

I even make these hosts on my development machine. There are quite a few good reasons for this so I'll start with the most basic: resources. In .NET a process has only so many threads in its thread pool. Sure you can always increase this number via a global setting, but there is a point at which this will generally stop helping you and start hurting. Part of this has to do with context switching overhead part with pure resource allocation. BizTalk is a massively parallel product and as a result requires many threads to run. If you leave all of the above features configured in a single process (as it is by default) you will run into thread starvation. I've run into this just on a development machine during testing, but you will really see it pronounced in a production environment. BizTalk will run slowly, though like expected still run reliably.

Further in reality you probably want to have different user accounts for each of these hosts, this can give you tight security controls between parts of your application. You may not need the security aspect on your development machine, but any servers (Integration, UAT, Production) will definitely benefit from this. Better still isolating processing, sending, and receiving will allow you to monitor and profile your solution more closely. You can attach perfmon logs to each service as it makes sense; no need to track messages received per second in the Orchestration host.

Basic Database Configurations

It is truly shocking how often this one happens. Most people installing BizTalk Server are completely unaware that installing the BizTalk databases on a SQL Server changes the server's MaxDOP (Maximum Degree of Parallelism) to one. If you're not exactly sure what this means it does what it sounds like: limits how many processors will be used in a parallel query. The setting is per query so its impact may not be that big, but it affects the Server, not just the Database. This may not really matter too much for you, but if this database server is used by other applications it probably will have an effect. This option is required for proper functioning of the Message Box database only. Other databases installed with BizTalk actually benefit from being on a server with a higher degree of parallelism. This is a great argument for spreading your databases across multiple SQL Servers (or clusters).

The other one I see a lot is to put the databases on an Analysis Services server. Analysis and Transaction are two diametrically opposed types of processing. They each require a different set of configuration and resources and they do not live well together. If your BizTalk solution is going to face significant volume I would recommend against host its databases on a shared database server (i.e. a database server that hosts other applications). Most people totally underestimate how hard BizTalk will be on SQL Server. Since everything goes through the Message Box, which is in SQL, it will be under tremendous load. Usually when a BizTalk application is running slow, SQL Server is a big contributor.

Microsoft has published some excellent information here that can help you really optimize your databases for BizTalk. It is really worth taking the time to go through this and the other optimization resources Microsoft has made available for BizTalk. Soon I will post on my own test results from this optimization process.