BizTalk Transactions

There are three possible discrete transaction boundaries within BizTalk Server.

The first boundary surrounds the BizTalk adapter, receive pipeline, and BizTalk MessageBox. The adapter can (transport permitting) enlist in a transaction with the source system, effectively creating a transaction spanning the source system and the in-bound BizTalk architecture. This way, the message will not be removed from the source system until the message is committed into the BizTalk MessageBox and is therefore safe in a durable store.

The second transaction boundary is between the BizTalk MessageBox and orchestrations. This ensures that any messages being processed by an orchestration are handled within the scope of a transaction. If an orchestration fails for whatever reason, the message will be returned to the MessageBox ready for reprocessing or the orchestration itself will resume from a previous checkpoint.

The third transaction boundary is between the BizTalk MessageBox and Send adapter. The adapter can, transport permitting, flow the transaction to a destination system, thus creating a transaction spanning from the BizTalk MessageBox to the destination system. This way, the message is not removed from the BizTalk MessageBox until the message has been successfully committed into the destination system.

These transaction boundaries are critical to ensuring that messages are not lost either by BizTalk or by remote systems, and these boundaries provide a high level of transactional integrity for your messages.

Below figure depicts the boundaries.


The figure depicts the transaction flowing between BizTalk and an MSMQ queue, as both MSMQ and the MSMQ adapter support transactions. However, this is optional depending on your solution. The figure also depicts a custom Receive pipeline component enlisting on the transaction (which is, again, optional).

BizTalk support Atomic and Long Running transactions.

Atomic: short execution time (typically seconds)

  • Fulfill all ACID attributes
  • Acquires data locks on Resource Managers (ex: SQL Server)
  • Operations succeed (commit) or fail (rollback) as a unit via Transaction Manager (ex: DTC)

Long-Running: might span hours or days

  • Must not acquire data locks for such long time
  • Commit and rollback are done explicitly by code. No Transaction Manager to aid in this
  • Rollback more commonly knows as Compensation. Compensate an action rather than undo it. Ex: You cannot undo sending a payment message, but you can compensate by sending a cancellation message

An Orchestration Scope shape can be configured with a transaction type

  • None (Default)
  • Atomic
  • Long Running


Transaction Type can be set at Orchestration Level (default None):


  • Cannot contain other transactional scopes
  • Entire Orchestration will be Atomic; therefore will persist once at the end

Long Running

  • Can contain both Atomic and Long Running scopes

Transaction Type at Scope Shape level:

  • Atomic scope cannot contain other transactional scopes (nesting not allowed)
  • Long Running scopes can contain both Long Running and Atomic scopes.


Compensation, as the name implies, is the process by which you can provide a compensating action for an operation that has previously occurred, unlike a transactional rollback, which occurs before the operation has been committed.

Compensation is supported for both Long Running and Atomic Transactions.

Compensation is often used for long-running transactions, as there is no other way to roll back things that have happened within the transaction. With atomic scopes, you ensure that everything is happy before committing. Compensation also can be used for atomic scopes where you need to reverse the results of a previously committed transaction.

Compensation is a multistep process; you must provide the code to undo the action previously performed. Again, this is different from atomic transactions, as any operations are done within the scope of a transaction and none are committed persistently until the overall transaction has completed.

Compensation blocks are called using the Compensate Shape inside Exception Handler blocks.


Compensation blocks will be executed in reverse order, following an exception being thrown within the orchestration. Compensation blocks can contain any combinations of orchestration shapes.



Compensation occurs only for committed Transactions.

So here in this case will transaction will be called?

The answer is NO because the compensation is only valid for committed transaction.

Here the transaction has failed.So it’s a case of exception handling.

In reality, however, compensation should be used with care. It is important that you fully understand the consequences of using it for your scenario.

The reason for this is that there are side effects from transactions that are committed. For example, suppose that a business transaction is constructed from two transactions: #1 – credit payee’s account, followed by #2 – debit payer’s account.

Let’s assume that transaction #2 fails. Therefore, you need to execute the compensating transaction for transaction #1. All’s well and good. You simply debit the account the amount that you credited it, and you are back where you started, right?

Well, actually no, because for this scenario when the payee’s account exceeds 100,000, he becomes classed as a premier customer. As such, the interest rate applied to his account is automatically adjusted upward. This now means that to correctly compensate you need to execute the business rules to determine whether he is still a premier customer.

