BizTalk, BizTalk Server 2013, Licensing

BizTalk Server 2013 Developer Edition arrives

Microsoft BizTalk Server 2013 Developer Edition New SKUs and Changes

Effective November 1, 2013, Microsoft BizTalk Server (BTS) 2013 Developer Edition licenses will be available under the Developer Tools license model in the Open, Select Plus and Worldwide Government Partner programs. Previously offered as a free download in prior BTS versions, the new BTS 2013 Developer Edition offers the full functionality of the
BTS 2013 Enterprise Edition, licensed for development and test use only, and includes the newly released Host Integration Server (HIS) 2013 software.


You will also find it if you run the Microsoft License Advisor at


The Developer Tools license model

Previously with BizTalk Server 2010 you have bought BizTalk Server Licenses for servers only (Branch, Standard and Enterprise). The Developer Edition was free. With 2013 you must purchase this license per user, if they do NOT have MSDN. This is a per user license.

You must acquire a license for each user you permit to access or use the software. You may install any number of copies on any number of devices for access and use by one user to design, develop, test and demonstrate programs. Only licensed users may access the software.


My interpretation of “access the software” (but I am not a license expert!) is that it is ok for BizTalk Server to exist in a test environment where it routes traffic and perform integrations to and from other systems that at their end have users, devs or admins that are not licensed. It is also ok for other users of the same server to access the server where BizTalk is installed to, for example, administer Windows (as long as that in itself is properly licensed). The limiting factor are the users that in some form access the BizTalk Server software itself. Such as deploy, configure, administer or in other ways interact with the BizTalk Server GUIs or services.

Price Lists

Target prices seems to be around $37 Estimated Retail Price (ERP).


I have also seen $36 for price level C.


