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.
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. 😉