This example is relatively trivial, but the point is that many business transactions have side effects. For compensation to work correctly, these side effects need to be accounted for. This usually adds a great deal of complexity, and for many integration scenarios that level of complexity can be overwhelming.


An Orchestration Scope shape can be configured with a transaction type of atomic. This signifies that anything executed within the scope will take part in an atomic transaction that conforms to the four usual ACID attributes: atomicity, consistency, isolation, and durability.

  • AtomicityAll changes effected within the scope of an atomic transaction must complete successfully or all changes must be rolled back.
  • ConsistencyOnce an atomic transaction is committed, it must ensure that any data modified remains consistent; it is not acceptable for an atomic transaction to leave a database in a inconsistent state by invalidating rules or constraints.
  • Isolation – Any changes made during an atomic transaction must be kept isolated from other read operations until the transaction is completed.
  • Durability – Once an atomic transaction has successfully committed, the changes must be durable and therefore not held in memory but instead in a durable store such as a SQL Server database. Such changes must be committed to a physical medium, such as a hard drive, to ensure that the changes survive a machine failure. It’s not acceptable for data to be subsequently rolled back following a committed atomic transaction.

To provide atomic transaction support, an atomic scope incurs a persistence point at the end of an atomic scope. This is done to ensure that, following the completion of an atomic scope, it cannot be executed again — for example, if the orchestration rolls back following a later failure in the orchestration.

Due to the nature of an atomic transaction, the orchestration cannot be dehydrated while within an atomic scope. Therefore, it’s wise to ensure that you keep the size of the atomic scope down and, as required consider splitting a large atomic scope into separate discrete atomic scopes and providing compensation handlers.

When would you want to use an atomic scope? There are three main reasons

  • To use a .NET class that is not marked as serializable
    • Serialization is critical to orchestration execution, however, an atomic scope prevents serialization during execution of an atomic scope, enabling you to use non-serializable components.
    • It’s worth emphasizing that the use of an atomic scope will produce an extra persistence point in your orchestration, which will introduce performance overhead to your solution.
  •  To minimize the number of persistence points
    • An atomic scope itself causes a persistence point, although this can be mitigated if, for example, you wrap two or more Send shapes, each of which incurs a persistence point.
    • In this scenario, you can turn two persistence points into one because the atomic scope optimizes the persistence points down to one by committing both send operations at the same time.
  •  To call a COM+ component
    • You might need to call a COM+ component (ServicedComponent) that you want to participate in the scope of the orchestration transaction.
    • Atomic Transactions are not propagated to and from BizTalk:
      • Orchestration cannot participate in other component transaction
      • Other components cannot participate in Orchestration transaction
    • Ex: calling a .NET component which uses TransactionScope from an Expression Shape, will not roll back the DB operations, if the Atomic scope fails in the Orchestration. Atomic scope is scoped only over MessageBox variables and messages.
    • If Transaction propagation is needed, external assemblies must use COM+ objects derived from System.EnterpriseServices.ServicedComponents

Atomic Transactions and Messaging

Send shape inside an Atomic scope will not actually send the message out, until scope is committed. Message will be sent to MessageBox, but will not be available to subscribers until scope commits.

Request/Response pattern is not allowed inside Atomic scope. If Request is not sent, then Response won’t come.

Similarly, Initialize/Follow correlation sets are not allowed inside Atomic scope

Long Running

Atomic transactions are perfectly suited to short-term operations that require the full ACID behavior and are using technologies that explicitly support transactions. But they may not be the most appropriate solution to your problem due to the isolation part of ACID.

Isolation effectively means that you have to place locks on any data involved in the ACID transaction to prevent modification by other people and, in the strictest sense, even reading of the data (although this can be controlled by lowering the isolation level).

Taking into account a typical BizTalk scenario involving a third party, you would not want a third party to lock any of transactional resources over the Internet or for a long period of time. This is where long running transactions come into play. They enable you to implement long-running business processes that do not require or cannot support atomicity or isolation.

Compensation is instead used to provide a manual form of rollback for your business process — a manual version of atomic transactions’ rollback features.

Atomic transactions aren’t always suitable, especially when you want to understand if a transaction rolled back for auditing purposes. An atomic transaction effectively erases all the history of a transaction.