To those with an MSDN subscription ( the list of subscription types that has access to this seems to be quite large:

VS Pro with MSDN (VL)
VS Pro with MSDN Premium (Empower)
VS Pro with MSDN Premium (MPN)
VS Test Pro with MSDN (Retail)
VS Test Pro with MSDN (VL)
VS Ultimate with MSDN (MPN)
VS Ultimate with MSDN (NFR FTE)
VS Ultimate with MSDN (Retail)
VS Ultimate with MSDN (VL)
BizSpark Admin
Designer AA
DreamSpark Premium
DreamSpark Standard
MSDN Platforms
VS Premium with MSDN (MPN)
VS Premium with MSDN (Retail)
VS Premium with MSDN (VL)
VS Pro with MSDN (Retail)

See screenshot:


How do I get it?

Summarizing from above you would either have an eligible MSDN subscription, or you get it through traditional volume licensing channels.



How the per-core licensing model will (by my guess) affect how we build BizTalk environments today

SQL Server 2012 comes with a new licensing model. Instead of per processor socket you will pay per core. Licenses are sold in two core packs with a minimum of four core licenses needed per physical processor (even if that processor only has two cores). The price per core is about one quarter (1/4) of the price per processor today. This means that the price for anything but quad core processor architectures will either go up, in the case of hexa core processors, or will give you less value then what you are paying for, in the case of dual core processors.

As far as how you would design your environments to keep the value without increasing the cost that means going with quad core as far as possible instead of for example hexa core. Especially if you are not sure you need that extra bit of processing power.

Although this change is explicitly announced for SQL Server and so far does not extend to BizTalk Server, the way the development of processors is and has been moving over the last couple of years it stands to reason that this may very well be (and by my guess will be) extended to other products in the future. The change is inevitable.

Therefore, today I would opt for quad core processors over hexa core if I use physical servers, in both SQL and BizTalk, to get a smooth transition to new licensing models.

Or at the very least, think twice before you go on old preferences and choose as many cores as possible just to get the most value out of the current licensing model.

Virtualization stays pretty much the same, that is, either pay for the virtual cores or for the physical cores (under the same rules as stated above).

At this point in time this is not new information. For licensing technicians this is a well known fact, but for other technicians or architects, this information might not have surfaced yet.


BizTalk, Licensing, Maintenance

Why BizTalk Server 2010 R2 should be BizTalk Server 2013

That BizTalk Server 2010 will have a successor and that the working title of that release is BizTalk Server 2010 R2 was announced at the BizTalk Server team blog in december 2011 and re-announced by folks like Kent Weare, Charles Young, Saravana Kumar, Steef-Jan Wiggers among others.

What some of them hints at but doesn’t discuss further is that the version naming “2010 R2” might not stick. There are good grounds for such guesses. Historically BizTalk Server 2009 was initially called BizTalk Server 2006 R3 before the renaming was announced and BizTalk Server 2010 was called BizTalk Server 2009 R2 when first announced before it too was renamed.

One might argue that the R2 is a good suffix in this release since it is a minor release, without an abundance of new functionality. That’s true.

One might argue that there is only so much to a name, the important thing is that Microsoft is showing that it will continue to maintain and carefully evolve the product. Not so I say.

There is one very important thing that goes into that name that should not be overlooked or underestimated – the support lifecycle. Microsoft’s support lifecycle policy says that products will have 5+5 (mainstream+extended) support. However, that applies to major versions. An excerpt:

“Minor releases follow the same Support Lifecycle as the major product release.

An example of this is Windows Server 2003 R2 which has the same Mainstream Support phase and Extended Support phase dates as the parent product, Windows Server 2003. Likewise, Windows Server 2008 R2 follows the same Support Lifecycle dates as the initial release of Windows Server 2008″

If the product will be BizTalk Server 2010 R2 (and assuming it will follow the general rule), it will not get an extended support lifecycle end date. Except for what is stated in the general policy you can see examples of this scheme throughout the product chain. BizTalk Server 2006 and 2006 R2 are the closest examples, but also Windows Server 2008 and 2008 R2, and SQL Server 2008 and 2008 R2 both follow suit. In all these cases the R2 version does not start a new 5+5 year period. Where as with BizTalk Server 2006 R2 to BizTalk Server 2009 and again to BizTalk Server 2010, we got new lifecycle support dates.

One of the major asks around BizTalk Server before the announcement was for Microsoft to clearly show its continued support for BizTalk Server as a product – they did that, but here is hoping that they will strengthen that statement further by giving us a BizTalk Server 2013 (or 2012).


BizTalk, Licensing

BizTalk Per-Proc Licensing DeepDive

Now that I feel I’ve finally reached the bottom of this pit, travelling the last distance in pitch black before finally reaching the bottom, I felt a post was in order. I am however not a licensing expert so I might still take a step to the side here and find myself in a free fall again (a.k.a. I might be wrong). The goal of this post is both to inform and to be informed and I’d be just as happy if someone contradicted me as if they agreed with me by commenting. I’ve made more then one assumption, clearly marked as such, that may or may not be correct although they are what I currently believe to be right.

BizTalk Server is licensed using the Per-Proc licensing model. There are a couple of easy references that most everyone looking at licensing will have read and know.

First of there is the Multicore processor licensing site that clearly state that licensing is done per proc and not core (but everyone knows that by now) –

Then there is the BizTalk pricing and licensing FAQ (at and the questions (the quoted anwers are not word by word, they are more my interpretation)
Q: "How is BizTalk Server licensed on computers that have more than one CPU?"
A: …Std Ed needs licenses for all procs available to windows even though it has a technical limitation of two (…
Q: "Does BizTalk Server 2010 allow for virtualization?" 
A: …Yes…Ent can be licensed on the physical servers procs running any number of virtual machines with BizTalk on them.

Then there is the volume licensing site for BizTalk Server 2009 / 2010 at which helps mostly just by pointing out the same basics. It explains how the product uses Per-Proc licensing and that you license on either physical or virtual procs and for Enterprise you can also use the “license physical procs and run any number of virtual procs” options.  It also points out the current PUR (Product User Rights) document (available at MicrosoftProductUseRights(Worldwide)(English)(December2010), listing in different languages at that basically just repeats those same things with better formatting (ie, read that instead since the website really makes some parts hard to read). Per-Proc licensing starts at page 59.

This is an interesting section:

A. General License Terms. You have the rights below for each server you properly license.

I) Licensing a Server. Before you run instances of the server software on a server, you must determine the number of licenses required and assign them to that server.

a) Determining the Number of Licenses Required. The number of licenses required is based on either the total number of physical processors on the server (as described in option (i) below) or the number of virtual and physical processors used (as described in option (ii) below). For Enterprise Editions of the software, you may follow either option. For all other editions of the software, must follow option two.

i) Unlimited Virtualization. Under this option, the number of software licenses required for a server equals the total number of physical processors on that server. Counting and assigning licenses based on this option permits you to run the server software in one physical and any number of virtual operating system environments (or OSEs) without regard to the number of physical and virtual processors used. This option is available to you only for enterprise editions of the software.

ii) Licensing based on Processors Used. Under this option, the total number of software licenses required for a server equals the sum of the software licenses required under (A) and (B) below. This is the only option available to you for editions other than enterprise.

(A) To run instances of the server software in the physical OSE on a server, you need a software license for each physical processor that the physical OSE uses.

(B) To run instances of the server software in virtual OSEs on a server, you need a software license for each virtual processor1 that each of those virtual OSEs uses. If a virtual OSE uses a fraction of a virtual processor, the fraction counts as a full virtual processor.

