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.