To this end, you should consider full auditing of such operations and ensure that the auditing operation is not transactional itself. This will ensure that the audit trail is preserved even if the transaction has been rolled back.

Related Links

BizTalk built-in monitoring tool – BizTalk Health Monitor (BHM)

Microsoft has finally provided a BizTalk built-in monitoring tool called BizTalk Health Monitor(BHM) with the release of BizTalk Server 2013 R2 in June 2014.

BizTalk Server 2013 R2 release was a basically a platform update along with the support for JSON on the WCF-WebHttp adapter. An overview can be found here on MSDN: What’s New in BizTalk Server 2013 and 2013 R2

You can view Guru Venkataraman speak in the screencast below on these new features of BizTalk 2013 R2 at TechEd North America 2014. To view the part about BizTalk Health Monitor skip to about 34 minutes.



BizTalk Health Monitor is a new BizTalk snap-in that helps monitor the health of your BizTalk Server environment. This snap-in can be added to the existing BizTalk Administration Console or can be run individually.

This is a new free tool from the support team.  The idea for the tool was envisioned by the Support engineers based on their years of experience.

While this built-in option won’t replace things like the BizTalk Server 2013 Monitoring Management Pack for System Centre Operations Manager, or come close to the feature set of third party options like BizTalk360 or AIMS for BizTalk, but it does provide an out-of-the-box solution for performance monitoring, environment validation and notifications.


If you are working on BizTalk for a while then you probably already about MBV – MsgBoxViewer. It’s a windows based application gathering all information of a BizTalk group and detecting any issues, non-critical or critical warnings. It is vital for a BizTalk administrator to have complete and detailed knowledge of a BizTalk group at any time, and detect any potential problems in advance.

This new BizTalk snap-in BHM is based on the same engine as MBV and was built by the same project team that created the MsgBoxViewer tool (MBV). Though BHM was introduced with BizTalk Server 2013 R2 and it would also be helpful to existing customers (still using 2010 and 2013) with monitoring their server deployments.

How to install BizTalk Health Monitor snap-in

You can refer this MSDN post to learn more about how to register the BHM MMC with BizTalk MMC. I would also recommend the post by Sandro Pereira where has very well explained Installing the new BizTalk Health Monitor snap-in on Biztalk Server 2010 or BizTalk Server 2013


Following are the major features of BHM :

  • Monitor Multiple BizTalk Environments
  • Generate and View MBV reports
  • Dashboard view for overall health of BizTalk Environments
  • Schedule Report Collection
  • Send Email Notifications
  • Performance Monitor integration with pre-loaded scenario-based Performance counters
  • Report Management
BizTalk Health Monitor v2

Based on the feedbacks of the BHM user the team has come up with the new version of BHM with new features, at the same time made it more reliable to provide a better experience.

  • Customised Dashboard – Now you can customize your dashboard by adding\removing\resizing custom tiles.


  • Custom Queries – You can add your own queries to the BHM to make it more personalize and enrich the out of the box BHM query repository.


  • Custom Rules –  BHM v2 will also allow you to add custom rules on your custom queries or existing BHM queries so you can easily monitor your environment specific information.



  • Profiles enhancements – You can create mu
  • ltiple profiles to monitor a single or multiple BizTalk groups. Based on customers feedback we have made some enhancements in the profile management:
      1. Now you can add the option to specify a different user under which BHM should collect the report.
      2. We also moved the report management from BHM to per profile level so that you can manage the BHM reports for each profile separately.
      3. You can easily create a copy of a profile and reuse it for other group or some other modifications.
      4. You now have an option to select if you want to create the HTML page. You can uncheck this option to preserve disk space.
      5. Renamed it from “Group” to “Profile”
Known issues with BHM v2

Here are the list of known issues reported in the last version of BizTalk Health Monitor

    1. When a user account is specified to schedule a BHM collect, the creation of the task returns the following error: “A specified logon session does not  exist. It may already have been terminated”.
    2. BHM on a localized OS is displaying an error message when creating the collect scheduled task even if the task is well created.
    3. BHM on a localized OS is displaying an error message when creating the collect scheduled task even if the task is well created.
    4. BHM on a localized OS is not displaying the performance counters in the interactive performance view.
    5. When we create a monitoring profile targeting a BizTalk group not accessible by the logged-on user, the  console is crashing.
    6. There is no SSL usage option in the mail notifications settings.
    7. Error when creating a scheduled analyze task if the username or password contains some special chars like ‘&’

