BizTalk licensing, can standard edition have configuration database deployed remotely? - biztalk

So confusing about their license statement 'Single server solution/single message box', can the message box on another server?

Yes. Standard Edition allows the use of a remote (2nd server) SQL Instance.
You are also permitted to Cluster the SQL Instance(s) used for BizTalk SE.
You may not Cluster the Master Secret Server and you may not have more than one BizTalk Host Computer.

Regarding BizTalk licensing, "single server/single message box", means you will only have 1 BizTalk server having only 1 message box configured.
Keep in mind that the message box is "more or less" nothing more than an additional database in SQL server. You can put the BizTalk databases on a single SQL server instance, spread out over more than 1 instance or over more than 1 SQL logical server. It doesn't really matter. What you have to take care of, is to only have 1 BizTalk server running at all times for that specific environment and that that BizTalk server can only have 1 message box.
To be honest, having multiple message boxes for a single server could only do so much.
For more information regarding multiple message boxes, see the following link: https://msdn.microsoft.com/en-us/library/cc296848(v=bts.10).aspx

Related

Is it possible to have 2 BizTalk Server nodes running off of a single MessageBox?

Myself and my colleagues are currently in the process of upgrading our BizTalk environment to BT 2020 from BT 2013R2 and as part of this we are intending on setting up two BizTalk servers so that we can have host instances running across both of them. We do not, however, need more than one MessageBox DB based on the load we see, and after looking online, there doesn't seem to be a breadth of information.
Is it possible to have our BT setup to have 2 servers running off of a single MessageBox and is it complicated to configure?
It’s the basic feature of BizTalk to have multi servers group connected to same message box. On your second computer, when you configure BizTalk using BizTalk Configuration Wizard, you choose option to join existing group and you should select your existing dbs to join.
Microsoft Docs Install BizTalk Server in a Multi-Computer Environment

Some BizTalk Receive Locations are disabled after server reboot

It is found that some BizTalk Receive Locations are disabled after server reboot (BizTalk server and SQL Server are separately installed to different physical servers)
Is there any idea on this scenario? Due to the boot sequence or other issues?
I will assume that, once you enable the receive locations manually, they are working correctly.
Typically, when FILE receive locations fail while pointing to an external server/share, it is because they are no longer available.
Make sure that, during the night, there are no network issues, planned/unplanned downtime of the share (= here your SQL server). A BizTalk receive location will retry to access a share for quite a while before disabling itself. Check the event log(s) for more information. You would want to look for errors/warnings there indicating an issue with connectivity between BizTalk and SQL.
Another issue might be that there are too many connections between your BizTalk server and SQL server. You can provide a maximum number of connections in the FILE share properties.
Also, you could try this link: https://serverfault.com/questions/235032/intermittent-connection-to-windows-7-shared-folder-from-windows-xp-workstations
It describes a potential fix for optimizing throughput for file sharing, although it depends on your operating system.

How to set up a BizTalk active/active cluster

I am setting up a virtual environment as a proof of concept with the following architecture:
2 node web farm
2 node SQL active/passive fail-over cluster
2 node BizTalk active/active cluster
The first two are straight forward, now I'm wondering about the BizTalk cluster.
If I followed the same model as setting up SQL (by using the Fail-over cluster manager in windows to create a cluster) I think I would end up with an active/passive cluster.
What makes a BizTalk cluster Active/Active?
Do I need to create a windows cluster first, or do I just install BizTalk on both machines and configure BizTalk appropriately?
Yes, my understanding is that you do need to cluster the OS first.
That said, you can usually avoid the need for clustering unless you need to cluster one of the 'pull' receive handlers like FTP, MSMQ, SAP etc. For everything else IMO it usually makes sense just to add multiple BizTalk servers in a group, and then use NLB for e.g. WCF Receive adapters.
The Rationale is that by running multiple host instances of each 'type' (e.g. 2+ Receive, 2+ Process, 2+ Send, etc), is that you also have the ability to stop and start host instances without any downtime, e.g. for maintenance (patches), application deployment, etc.
The one caveat with the Group approach is that SSO master doesn't failover automatically, although this isn't usually a problem as the other servers will still be able to work from cache.
You can configure a BizTalk Group in multi-computer environment. You can refer to the doc available at MSDN download center for more details. The document specifically has a section titled "Considerations for clustering BizTalk Server in a Multiple Server environment"
You can also additionally configure your BizTalk host as a clustered resource. You can refer to the documentation available at MSDN for more details.

SAP receive adapter high availability

We are having a active-active BizTalk cluster with windows server as software load balancer. The solution includes a SAP receive adapter accepting inbound rfc calls. The goal is to make SAP adapter high availabile.
Read the documentation (), it does says 'You must always cluster the SAP receive adapter to accommodate a two-phase commit scenario.' and 'hosts running the receive handlers for FTP, MSMQ, POP3, SQL, and SAP require a clustering mechanism to provide high availability.'
What we currently did in both the active-active node for BizTalk, we have a host instance enabled. With refering to above documentation, does it mean we did it incorrectly? We should take the clustered host instance instead the active-active deployment?
thanks for all the help in advance.
You need to cluster the host that handles the SAP receive. What this means is that you will always have only one instance of the adapter running at any given time and if one of the server goes down, the other will pick up.
Compare this with your scenario where you simply have two (non-clustered) instances running concurrently: yes, this gives you high availability - but also deadlocks! The two will run independently of each other... With the cluster scenario above, they will run one at the time
To cluster the SAP receive host: open the admin console, find the host, right-click and Cluster.

BizTalk: Should I care this: "Failed to recover from previous error. Database: BizTalkMsgBoxDb"

BizTalk Server complains from time to time:
Reading error. Failed to recover from previous error. SQLServer: XXX, Database: BizTalkMsgBoxDb.
Should I care this, or simply ignore it?
Looks like a temporary loss of connectivity to the MessageBox. Not good, but also not critical as long as connectivity is restored quickly enough. The specific error message relates to BAM, which you can switch off if not being used. However, the problem will affect BizTalk as a whole.
You would have to find out what's causing the loss of connectivity and address that. Might not be easy, mind you, I have seen this happening on DEV boxes with both BizTalk and SQL Server on the same box...
BizTalk Server 2006: BAM FAQ
As per Fabio, the message you received is likely to be specific to BAM.
The types of error that you get in your eventlog if BizTalk hosts and ENTSSO does lose connectivity with SQL are listed here
These errors are more serious and can result in the loss of messages (Hosts and Receive Locations are usually stopped).
These errors can occur intermittently and then a minute or two later you see
Communication with MessageBox BizTalkMsgBoxDb on SQL Instance XXX has
been re-established
Common causes of BizTalk : SQL Connectivity issues are listed here
We've found the usual culprit of connectivity issues to be the TCP/IP SynAttackProtect security feature on the SQL Server host - BizTalk can hog a lot of SQL Connections, especially during a 'ramp up' of connections required when a batch of messages comes in after a protacted idle period.

Resources