Since the arrival of BizTalk Server 2016, Microsoft added support for SQL AlwaysOn. It still is new to many BizTalk operators, administrators and developers. Often having been dealing with older versions of BizTalk.
Not many people have been dealing with SQL AlwaysOn already, so this post is for non-BizTalk geeks as well…
There was always the need for high available SQL environments. Companies want their data and systems running in a way that downtime can be minimized and SQL Server has a lot of solutions to that problem, one of them being SQL AlwaysOn.
When having dealt with a SQL Failover Cluster before, you might be tempted to use the Failover Cluster Manager to fail-over an availability group, however this is NOT a good choice when dealing with SQL AlwaysOn…
As every other developer working with Microsoft SQL Server on-premise, you probably already came in contact with SQL IDENTITY columns. They are commonly used and are pretty straightforward… or at least they seem that way.
As an architect I regularly use them in my designs, but there are a few quirks I learned along the way that some of you might not have encountered yet.
Disclaimer: I’m not a DBA nor is this article intended for DBA’s, this is mainly directed towards developers.
So, now that we got our DBA disclaimer up….. 😉
Here are some of the things you might now know yet…
Having a production system with “new technology” is always keen to give you some issues you didn’t know about earlier on.
Lately, due to the arrival of BizTalk Server 2016 and related support for Windows Server 2016 and SQL Server 2016, we’ve seen some things we did calculate for.
It seems the Failover Cluster Manager now has built-in support for automatic load balancing:
Update: this blog post pretty much says the same, however seems to have some more information on the issue and additional workarounds! If you want the details, check there, if you want the quick fix for Windows 10, this place is as good as it gets 😉
Today I came across several machines where I would not be able to connect via Remote Desktop, using RDP (Remote Desktop Protocol).
This was the error:
An authentication error has occurred.
The function requested is not supported
Remote computer: <redacted>
This could be due to CredSSP encryption oracle remediation.
For more information, see https://go.microsoft.com/fwlink/?linkid=866660
The issue did not have anything to do with connecting to an Oracle machine, so I was pretty much in the dark about this.
When integrating with GXS OpenText, I recently encountered an issue with an AS2 setup.
- You receive an inbound message over AS2.
- The AS2 client is setup to receive an asynchronous MDN regardless of the use of a encryption/signing or compression.
- You’ve setup a two-way send port to send out the asynchronous MDN.
- The two-way send port uses AS2Send and AS2Receive pipelines.
With this setup, we encountered the following AS2 error:
An output message of the component “Microsoft.BizTalk.EdiInt.PipelineComponents” in receive pipeline “Microsoft.BizTalk.EdiInt.DefaultPipelines.AS2Receive, Microsoft.BizTalk.Edi.EdiIntPipelines, Version=184.108.40.206, Culture=neutral, PublicKeyToken=31bf3856ad364e35” is suspended due to the following error:
An AS2 message was received that did not contain the AS2-From header..
The sequence number of the suspended message is 2.
A couple of months ago Glenn Colpaert & myself, both colleagues at Codit, announced that we both were “the brains” behind the CrazyBizTalk Twitter account.
Since then we’ve been receiving very positive feedback and lots of people have asked us to continue. Although it is tempting to continue with the account, we feel people may become biased by what we think is funny.
However, we also felt that Crazy BizTalk was more than us sending some funny tweets. The account should be opened to a broader public, this to allow people to make fun of their favorite integration topics in an anonymous, but verified and non-toxic way.
As a BizTalk consultant, it is always important to know the product and its features inside out. Knowing the cards you have to play with when designing a solution, gives you an advantage as you know what you can expect in certain situations.
The WCF-SQL adapter is certainly one of the better known adapters out there, so why decide to write yet another piece on it? There are already plenty of blog posts out there, yet I often find myself double-checking certain behaviors and I wanted to write something so I could refer to it at a later stage and help some people out less experienced.
I know there already is an excellent article up on TechNet around this topic, called Typed Polling with WCF-SQL Adapter: Best Practices and Troubleshooting Tips, but the article here will try to add some extra to that.