BHM would be a good option for customer who are not using SCOM or any third party tool for BizTalk monitoring. BHM can be used to schedule to generate the MBV report and receive the email notification. You can also integrate Perfmon with pre-loaded scenario based Performance counters. It also provides Dashboard view for overall health of BizTalk Environment and Schedule Report collection.

Best approach to automate the BizTalk deployment process

I  believe being a software developer one of the primary goal is to help people to automate their manual process/task in their business/work to make them more efficient and productive.

And in the same way automating the BizTalk deployment process makes the team more efficient and productive.This reduces deployment time and also error during deployment, and adds stability to deployment process. Even for small environment we use should use automatic deployment process.

There is already a very good article written by a friend of mine, and my colleague in one of my previous company, Vikas Bhardwaj  which talks about the BizTalk deployment using BTDF and PowerShell.

But here in this post I want to go a step back and discuss the process/approach to come up with automation deployment plan for your BizTalk Environment.

In my current job I do BizTalk Health Check for many customer and still I find most of them are using the manual deployment process. For one of the customer I have been assigned the task to help them to automate their BizTalk deployment process.

I can use one of the following approach to accomplish the task.

Approach 1:

  1. Go through their last deployment or the current deployment (if there is any) and then create the script to automate it by using BTDF or PowerShell or something else.  And once it’s complete and tested walk them through the script I have created.
  2. Now customer can use this for current deployment but what would happen for the next deployment which can be a
    • Partial or full deployment
    • Number of artifacts and application may increase\decrease.
  3. Chances are that they would be able to update the script for the changes or they can go back to their manual deployment if they are not able to update the script.
  4. They can again reach out to me or some other consultant to update the script as per the changes.

Approach 2:


  1. Ask customer to explain me the current manual deployment steps. Check if deployment document exist else help them to create one. Idea here is to make them understand what exact task requires for their manual deployment and have them documented.
  2. Next thing would be to help them understand which all tasks in the document can be automated by using BTSTask commands . BTSTask can be used to perform most of the tasks that are found in the BizTalk Administration Console.
  3. Now I will ask them to create a script using BTSTask command-line tool for the task identified by referring the scripts available in SDK samples of BizTalk.
  4. This would give them clear picture of time and effort saved by using the scripts. For example if a deployment was taking 2 hours and after the above exercise they reduced it 1.5 hour, it’s a good value for the exercise they did.
  5. Now I can pitch in here and can add value by improving the script using whatever framework & technology which further reduce their deployment time and effort. For example deployment time form 1.5 hours to 1 hours and also without any further dependency on me for updating the script going forward (change/update is inevitable 🙂).

I always try to use the 2nd approach until unless customer is very much asking for the 1st one.

Feel free to share any other approach in the comment which has worked for you or can be better than above mentioned.

Related Links:


Why does BizTalk need MSDTC?

The Microsoft Distributed Transaction Coordinator (MSDTC) service is the component included with Windows 2000 and above that is responsible for providing and coordinating transactions between multiple Windows machines. This is used by COM and .NET to provide transactional capabilities for programs built on either of these systems.

To ensure that all operations are transactional in an environment that may potentially contain multiple servers all performing different roles, BizTalk uses MSDTC to ensure that the operations are transactionally consistent.

BizTalk does distributed transactions across the various BizTalk databases like BizTalkMsgBoxDb (MessageBox), BizTalkMgmtDb (Management), BizTalkDTADb (Tracking and Archiving), BizTalkRuleEngineDb, or BAMPrimaryImport and other (BAMStar, etc.). If you want transactional receiver you again need MSDTC.

Each computer, in a distributed transaction, has its own resources and participates as an element in the global transaction that must be committed or aborted across all the servers involved. MSDTC performs the coordination role for the components (and machines) and decides if a global transaction is successfully committed or must be rolled back.

MSDTC blocks

Consider a scenario where three servers are involved in the transaction: the MQSeries server, the BizTalk Receive host server, and the SQL server that hosts the BizTalk MessageBox. MSDTC is used throughout to ensure that the operation is done atomically (that is, the message is either successfully removed from MQSeries or published into the MessageBox or the transaction is aborted and it remains on the queue).

