Wow, it has been a long while since I wrote a post about good old BizTalk! But we had some interesting findings this week trying to run an in-place upgrade from BizTalk Server 2013 to BizTalk Server 2020.
I know that in-place upgrade is one of the cardinal sins of BizTalk, together with not running the BizTalk database jobs or having a single host to rule them all! But before you take my BizTalk fan club membership card, just understand that we had 5 different environments and so much red tape and reconfiguration for a side by side upgrade, that it was worth taking the risk.
And here is what we found during this process. I say we because although I helped troubleshooting, one of the best consultants from my team, Peter Kenyon, had the pleasure of experience this particular kind of hell – I am pretty sure I owing lunch after all of that…
What did we find…
Before you start… Operational System Upgrade
We had a small gotcha when trying to upgrade the OS. The client decided that they would be using Windows Server 2016 and SQL Server 2016, which would match the other servers currently installed. The environment where we were doing the proof of concept was an Azure environment, which we use for system testing – we wanted to find all the gotchas on an environment that would be easy enough to back up and roll back, but also use an environment matched as close as possible their production environment (at least from a configuration and installed applications).
One thing that we didn’t realized until we actually tried is that not all versions of Widows Server are supported by Windows Azure VM. So the upgrade from Windows Server 2012 to Windows Server 2016 failed miserably. We’ve managed to get a machine that would support BizTalk, by upgrading the OS to Windows Server 2019 instead.
No direct path from 2013 to 2020
After our little adventure upgrading the OS, we also found that that there was no direct path from BizTalk Server 2013 to BizTalk Server 2020. The steps for installation must be 2013 > 2016 > 2020.
So make sure that if you are in the same situation as we were, you have both the ISOs handy (2016 and 2020).
While we are talking about BizTalk Server 2016, it is worth mentioned that the version of BTDF that runs on BizTalk Server 2013 is not supported on BizTalk Server 2016. So also make sure that as a post implementation step, you install the BTDF version compatible with BizTalk Server 2016. In our case we had a dependency on a SSO reader component that was complained until we updated the reference on GAC. It is important here to notice that although the BTDF SSO component still worked at runtime for BizTalk 2020 – after all it is just a .NET component in a supported framework, we didn’t try to compile new solutions using the existing BTDF framework.
SQL Server 2016 was installed but not recognized
That was probably the most strange (and in a way annoying) of all the little issues we had. Once we’ve completed BizTalk Server 2016 upgrade, installed with SQL Server 2016 SP2, when trying to install BizTalk Server 2020, we received repeatedly the following error:
After a couple of restarts, opening a support ticket and contacting the product group, we’ve decided to try to install the latest cumulative updates. After installing SQL Server 2016 CU 12, the installation worked as expected. We wondered if the installer was looking to a minimum version number which didn’t match SQL Server 2016, or SQL Server 2016 SP2, but matched Cumulative Update 12.
Summary
So there we go. If you ever is backed to a corner where you need to do a in-place upgrade from BizTalk Server 2013 to BizTalk Server 2020, those are the things you will need to keep in mind:
- If doing that on Azure, make sure that the OS you choose to upgrade to is supported by Azure
- Have the ISOs handy for both BizTalk Server 2016 and BizTalk Server 2020
- If you are using BTDF components during runtime, make sure you also upgrade BTDF
- If you are using a version of SQL Server that is not the latest supported, install the latest Cumulative Updates just in case.
As a last note, I really hope you don’t need to use this post… Ever. 😉
Interesting.
I have been working on extending BizTalk to become an HL7 FHIR Server. Adding the HL7 FHIR Rest API as an Adapter is about completed. The BRE is going to handle the majoring of the mapping.
That is interesting mate!
Would like to see a bit more about that. Hopefully you will be writing something about it. Let me know and I can link it up!
“…the version of BTDF that runs on BizTalk Server 2013 is not supported on BizTalk Server 2016.”
The final version of BizTalk you installed is 2020 – are you saying that the version of BTDF that worked with 2016 also works with 2020? Is the only component of BTDF used the one for SSO Config access or is BTDF used for application deployment as well? Currently, BTDF has not been upgraded to work with BizTalk 2020, at least not in Visual Studio (https://github.com/BTDF/DeploymentFramework/issues/464).
Hi Simon,
We didn’t try to use BTDF as the deployment agent yet, but the runtime SSO configuration worked as expected. Which makes sense, because as far as I understand BizTalk 2020 is simply BizTalk 2016 + FP3 packaged together, with some additional adapters and the deprecation of some of the items. So take this mainly as runtime support, not design support.
That is a good point though, so I will make sure I update the post to reflect that!
I wonder if Microsoft could provide a BizTalk installer to upgrade the OS for you to Windows Server 2016 (or 2019) if you are on Azure VM and upgrade SQL Server to 2019 (or optional 2017) before installing the main BizTalk 2020 product. (Similar to many other installation it provides).
They can use (your) Microsoft Account on the Windows server OS as there are supported since Windows Server 2012 to grant access to these prerequisites.
Especially if it is the OS’s whole purpose of running BizTalk, which is likely as using a dedicated machine is justified as BizTalk often runs its organisation core intersystem communications.
If that suggested installer would be on extended support which only end 11 july 2023 instead of mainstream support.
source:
https://social.msdn.microsoft.com/Forums/en-US/50b3701d-8b7c-4283-80f4-73717f1618b7/biztalk-2013-r2-and-windows-7
Hi , did you upgrade from biztalk 2013 ?? according to link below (check Supported upgrade paths) ,only 2013R2 can be upgraded and 2013 must be recreated .. will be happy to get your inputs and advice..
https://learn.microsoft.com/en-us/biztalk/install-and-config-guides/upgrade-to-biztalk-server-2016
Hi Ori,
Before we did the in-place upgrade in this particular case, we had to upgrade SO and SQL. Although this shows that is feasible, when I was engaged with this type of projects, I would usually prefer doing a side by side migration (e.g. recreate the environment and redeploy the apps).
thanks for reply !
unfortunately looks like i will need to do in place upgrade from various reasons..
so wanted to verify again , did you start from biztalk 2013 or 2013R2 ?
(you upgraded 2013 directly to 2016 ? )