Multiple Isolated Host (Host Instances) - Multiple Virtual directories - different adapters, what are the rules?

Posted at: 8/26/2008 at 3:02 PM by saravana

If your BizTalk solution is mainly relying on HTTP/SOAP adapter (we are still in BTS 2006 - no WCF yet), you'll soon see weird errors popping up due to BizTalk isolated host instances / IIS Application pool  configuration. The most common one you'll encounter is this

The Messaging Engine could not find the receive location for URI:"/XXX_VirtualDirectory/Service.asmx".\
Please verify the receive location exists and is enabled.

And the most important but annoying thing is, intermittently  you won't get any messages published into the message box, but the client will happily be getting the HTTP 202 success response.

In order to resolve this problem, you need to setup the Isolated Host Instances and the application pools correctly. The rules are simple

1. You must create at least one IIS application pool for each isolated host.

2. A separate IIS application pool is not required if all of your receive locations use the same adapter (HTTP or SOAP) and same ReceiveHandler (ex: BizTalkServerIsolatedHost)

3. A separate IIS application pool is required if the receive locations use different adapters (HTTP/SOAP) and they run under the same ReceiveHandler (ex: BizTalkServerIsolatedHost)

4. A separate IIS application pool is required if the receive locations run under different ReceiveHandler (ex: BizTalkServerIsolatedHost, BizTalkServerIsolatedHost_2)

For simplicity I specified ReceiveHandler in the above points, they need to be substituted as Isolated Host.

The rules are straight forward, but I find it difficult to visualize it. I just put a pictorial representation to help you out in various scenarios. The GREEN box is correct configuration, RED box is wrong configuration.

1 Isolated Host, only using either HTTP or SOAP adapter:

This is a typical scenario in most of the projects I worked with. You either use only HTTP or SOAP adapter (NOT both. Just to make it clear: means you don't create receive locations for both HTTP and SOAP) in your environment (not just your application), you use the default BizTalkServerIsolatedHost instance.


1. You create one IIS Application pool.

2. You create 1 Virtual Directory, and configure to use application pool created in step 1.

3. You create 1 Receive Location, with HTTP or SOAP adapter

4. You configure BizTalkServerIsolatedHost as Receive Handler.

If this is the kind of setup you have, you are fine with your settings. Since it satisfies RULE 2.

A slightly advanced configuration will look like the one shown below. You added the second virtual directory running under the same IIS application pool, using the same adapter (HTTP), and using the same ReceiveHandler (BizTalkServerIsolatedHost). It's a valid setup, since it Satisfies RULE 2.


The same picture with SOAP adapter, still valid because both the virtual directories are using the same adapter (SOAP).


1 Isolated Host, using both HTTP and SOAP adapter:

The complication will arise once you start using both the out of the box Isolated Adapters within the same environment. Here comes our first invalid setup scenario as shown in the following picture:


This setup is conflicting with our RULE 3. The solution to the issue is to create two IIS application pools and configure them as shown in the below figure


NOTE: Isolated hosts are same BizTalkServerIsolatedHost

2 Isolated Hosts:

For various reasons (could be for performance, could be for logical separation etc) you might have created additional Isolated hosts in your environment. The setup shown in the following picture is not correct, since its conflicting with RULE 1 and RULE 4.


NOTE: You got 2 Isolated Hosts (BizTalkServerIsolatedHost 1 and BizTalkServerIsolatedHost 2)

The correct solution will be to create the additional IIS application pool.


The following setup is also correct (using different adapter).



Tags: | |  Categories: BizTalk General
Actions: Email this article Email | Kick it! | DZone it! | Save to | Technorati Links
Post Information: Permanent LinkPermalink | CommentsComments(0) | Comments RSS


Comments are closed