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

HTH
/Johan

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 h.id = 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 a.id = rh.AdapterId
UNION
select
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
UNION
select
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
–UNION
–select distinct h.Name as Host, * –, ‘*Tracking’ as Adapter, NULL as Port
–from adm_Host h
–where h.HostTracking = 1
)


HTH
/Johan

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
set BACKUP_PATH=%1
set RET_INTERVAL=%2

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"
exit %ERRORLEVEL%

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=1.0.0.0, 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.

BizTalk, Maintenance

Cleanup BizTalk Servers MgmtDb

I’ve previously blogged about cleaning (emptying) the MsgBox database, something that can be useful in some scenarios, like development and test. While looking for something else the other day I found information about an equally useful procedure, again mainly in an development environment. Speaking for myself I can say that there has been a number of time where I have just wanted to start from a clean slate with my development BizTalk Server installation. Just remove all ports and other deployed artifacts and start from a clean slate. Do NOT run this in production, and be careful that this is REALLY what you want even when running it in another environment.


According to the documentation:
In the BizTalk Management (BizTalkMgmtDb) database, there’s a stored procedure named dbo.adm_cleanupmgmtdb. If you do run this stored procedure, all the entries in the database will be deleted.


It was documented in this article, which wasn’t really on topic with the other content of the page: http://msdn.microsoft.com/en-us/library/aa561960.aspx


Nostalgic off-topic link: For some reason I always come to think about the starting sequence for “Anslagstavlan” when talking about clean slates. This link is completely irrelevant to BizTalk, it’s swedish television from the 80’s.

Configuration, General, Maintenance, Monitoring

Event log service is unavailable issue

I thought I’d blog about this issue I had, since it was in the end so easy to solve, but I had a hard time finding a good description of both my specific problem and any resolution. I am a bit ashamed to say that I got quite creative before trying this.


The problem I was having was that when opening the Event Viewer on my Windows Server 2008 I’d got a message saying that “The Event Log service is unavailable. Verify the service is running.“. And if I went to look it was in fact not running. The thing is though that I could easily start it, and it would keep running, until I went to the Event Viewer to look at the logs, which would then bring it down.


I solved this by simply deleting all the files in the C:WindowsSystem32winevtLogs folder.


Update 2010-02-22: Feedback in comments suggest that you might need to restart after performing this step.  


I’m not going to patent the solution, or make the claim that it will work in every case, but it did for me, and if you are experiencing this problem it’s easy enough to try.