MSDTC is also used whenever BizTalk persists data to the MessageBox (for example, when a persistence point is hit in an orchestration).

It is clear from these scenarios that if MSDTC is not working correctly, it is impossible for BizTalk to perform any of these actions in a transactional manner.

Checking MSDTC Security Options

By default, network DTC access is disabled on operating system, meaning that the machine will not accept or send network DTC traffic. Given that BizTalk requires this, you must modify the default network DTC configuration for proper operation. This is one of the most common MSDTC issues that I have seen when working with customers.

Network DTC access is strictly required only if a multibox installation of BizTalk has been done (including separating SQL and BizTalk on separate boxes) or if an adapter that requires MSDTC, such as the MQSeries adapter, is used.

To configure the correct MSDTC settings:

  1. Go to the Administrative Tools folder in Control Panel and double-click Component Services.This will open the Microsoft Management Console (MMC).
  1. Expand Component Services and open the Computers folder.
  2. Right-click My Computer, select Properties, and then click the MSDTC tab.
  3. Configure the MSDTC

MSDTC Table1

MSDTC properties


Related Links:

Essential ESSO in BizTalk

BizTalk has a key dependency on Enterprise Single Sign-On (ESSO), because there are two uses of ESSO.

First, ESSO is used to securely store send port and receive location configuration information for BizTalk. Because the information contained in the configuration of these items (URLs, file drop locations, etc.) is often confidential, it needs to be stored safely and securely. This means that the BizTalk service requires access to the ESSO service in order to be able to access this configuration information and, hence, send and receive messages. Therefore, it is essential to ensure ESSO is always available.

The other use is to store encrypted user credentials, which can then be transmitted to various systems. A key problem within many enterprise organizations is cross-platform security, system integration, and management. For example, when Line-of-Business (LOB) applications and other systems require separate logons users must keep track of, and use, multiple credentials. For many IT support teams the most common support incidents are password resets. This situation reduces end-user productivity while significantly increasing help desk expenses. If a user community mishandles IBM mainframe or AS/400 midrange logon credentials this can represent an increased security risk and compromise access to vital enterprise computing resources.

Enterprise SSO is provided by a set of processes that run on network servers to provide the following services for heterogeneous systems:

  • User account and password mapping and caching
  • Single Sign-on to multiple Windows domains and Host security systems
  • Password Synchronization to simplify administration

Enterprise SSO offers administrators a means to efficiently map accounts across Windows Active Directory and Host systems or LOB applications. This includes supporting 1:1 and group:1 associations. These mappings are stored securely in a centralized Credential Database (SSODB) using SQL Server. Based on a secure end-to-end architecture, BizTalk Server can call into SSO to obtain foreign credentials and access resources on these Host systems or LOB applications with the appropriate credentials.


The Master Secret Server

ESSO uses the SSODB database to store all encrypted credentials. Information is encrypted and decrypted from this database using a key called the master secret key. The first BizTalk Server that is installed in your group will have an ESSO service installed, referred to as the master secret server because the master secret key is stored in the registry on this box. On each additional BizTalk Server that is installed in the group, an ESSO service will be present, which has to start up successfully and without errors for BizTalk to start.


For each of these instances of ESSO to start, they require access to the master secret server ESSO instance so that the key can be cached by the service. Access to the master secret server is now not required until the service is restarted. If the master secret server fails, when the other ESSO services restarted, they would no longer be able to access the master secret server and cache a copy of the key. Therefore, they would not be able to access information in the SSODB database and the service would not start correctly.

This, in turn, would prevent BizTalk from starting correctly. To resolve this, you would need to recreate the SSODB database, which would require you to reconfigure the full BizTalk group — typically, a lengthy process and one that you want to avoid! Therefore, it is critical that you back up your master secret key and know how to restore it.

Clustering Options for the Master Secret Server

Because the master secret server is a single point of failure in your BizTalk group, it should be made highly available. This can be done using Windows clustering. The master secret server must be part of an active-passive cluster configuration. It can either be installed on its own server cluster or as part of one of your existing clusters. Given that the master secret server does not consume many resources, most customers opt to install it on the database cluster that the BizTalk databases use. This avoids the somewhat prohibitive costs of purchasing the additional resources required for an additional cluster but provides a highly available solution. Please note that if you do cluster the master secret server using the BizTalk database cluster, it is recommended that it is contained in its own cluster group so that if it fails over it does not affect other clustered services such as SQL Server.

