So which should you install? I’ve seen people post a few questions about installing Feature Packs in conjunction with Cumulative Updates and here is my advice and reasoning.
For BizTalk 2016 Enterprise, always install the latest Feature Packs only. Your server will be up to date and contain some extra features you may need later, even if you don’t need them now. Feature Packs are only available for Enterprise, are cumulative and contain both the previous Feature Packs and all the CUs so no need to install those separately.
For BizTalk 2016 Standard or Branch, always install the CUs only.
For BizTalk 2016 Developer, you will want to keep this in line with whatever your Production server has.
Mixing CUs and Feature Packs either causes the installation to fail, or can cause strange issues. e.g.
Below a list of know bugs, issues, & other quirks* of BizTalk 2013 R2 (mainly CU3) and Visual Studio 2013 (update 4) , but I will update with fixes as the CUs come out or when I know about a new issue, so if you have another one I will add it (and link to it if you have a blog about it) if you let me know. This in addition to the ones listed by Microsoft on Known Issues in Installation, Configuration, and Deployment
I’ve now posted the below article on a TechNet wiki
* My definitions for classifying these are Bug: Causes negative impact and no known work around or requires a lot of effort to work around. Issue: Causes negative impact but has an easy or quick work around. Missing: A feature that BizTalk doesn’t have that would make our life easier. Quirk: Something strange or unusual but does not cause a negative impact so far as known.
To maintain a high level of security and reliability, BizTalk Group requires a master secret server cluster to provide redundancy for the Single Sign-On (SSO) services.
To ensure that the SSO services in the BizTalk Group remain available even in the event of a failure, we configured a separate master secret server cluster on SQL Server AOG. This setup involves the deployment of multiple servers that work together to provide high availability for the master secret services. In this way, if one server fails, the other servers in the cluster take over and maintain the availability of the SSO services.
Despite the setup working fine, we occasionally encountered an error after a failover happened in the SQL cluster after a day of inactivity. The error message was: ‘Both SSO Servers (server names) Failed. Backup server failure. Cannot Perform Encryption…
If you run BizTalk Health Monitor and get the above warning, take it seriously and escalate it to the database support. This usually occurs when the database support team decides to use it’s own database backup methods. But Microsoft have made it very clear that this is not supported.
The Backup BizTalk Server job is the only supported method for backing up the BizTalk Server databases. Use of SQL Server jobs to back up the BizTalk Server databases in a production environment is not supported.
If the Backup BizTalk Server job is not run, the BizTalk Server database transaction logs will grow unbounded. The backup job truncates the transaction logs, which keep them from growing unbounded. If the BizTalk Server database transaction logs continue to grow, they could at some point fill the disk they are housed on.
Note
Using both the Backup BizTalk Server job and log shipping is currently the only fully documented and supported method for performing BizTalk Server database backup and restore.
Also of note are the version of components you will need.
Updated External Dependencies
Dependency
Updated version
WinSCP
5.19.2
Newtonsoft.Json
13.0.1
WindowsAzure.ServiceBus
6.2.0
Saxon-HE
9.9.1.7
Microsoft.Identity.Client
4.36.0
Microsoft.ApplicationInsights
2.18.0
If you have BizTalk Developer Tools installed, you must install the latest version of BizTalk Server Visual Studio extension (build 3.13.2.0) in addition to this CU package. The extension can be installed from https://marketplace.visualstudio.com/items?itemName=ms-biztalk.BizTalk or from within Visual Studio through Manage Extensions.
Sometimes you come across BizTalk Projects that have been checked into source control, but someone missed checking in the AssemblyInfo.cs file
When you let Visual Studio create a new one, it all builds fine, but when you try to deploy it, you get weird errors about not having permission to the DLL in your Local user profile.
Error 3 Access to the path ‘C:\Users\USERNAME\AppData\Local\Temp\5\BT\PID34764\BizTalkAssembly\175958c71880b4092ef846ff9349619b\BIZTALK.dll’ is denied. 0 0
Trying to manually add the DLL to BizTalk will complain that the DLL is associated with another Application.
Removing the resource and then manually adding seems to work, but then it doesn’t recognise it as a BizTalk Assembly, and your artifacts such as Orchestrations, Schemas and Maps will be missing.
To fix this you need the following line after the AssemblyFileVersion line.
This question “Do you require BizTalk Server licenses for Enterprise SSO on SQL Server?” has come up several times for me at work recently, as apparently some software licence monitoring tools pick up the fact that SSO is installed on the SQL Server used for BizTalk, and that it does not have a licence.
To reduce the hardware resources for a highly available solution, you can add the master secret server as a cluster resource in your SQL Server cluster. Note that you do not need to purchase additional BizTalk Server licenses to install the SSO service on the computer running the SQL Server.
Review of the Book, Migrating to BizTalk Server 2020
This book is written by Sandro Pereira, Tom Canter and Lex Hegt, all well known people in the BizTalk sphere. After the dedication about the Authors the introduction starts with an interesting brief history of the various BizTalk Server and then dives straight into what this book is for and what it covers, which unsurprisingly is about how to migrate from earlier version of BizTalk to the latest version Microsoft BizTalk Server 2020. And that is just the introduction.
The next chapters give an Overview of BizTalk Server 2020, what might be some of the reasons why you would want to upgrade; what you need to do to prepare for the migration; the options of doing an in-place upgrade (but also covers why you shouldn’t do this); migrating in a side by side way; and also looks at the option of migrating to Azure. Lastly it has an Appendix that list the BizTalk Dependencies their EOL (End Of Life), which can be one of the justifications you need for an upgrade.
All in all a very comprehensive book and something that you should read if you do have some older BizTalk environments that you are planning to migrate away from. As I’m currently in the midst of a project to migrate of both BizTalk 2010 and BizTalk 2016 to BizTalk 2020, this book has already proven valuable.
Microsoft has announced that mainstream support for BizTalk Server 2020 has been extended from January 9, 2024, to April 11, 2028, details here. This change will not affect the overall end of support date of April 9, 2030.
Before you get your hopes up, this is not a How To of sending messages via email using BizTalk, instead this is advice not to do it. Why is that you ask? See my reasoning below, feel free to use this to tell your boss/solution architect/client etc. as to why they shouldn’t implement a solution that sends business documents via email, except when they go to a person, rather than a system.
There is no interface contract
Unlike web services there is no WSLD or Swagger to define the interface, so how it is implemented at both ends is usually very loose. I’ve seen multiple solutions in Production that relied on messages received by email break when the sender decided to change how they were sending the payloads without notice.
It is insecure
It is ridiculously easy to spoof a From address or use a fake address that looks similar to the real one, and unless the receiver uses SPF, DKIM or DMARC the receiving mail server and system will not notice.
By default emails are sent un-encrypted, this could leave you open to a man in the middle attack where payloads are altered. So you have to encrypt or de-crypt in the MIME pipeline, and exchange certificates.
By default emails are digitally unsigned, so receiver cannot verify with 100% accuracy that the payload was sent from your system unless you go to the trouble of signing the payload and the receiving system verifies.
The authentication options to send emails are Basic, which sends credentials in the clear across your network, NTLM authentication (which is also vulnerable to chosen plaintext), or your mail server needs to be set not to authenticate client apps that are sending emails. The standard BizTalk SMTP adapter does not support SSL/TLS connections either. So you would have to use something like Stunnel as per an answer in the thread BizTalk 2016 SMTP/POP3 with TLS 1.2
SMTP Authentication types
For receiving emails your choices are Basic, Digest and SPA, but at least there is a Use SSL option available so your credentials aren’t sent in the clear. Note Use SSL probably also enables TLS, as the SSL protocols are deprecated and disabled in most systems.
POP3 Authentication Scheme
It is unreliable
There is no guaranteed delivery with emails. Email servers can occasionally start treating legitimate emails as SPAM, and then the emails and payloads are never received by the receiving system.
There us usually no acknowledgement mechanism that the email has been received* and processed. So again if you want that then the receiving system has to send an acknowledgement back somehow.
* as this mechanism was heavily abused by Spammers and so disabled on most mail servers.
It is complex to implement
There are also sorts of pitfalls when you try to send emails with documents attached, in getting it sent in the first place (security), how it is sent (body or attachment), getting the attachment names correct, and even the encoding of the attachments can cause issues, at one point there were three different standards for attachments, and usually the receiving system would only support one or maybe two of those.
For example, some Stackoverflow question over the years.
BizTalk musings 