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, Maintenance, SQL

Used and unused hosts sql script

This is just a log post of a script I put together. When setting up a plattform we are not always certain what hosts and handlers the customer wants. We usually set it up according to common requirements and best practices. In that case it’s also interesting to see what hosts are indeed used and not used once the solution is deployed, so you know which ones can be removed if requested. This is a sql script for that. Although this information can be found out using the Administration Console these kind of reports are not easy to get out and there is no one view for it. It’s much easier to access the database BizTalkMgmtDb directly for these things.

select h1.Name from adm_Host h1 where h1.Name not in(
select distinct h.Name as Host –, a.Name as Adapter, rp.nvcName as Port
from adm_host h
join adm_receivehandler rh on = rh.HostId
join adm_receivelocation rl on rl.ReceiveHandlerId = rh.Id
join bts_receiveport rp on rp.nID = rl.ReceivePortId
join adm_adapter a on = rh.AdapterId
distinct h.Name as Host –, a.Name as Adapter, sp.nvcName as Port
from adm_Host h
join adm_SendHandler sh on h.Id = sh.HostId
join bts_sendport_transport spt on spt.nSendHandlerID = sh.Id
join bts_sendport sp on sp.nID = spt.nSendPortID
join adm_Adapter a on sh.AdapterId = a.Id
distinct h.Name as Host –, ‘*Orchestration’ as Adapter, o.nvcName as Port
from adm_Host h
join bts_orchestration o on h.Id = o.nAdminHostID
–select distinct h.Name as Host, * –, ‘*Tracking’ as Adapter, NULL as Port
–from adm_Host h
–where h.HostTracking = 1


Administration, BizTalk Server 2010, Maintenance

Updates to bLogical.BizTalkManagement powershell BizTalk Server database restore commandlets

I’ve uploaded a new version of the bLogical.BizTalkManagement restore powershell commandlets originally posted by Mikael. The updates are minor and adress the parsing of filenames and cleanup of the code to get rid of some god intentions that never became more then intentions, aka unused code.

If you have no idea what I am talking about, feel free to read the original article and give them a try. We are using these heavily for customers instead of log shipping and it really makes the whole process of restoring your databases easy.

Administration, BizTalk, Maintenance

Cleaning up BizTalk database backups

Everyone knows (read that as: should know 😉 that enabling the BizTalk jobs “Backup BizTalk Server” and “DTA Purge and Archive” is a good thing. Even on simple test machines, and perhaps (preferably) even on your developer laptop. What happens some times though is that, when you end up using the dump-to-disk approach, you fill up your disks. This happens because by default the BizTalk Backup and DTA Purge and Archive jobs doesn’t clean house. In your production and staging environments the “IT guys” will usually have your back in this case and make sure that doesn’t happen. For those environment where that isn’t the case here’s an easy to use script provided by our IT guys to help keep things tidy. It uses the forfiles statement as the bulk of its logic.

@echo off

if "%BACKUP_PATH%"=="" exit 1
if "%RET_INTERVAL%"=="" exit 1

Forfiles /P %BACKUP_PATH% /S /M *.BAK /D -%RET_INTERVAL% /C "cmd /C Del @path"

Now all you need to do is to call this script from somewhere. A suggestion might be from a SQL job. This way you configure the backup and the cleanup of the backup files from a single location. Like this:

exec xp_cmdshell 'script.cmd C:Backup 4'

script.cmd should be the full path to your script, while C:Backup should be the full path to your backup directory. Remember to surround paths by ” should they contain spaces. The 4 in this case says that any files 4 days and older will be removed. Schedule as you see fit.

Administration, BizTalk, Maintenance

Redeploying a schema assembly…

If I ask you upfront: Can I redeploy an assembly to BizTalk (that contains a schema) that is referenced by (and used in) another assembly? – What would you say?

Some of you might say yes, some might say no. And you’d both be right! It all depends on what it is being used by and how it’s deployed.

Redeploying a schema referenced by a map in another assembly

Yes. This will work – provided you specify overwrite when redeploying or updating the resource, and regardless if the resources are placed in the same or different applications. The behavior is the same in all relevant tools, whether it is Visual Studio, BizTalk Administration Console or the BtsTask tool. For the remainder of the discussion I’ll use BtsTask only, since it has the easiest (or at least most verbose) output to follow.

Sidenote: If you don’t specify overwrite, you’ll get something like:
Error: Failed to add resource(s).
Resource (-Type=”System.BizTalk:BizTalkAssembly” -Luid=”SchemaProject, Version=, Culture=neutral, PublicKeyToken=0a220f093608cb3f”) already in store.
1) Use BTSTask’s overwrite flag or
2) Set redeploy flag to true in BizTalk Project or
3) Click overwrite all checkbox in Admin MMC to update if the resource exists in the specified target application “SchemaApplication”.
Overwrite flag will be ignored if the resource is associated with another application.

Redeploying a schema referenced by an orchestration in another assembly in the same application

Yes. This will work. It assumes that the orchestration is unenlisted (which may be a huge problem in some cases), or you will get an error. If it is however, and as long as you specify the overwrite flag, BtsTask will happily inform you of it’s progress telling you exactly what it’s doing – which is to find the referencing resources, save their binding information, removing them, then doing the same with the thing you want to redeploy, then deploying the thing you are deploying and applying it’s bindings, and finally deploying the referencing resources and applying their tucked away bindings.

The tools does all this for you, in a controlled manner under one transaction that can be rolled back if something fails. BtsTask output is here.

Redeploying a schema referenced by an orchestration in another assembly in another application

No. This is where the fun stops. You cannot do this with the out of the box tools. The Application boundary will stop you. To be frank: WTF!? For someone approaching BizTalk Server 2006/R2/2009 from a 2004 (single/no application) perspective this could invalidate their whole deployment strategy. BtsTask output is here.

In Summary

Why is this happening? If we use Reflector to disassemble BtsTask and the Deployment API’s it uses it’s apparent that the whole things is built around an Application and it’s around an Application that everything revolves. So… If you are faced with this kind of requirement for your deployment scenarios – the tools won’t do it for you – you have to do it yourself. Mimicking the steps taken by BtsTask, but without the dependency on Application, is my recommended approach. But the implementation of that is for another post…

Has anyone already done this and have or know of a tool developed for this purpose?

Update: The odd cases

I want to add that I make no claim to cover all scenarios in the above write up. I only wanted to highlight the Application boundary as one of the things that will have a big impact on redeploying schemas. We have for example come across scenarios such as when an orchestration within the same application is “specify later”-bound to a port, on which there are maps, for which there are no referential relationship with the orchestration assembly, though there are with the schema assembly being redeployed. This scenario may fail, depending on your luck, where BizTalk is unaware of the correct order to re-deploy these things. This may result in the orchestration (and the port) being re-added before the assembly containing the maps is in place. Which in itself will fail since an attempt to add a binding containing a port that has maps configured that are not deployed will of course not work. There are more scenarios, and it would be unfair to expect any tool to cover them all.