Related Links:

What is the difference between Basic and Custom configuration of BizTalk Server?

After BizTalk Server is successfully installed, the next step is to configure BizTalk Server.



There are two ways you can configure BizTalk Server:

  • Basic configuration
  • Custom configuration

Basic configuration

Basic configuration is a quick configuration and is recommended for developers setting up a single-computer installation of BizTalk Server with the BizTalk databases on the same server.

When using basic configuration, the following occurs:

  • All default BizTalk database names are used during configuration.
  • Accounts specified during configuration will be created locally on the BizTalk server.
  • The configuration tool does not allow you to select what features to be configured and would attempt to configure all features installed.
  • The SSO backup file password will be the password of the current user used to configure all BizTalk services.

In addition, when BizTalk Server is configured using basic option, the following points should be considered:

  • You cannot configure the BizTalk databases on a separate SQL Server computer.
  • BAM Analysis cannot be configured on a SQL Server named instance.

Custom Configuration

Recommended for all other installations where one or more computers are used in the BizTalk solution or when more control is needed over the installation.

Custom Configuration allows you to:

  • Select the features to be configured on BizTalk Server.
  • Define the database servers and database names associated with BizTalk Server features.
  • Consolidate the data store for BizTalk features into a single database, except the BAM databases.
  • Change the service accounts associated with BizTalk Server features.
  • Configure BAM Analysis on a SQL Server named instance.
  • The account used for configuration must be a member of the domain-level SSO Administrators group.
  • Domain-level security groups and accounts used in a custom configuration must be created before configuring BizTalk.

When BizTalk Server is configured on the first computer, the following are created:

  • BizTalk Server group—when you configure the first BizTalk server, a BizTalk Group is created along with the BizTalk databases and the BizTalk SQL agent Jobs.
  • Enterprise SSO—The Enterprise SSO service is created during BizTalk configuration. The BizTalk runtime service is dependent on this service.
  • BizTalk Server Runtime—One host instance (BTSNTSVC.exe) implemented as a Windows service and an isolated host instance (mapped to an IIS application pool) are created.
  • Depending on the features selected when configuring BizTalk, other databases may be created. If BAM portal is configured, the virtual directory for BAM is created in IIS.
  • The configuration for BizTalk can be exported from one server as an XML file and used to import to another server. This is a convenient way to populate most of the fields in the configuration wizard to save time and effort.

Troubleshooting Configuration issues

If the configuration of BizTalk fails, then review the configuration log. The location of the configuration log file is provided at the end of the wizard or by navigating to the %temp% directory.

The log file provides information as to why the configuration failed. Start by opening the configuration log file in the notepad and searching for error from the bottom of the file, searching up to find the most recent error or reason.

Common issues leading to an unsuccessful configuration:

  • BizTalk database already exists: This happens when the BizTalk databases with the same name already exist on the SQL server(s) specified. Consider manually deleting the databases using SQL Management Studio or by specifying a different database name or different SQL Server.
  • BizTalk databases cannot be created: This is commonly due to lack of permission of the user used to configure BizTalk on the SQL Server to create the BizTalk databases.
  • Event viewer log space: If the application event log runs out of space during BizTalk Server setup, the BizTalk configuration may fail.
  • MSDTC not configured: If the BizTalk databases are configured on a remote SQL server, it is important to ensure that Network DTC Access is enabled in Component Services for both the BizTalk server and the remote SQL server where the BizTalk databases are to be configured. If there is a firewall between the BizTalk Server and the SQL server, it is important to ensure that the required ports are opened in the firewall to allow RPC communication. If the Windows installation of the BizTalk servers and the SQL server where the BizTalk databases are to be configured are from an image, the System Identifier may be the same and this would cause issues during BizTalk configuration.


The recommended MSDTC settings for the BizTalk server and the SQL server are:

  1. Network DTC Access: This is required to be enabled.
  2. Client and Administration: Allow Remote Clients and Allow Remote Administration are not required unless you are using the MQSeries adapter. Otherwise, it is recommend that these settings be disabled.
  3. Transaction Manager Communication: Allow Inbound and Allow Outbound must be enabled. In the Transaction Manager Communication section, select Mutual Authentication Required. However, if MSDTC is clustered (if the SQL server hosting the BizTalk databases are clustered), Incoming Caller Authentication is required