1 A virtual processor is a processor in a virtual (or otherwise emulated) hardware system. Virtual OSEs use virtual processors. Solely for licensing purposes, a virtual processor is considered to have the same number of threads and cores as each physical processor on the underlying physical hardware system. So, for any given virtual OSE on a server on which each physical processor provides X logical processors, the number of licenses required is the sum of a) and b) below:

a) one license for every X logical processors that virtual OSE uses

b) one license if the number of logical processors it uses is not a whole number multiple of X

X,” as used above, equals the number of cores, or where relevant, the number of threads in each physical processor.

Ok, so you can either license using the unlimited virtualization option mention before, or per physical processor when installing on a physical machine – it will always be a one to one mapping at that point between processor and license, or you can also license per virtual processor. Here is were it gets muddy. Virtual processor… what’s in that term? You might at first think that it means a processor as it is visible to the virtual machine. In case of the below picture… 4.


You’d be wrong.

The text that tries to explain the essence of a Virtual Processor is difficult to interpret – for me at least, but then I ‘m a foreigner so you native US or other english spoken nationals might have no problem with it. You will find no further explanation in the above document. Enter the “Licensing Microsoft Server products in Virtual Environments” document (

This brief (at page 14) talks about the physical cpu (and core) to virtual cpu relationship. Mostly the point being made is that even though cores from more then one physical cpu gets used – like two cores being used in a dual-core machine still just counts as one virtual proc and one license. What I don’’t like with this document is that I think the images are somewhat confusing as it constantly uses 2 procs and two cores and it seems to put those cores into the same virtual socket (I borrowed the picture for clarity).


Now it also states that even if you use just one core you will still need to pay for one license, which is an important note. As in “Never do that for BizTalk”.

It also does some attempts to count licenses under some sample deployments (on page 19) but (to me) it falls short here as well.

Now two find a better explanation to the above pictures… Enter the LadyLicensing blog and a post about the per-proc licensing of SQL Server. Now granted SQL Server and BizTalk Server is NOT the same product, but I assume that the licensing rules at this point that the licensing rules around per-proc licensing is shared since I’ve found no indication of otherwise.

Now I’ll use her visualization (since it really cleared things up for me) but redo it for BizTalk:

1. Gather the following data points of A B C

2. Calculate licenses needed


In this sample this would be filled in as:


Now that’s basically as clear as it can be, right? Well, yes, but…

With virtualization a virtual processor is often thought of as a core (at least I, not being an virtualization expert, do), and the sample above I assumes that is the case.  In Hypervisors a virtual proc is really just something assigned a timeslot of execution. By default on both ESX and Hyper-V it seems to be the case that when a virtual processor is given time to execute this happens on a core. On both ESX and Hyper-V, through settings cpuid.coresPerSocket and “Virtual machine reserve” respectively, it is possible to equate virtual processors to a whole (or larger part of a) physical processor. I believe that in Hyper-V this does nothing for it’s representation in the virtual machine as other then a single processor, but in ESX makes it appears as a multi-core processor. In this case I am unsure, but I feel that a better fit for A in the calculation above then becomes “# physical cores used by virtual processors” rather then virtual processors, which is not nearly as clear. Now, how is this setting useful?

Well, remember Standard Edition technically merely supporting two processors? I don’t know for sure of course, but I feel pretty confident saying that if you have four virtual processors, which then maps to one license, BizTalk Server Standard will look at that as four separate processors and just use two even though that (kinda) maps to two cores. So these settings might be worth looking into.

I am also not certain that the number of Enterprise licenses that would be needed is really correct, but I’ll get back to that later.

Another interesting point I’ve come across is this (taken from the PUR):

Under General License Terms for Per-Proc licensed servers…

a) Assigning the Required Number of Licenses to the Server.

i) After you determine the number of software licenses you need for a server, you must assign that number of software licenses to that server. That server is the licensed server for all of those licenses. You may not assign the same license to more than one server. A hardware partition or blade is considered to be a separate server.

ii) You may reassign a software license, but not on a short-term basis (i.e., not within 90 days of the last assignment). You may reassign a software license sooner if you retire the licensed server due to permanent hardware failure. If you reassign a license, the server to which you reassign the license becomes the new licensed server for that license.

Basically – you have to guarantee that your virtual machine always is activated on one and only one host. It cannot “float around”. It’s unfortunate that this is not clarified in the same document (that I have found), but I have found another document, the Mobility Brief that states that BizTalk Server Enterprise is exempt from this rule, while it still seems to apply to Standard Edition. Also note that while that document talks about 2006 R2 I am assuming it applies equally to BizTalk Server 2010 as I’ve found nothing that says otherwise.

