What is Hosts and Host Instances?
A host is a logical representation of a Microsoft Windows process that executes BizTalk Server artifacts such as send ports and orchestrations. A host instance is the physical representation of a host on a specific server. A host can be either an in-process host, which means it is owned and managed by BizTalk Server, or an isolated host, which means that the BizTalk Server code is running in a process that is not controlled by BizTalk Server. A good example of an isolated host is Internet Information Services (IIS), which hosts the receive functionality of the HTTP and SOAP adapters. Hosts are defined for an entire BizTalk Server group; a collection of BizTalk Servers that share configuration, MessageBoxes, ports, and so on.
What is Send Ports and Send Port Groups?
A send port is the combination of a send pipeline and a send adapter. A send port group is a collection of send ports and works much like an e-mail distribution list. A message sent to a send port group will be sent to all send ports in that group. The send pipeline is used to prepare a message coming from BizTalk Server for transmission to another service. The send adapter is responsible for actually sending the message using a specific protocol such as SOAP, or FTP.
What is BizTalk MessageBox Database?
The heart of the publish/subscribe engine in BizTalk Server is the MessageBox database. The MessageBox is made up of two components: one or more Microsoft SQL Server databases and the Message Agent. The SQL Server database provides the persistence store for many things including messages, message properties, subscriptions, orchestration states, tracking data, and host queues for routing.
What is Difference between an Isolated host and an In-Process host?
The difference between an Isolated host and an In-Process is that an Isolated host must run under another process, in most cases IIS, and an In-Process host is a complete BizTalk service alone. Additionally, since In-Process hosts exist outside of the BizTalk environment, the BizTalk Administration Tools are not able to determine the status of these hosts (stopped, started or starting).
Security is also fundamentally different in an Isolated host versus an In-Process host. In-Process hosts must run under an account that is within the In-Process host’s Windows group, and do not maintain security context within the Messagebox. Isolated hosts are useful when a service already exists that will be receiving messages either by some proprietary means or by some other transport protocol such as HTTP. In this case, the Isolated host only runs one instance of the End Point Manager and is responsible for receiving messages from its transport protocol and sending them to the Messagebox through the EPM.
What are benefits & best practices for configuring multiple BizTalk hosts/host instances?
A good Host separation policy recommend using separate hosts for processing, receiving, and sending messages, and use separate hosts for trusted and non-trusted items to facilitate implementing security measures and to improve manageability of the hosts. You can install only one instance of a host per BizTalk server. it is recommended to start any BizTalk environment with at least four hosts.
- Receiving
- Orchestrations
- Sending
- Tracking
- It will be easier to configure scalability and easier to control the behavior such as stopping all receives to enable an environment drain.
- host separation technique is to have a dedicated tracking host, since tracking is a low priority sub-service if you have tracking in a very busy host it might start accumulating tracking information on the BizTalk Message Box.
- Isolating artifacts with different security requirements are also reason for host separation, you can assign different Windows Groups, Users and certificates to each host creating security boundaries which will reduce the risk of running them in the same environment as other artifacts which increases the return on investment you have done in BizTalk.
- You can also separate hosts for security and reliability reasons, since each host has its own set of dedicated resources such as database tables and windows services you can separate artifacts or applications that have high performance requirements that will benefit from these additional resources
- If you have some unreliable artifact you can also use host separation for reducing the impact of such component (Custom Adapter, Pipeline, etc.) since if that host instance crashes it won’t affect anything else.
What are Disadvantages of Additional/Multiple Hosts?
While there are benefits of creating additional host instances, there are also potential drawbacks if too many host instances are created. Each host instance is a Windows service (BTSNTSvc.exe or BTSNTSvc64.exe), which generates additional load against the MessageBox database and consumes computer resources, such as CPU, memory, and threads. Other than these, you have the following reasons for not configuring too many additional host instances:
- Several performance counters are reported per host with too much granularity. This affects the usability for the administrator who would need to traverse through a lot of data. This has a negative impact on the overall view the administrator has.
- Each host consumes considerable amount of memory that might lead to a situation of throttling and reduced performance.
- If the hosts have received adapters that continuously perform polling, each host will poll the database at short intervals, thereby resulting in degraded performance.
What is Single Sign-On (SSO)?
Enterprise Single Sign-On (SSO) provides services to store and transmit encrypted user credentials across local and network boundaries, including domain boundaries. SSO stores the credentials in the SSO database. Because SSO provides a generic single sign-on solution, middleware applications and custom adapters can leverage SSO to securely store and transmit user credentials across the environment. End users do not have to remember different credentials for different applications.
What is zombie message in BizTalk?
Error: 0xC0C01B4C The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended.
A zombie message is a message that was routed to a running orchestration from the messagebox and was “in flight” when the orchestration ended. An “in flight” message is a message that has been routed to a service instance and so is in a messagebox queue destined for the service instance. Since the message can no longer be consumed by the subscribing orchestration instance, the message is suspended and marked with a ServiceInstance/State value of “Suspended (Non-resumable)”.
A zombie service instance is an instance of an orchestration which has completed while a message that was routed to the orchestration instance from the messagebox was still “in flight”. Since the orchestration instance has ended, it cannot consume the “in flight” messages and so is suspended and marked with a ServiceInstance/State value of “Suspended (Non-resumable)”.
Terminate control messages – The orchestration engine allows the use of control messages to cancel all currently running work in a specific orchestration instance. Since the control message immediately halts the running orchestration, zombie instances are not unexpected. A number of Human Workflow related designs tend to use this mechanism as well as some other designs.
Parallel listen receives – In this scenario the service instance waits for 1 of n messages and when it receives certain messages it does some work and terminates. If messages are received on a parallel branch just as the service instance is terminating, zombies are created.
Sequential convoys with non-deterministic endpoints – In this scenario, a master orchestration schedule is designed to handle all messages of a certain type in order to meet some type of system design requirement. These design requirements may include ordered delivery, resource dispenser, and batching. For this scenario, the tendency is to define a while loop surrounding a listen with one branch having a receive and the other having a delay shape followed by some construct which sets some variable to indicate that the while loop should stop. This is non-deterministic since the delay could be triggered, but a message could still be delivered. Non-deterministic endpoints like this are prone to generating zombies.
What is an orphan message?
An orphaned messages is a message that has completed and finished its processing in the BizTalk message box however the information of this is not updated in the tracking database and will hold space in the tracking database until manually deleted or updated.
How do you track success message transaction in BizTalk?
You can use the BizTalk Server Administration Console to enable message body and message property tracking. There you can also view the tracked message body, including schema information, strong name, and all the promoted properties for the generated message. For more details of Message tracking click here.
In how many ways can we do the BizTalk Application deployment?
BizTalk Application deployment can be done using the following:
- Deploying from Visual Studio
- Building a Microsoft Installer (MSI) package that can be exported or imported between environments.
- Using command line-based tools such as MSBuild and BtsTask.
- Using community frameworks, such as BizTalk Deployment Framework and NANT.
Which are the four most important BizTalk databases?
- BizTalkMgmtDb (contains the configuration of a BizTalk Group)
- BizTalkMsgBox (contains the messages and work in progress)
- BizTalkDTADb (contains information about the completed processes)
- SSODb (contains credential information)
What jobs do you need to configure when you install BizTalk?
- The Backup BizTalk job (location of Full and Log backups).
- The DTA Purge and Archive job (at least the location where you want to Archive Tracking data.
Following Jobs created when we install & configured BizTalk.

Below links are available for other segment of Interview questions and Answers:
- Interview Questions And Answers – BizTalk Development Activity
- Interview Questions And Answers – Schema
- Interview Questions And Answers – Pipelines
- Interview Questions And Answers – Orchestration
- Interview Questions And Answers – Mapping
- Interview Questions And Answers – BAM
- Interview Questions And Answers – BRE
- Interview Questions And Answers – BizTalk Architecture