Related Links:

Error “Server is not found or not accessible” while executing bts_ConfigureBizTalkLogShipping on SQL Server 2012 for BTS 2013

Log shipping provides standby server capabilities, which reduces downtime in the event of a system failure. Log shipping allows you to automatically send transaction logs from the source system to the destination system. At the destination system the transaction logs are restored to the BizTalk Server databases, keeping them closely synchronized with the source databases.

Couple of times I found this error “Server is not found or not accessible” while configuring the DR site by executing the stored procedure bts_ConfigureBizTalkLogShippingLog

exec bts_ConfigureBizTalkLogShipping @nvcDescription = ‘<MyLogShippingSolution>’,
@nvcMgmtDatabaseName = ‘<BizTalkServerManagementDatabaseName>’,
@nvcMgmtServerName = ‘<BizTalkServerManagementDatabaseServer>’,
@SourceServerName = null, — null indicates that this destination server restores all databases
@fLinkServers = 1 — 1 automatically links the server to the management database


1. DTC Connectivity between LIVE and DR SQL Instance.

2. There might be some firewall issue where only a particular port has been open to access the LIVE database server. In that case create an alias with same name as LIVE SQL database and then run the stored procedure.


Also refer the MSDN forum link

Secret of MSMQ adapter in BizTalk

For one of our customer we ran into this unique issue in DR environment during DR drill preparation.

The traces for one of the EAI application shows the delay of more than 10 seconds in BizTalk and the same application is working fine in other environments (UAT & PROD).

After further investigation we found the delay was from the time message gets into MSMQ to the time it is picked up by MSMQ adapter inside BizTalk.


We also tested the MSMQ independently for send/receive and it did not take much time.

Finally after doing some research work we came to know about of this secret of MSMQ adapter. The MSMQ adapter is designed in such a way that it will either wait for the batch size of 20 messages or wait for 10 seconds before it timeouts and process the incoming messages, whichever occurs first.

In our case the batch size of the MSMQ adapter for the application was 20 in DR environment and it is 1 in LIVE.  And we were testing the application only with a single message instead of a batch of 20 messages. Therefore, we see the 10 sec delay every time when the number of message is less than 20. When we changed the batch size to 1 then the delay of 10 sec was resolved.


Scaling-out from 1 to 3 MessageBox databases instead of 1 to 2

Scalability is ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth.

Since BizTalk works on SQL layer, it is very common to find bottlenecks in the MessageBox database during performance and scalability tests of a high volume BizTalk solution when you try to determine the Maximum Sustainable Throughput.

These bottlenecks can be:
1.  CPU  – In case of complex orchestration scenarios, the MessageBox database consumes a lot of CPU resources.
2.  Lock Contention –  Complex scenarios with multiple host instances or orchestrations tend to create lock contention on the MessageBox database.
3.  Disk I/O – Disk I/O is a common bottleneck for the MessageBox database.

One of the significant optimization step when dealing with scaling the BizTalk Message Box is adding new message boxes even when they are created in the same SQL Instance.

But you will need to add three message boxes to achieve the best performance. Why so?

Lets consider the 1 SQL server topology with 2 BizTalk Servers


Now lets say if CPU processing is a bottleneck, then if you add only one MessageBox database to this topology, the master MessageBox database will still be CPU bound and the secondary MessageBox database will be under-used.

If you disable publishing on the master MessageBox database and dedicate the master MessageBox database to do only routing, the secondary MessageBox database will do the publishing. However, this will not increase overall throughput because the secondary MessageBox database is the only publisher and becomes the bottleneck. So, adding 2 secondary MessageBox databases and disabling the publishing on the master MessageBox database is recommended for scaling-out in this scenario.


How to add multiple Message Box database in an existing BizTalk group


BizTalk Administration Console: Failed to load group [BizTalkDBServername: BizTalkMgmtDb] data providers – Access Denied

When we get the above error while launching the Admin console and expanding the groups in BizTalk server, we can refer the following links to resolve it.

If still the issue does not get resolved, try deleting the Microsoft.BizTalk.Administration.SnapIn.dll.config from Current user,  \<USER>\AppData\Local\Microsoft Corporation\Microsoft BizTalk Server folder . This folder is generally hidden.

We can also try collecting the BizTalk traces for further analysis of the root cause.