In the past, Microsoft server software and EC licenses have had to be assigned to a specific server for at least 90 days before they could be reassigned to another server. Therefore, for example, if you wanted to move running instances of software from one server to another more frequently, you needed to assign licenses to both servers. With Microsoft’s new terms for certain products, Microsoft waives the 90-day reassignment rule, allowing you to reassign licenses from one server to another within a server farm as frequently as you need to. This allows you to freely move both licenses and running instances within a server farm from one server to another. In the example above, so long as you are not running the software on both servers at one time, you can do this without having to assign licenses to both servers at the same time.

This might also be what the following clause in the PUR details.

For BizTalk Server 2010 Standard Edition:

Networked Clusters. The server software may not be used on a server that is part of a networked cluster, or in an OSE that is part of a networked cluster of OSEs on the same server.

This could also mean that: “You cannot cluster BizTalk Server Standard”, which given that it’s a single server license also makes total sense. But add the two sources together and I don’t think that’s solely what it means.

Also mentioned by the mobility brief is that:

Today, with licensing for Per Processor products like Microsoft® SQL Server® 2008 Enterprise and Microsoft BizTalk® Server 2006 R2 Enterprise Edition, you can run unlimited software instances in physical operating system environments (OSEs), virtual OSEs, or both on your individual servers by counting all of each server’s physical processors and assigning it that number of licenses. With the new rules, as an alternative to simply counting all of a server’s physical processors and assigning that number of licenses, you may count the number of the server’s physical processors that support OSEs in which server software instances are running at any one time, and assign that number of licenses. This applies both to physical processors being used by physical OSEs in which instances are running and to physical processors supporting virtual OSEs in which instances are running.

With the licensing changes, you effectively count the greatest number of physical processors at any time supporting OSEs in which instances are running across your server farm, and assign that number of licenses.

Remember how I wasn’t sure about the number of Enterprise licenses needed in the calculation above? Well , my interpretation of this text is that if only some (let’s say one) of the processors on the physical machine support the virtual machine then that figure could have been one. This only really matters if you need Enterprise licenses for something, like if you have a web farm – according to the mobility brief. In Hyper-V, as I understand it, there is no way to set processor affinity (as in telling the virtual machine to only use one processor) and the load is spread across all processors – all processors support the virtual machine. However on VMware – it is (or might be, the KB suggests this is an old GSX setting but it’s also linked to from several ESX kb’s so it might still be valid?). This setting, combined with the cores in a virtual proc, would make figures for A B C more like this:


The text, to me, also suggests that if you on a two proc hexa-core machine want to run two virtual machines with one virtual proc used across a web farm you may get away with one license, but it has to be an Enterprise license. It’s an uncertain point for me at the moment.

Giving all these options and settings the variations to take into account are numerous.

And just because this is a licensing post, what about the “Additional Software”:

I) Running Instances of the Additional Software. You may run or otherwise use any number of instances of the additional software listed in the table below in physical or virtual OSEs on any number of devices. You may use those instances only with the server software. Use of any instance with the server software may be indirect, through other additional software, or direct.

For all editions of BizTalk Server 2010

  • Administration and Monitoring Tools
  • BizTalk Server Related Schemas and Templates
  • Business Activity Services
  • Development Tools
  • Master Secret Server/Enterprise Single Sign-On
  • Software Development Kit(s)
  • MQHelper.dll
  • Business Activity Monitoring (“BAM”) Event APIs and Interceptors & Administration Tools
  • BAM Alert Provided for SQL Notification Services
  • BAM Client
  • Windows SharePoint Services Adapter Web Service
  • Windows Communication Foundation Adapters
  • SOAP Receive Adapter
  • HTTP Receive Adapter
  • UDDI
  • Business Rules Component
  • MQSeries Agent

Only for BizTalk Server 2010 Branch Edition

  • BizTalk Adapter for SQL Server

This does not however, according to the pricing & licensing FAQ for BizTalk, include the Adapter Pack, and therefore not the AppFabric Connect features. Those must be used on a server with a valid license assigned. But then, what are the “Windows Communication Foundation Adapters” mentioned above if not the Adapter Pack? Odd… It doesn’t make sense for it to be the WCF-NetTcp et al adapters. Why would you install those on a separate machine? Not crystal.

An additional dimension to this is of course using SPLA licenses, which can be used when you are an outsourcing provider and supply licenses to clients. For now, I’ve decided not to cover those. The Product User Rights documents listing for SPLA can be found at:

Like I said, I’d be happy to extend this post further with clarifications and corrections based on input so leave your comment to either point out corrections that needs to be made or to point out gaps that could be filled.

Resources used:

/Johan Hedberg