Recently, I encountered a strange problem at a customer. MSDN blogs warned us about the leap year date 2/29/2012 when using EDI in BizTalk Server 2006 R2 or 2009, as you can see on this blogpost. It was during the install of this hotfix on a BizTalk 2006 R2 server I was encountering the problem. I’ll explain the problem over here and show you the easy work around. EDIT: Apparently Microsoft has solved this error. A more recent version of the hotfix download does autodetect Cumulative Update 3, without using a version number. The latest version of the hotfix can be found over here. However, I will show you how I worked around the problem (because the newer version was not yet available at that time).
MSDN blog is indicating that the install of the EDI leap year hotfix on BizTalk Server 2006 R2 requires some prerequisites. Since BizTalk 2006 R2 Service Pack 1 was already installed in this particular case, I only still needed to execute step 2 and 3. Installing the Cumulative Update 3 gave me no problems. So far, so good.
Install of the leap year date hotfix itself
However, when installing the leap year hotfix, I encountered following error:
“The patch 861c5534-6cfa-4dcf-ba70-cbf01129b646 in the package Microsoft BizTalk Server 2006 R2 Hotfix [See KB article 2435900 for detail] cannot be applied. The minimum installed version of Microsoft BizTalk Server 2006 must be 3.6.2222.12. The installed version on this computer is 3.6.1404.0.”
This was quite strange to me, since MSDN blog was indicating that Service Pack 1 and Cumulative Update 3 should be sufficient as prerequisites to install the hotfix. A little investigation led to the following.
Checking the Registry Editor (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0), showed us that the current product version is ‘3.6.1404.0’.
This is just like the error indicated, while it expects a version of 3.6.2222.12 or higher. So I started searching the web to check if that Product Version Key was correct and related to BizTalk Server 2006 R2 SP1.
BizTalk Server 2006 R2 SP1 Product Version Key
On a Microsoft Technet wiki page I found following table with the all product version key’s correlated to the product name:
What you can see over there, is that the Product Version Key is not adapted when Service Pack 1 of BizTalk Server 2006 R2 is installed. This is not consistent if you compare it with the other version of BizTalk Server.
Strange thing, BizTalk 2006 R2 SP1 comes with Product Version Key 3.6.1404.0, while the install of the hotfix needs a version of 3.6.2222.0 or higher. Because the prerequisites for the hotfix (BizTalk 2006 R2 SP1 and CU3) were correctly installed and yet the Product Version Key seemed not to be right, I started thinking about a possible solution to fix this little error.
Workaround for the error
Since installing the hotfix for the leap year date is all about just running a ‘Setup’ and there’s also a Setup.xml file in the folder, I had a look over there.
As you can see in the print screen below, there indeed is a field ‘MinProductVersion’ indicating the version should be at least 3.6.2222.12. This is why we encountered the error.
So what about changing this value to a Product Version lower than 3.6.1404.0, the one that is installed on the server now? Let’s give it a try.
NOTE: make a copy of the original Setup.xml, in case the change would not be effective.
As you can see below, I changed that one value in the xml document to ‘MinProductVersion = “188.8.131.52” ‘.
Before executing the Setup again, and hoping it will not fail on the Product Version again, we need to find a way to check if the setup will be executed effectively.
In the Setup xml file we can see some assemblies that will be adjusted to a newer version when executing the hotfix. Therefore we can check the current file version of a specific assembly and see if the file version has been changed after the execution of the Setup.
For example, we can see in the setup xml file that 'Microsoft.BizTalk.Edi.Shared.dll’ should have version 3.6.2230.12 after the execution.
A quick lookup shows us that the file version of that assembly is '3.6.2224.12’ right now.
If we now execute the Setup and check this file version of the assembly again afterwards, we should see it’s changed to '3.6.2230.12’ if the Setup was successful. Let’s try this!
I executed the Setup again and did not encounter the same error again, indicating the product version is too low. So that’s a good start. Now that the wizard indicates the execution has successfully ended, let’s have a look at the file version again.
And yes, the file version was changed to 3.6.2230.12 and therefore the assembly was updated. Together with the fact that our newly installed hotfix is shown in the 'Installed programs and updates’-overview (as you can see below), we can conclude that our workaround for the error and therefore the installation of the hotfix itself has been successful!