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, Tracking

How-to: Easily examine the incoming message using tracking

I got a question the other day, and thought I’d post a very short how-to. The problem the questioner had was this: They encountered a situation where they wanted to view the incoming document before BizTalk has begun processing it – the sending party “hadn’t changed anything” yet all of a sudden the message was failing in BizTalk. How can this easily be available?

By default, when you look at a ports Tracking tab, no box is checked.

clip_image001

If you try and look at the message details of such a message

clip_image002

you will get an error dialogue.

clip_image004

However if I return to my port and check some of those check boxes for tracking, in this case “Request message before port processing”

clip_image005

make sure that the SQL job TrackedMessages_Copy_BizTalkMessageBoxDb is running as it should (which by default is enabled and running)

clip_image006

Now if I send in another message and try to look at its Message Details I get a dialogue containing the details I am after, including the content of the message

clip_image008

As expected this dialogue may not show some characters correctly, but you can easily go to File… Save Message.

This will create two files, one which is the context properties, and the other the message.

clip_image010

The message will stay in the database as long as configured in the database job DTA Purge and Archive (BizTalkDTADb). Live means the the ServiceInstance exists (ie suspended) and Hard that it is no longer in BizTalk.

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, WMI

Strange BizTalk WMI behavior (curious BizTalk SQL)

This week a co-worker raised an issue with a WMI query where he did a simple query for an orchestrations messages, and for some reason not all of them were returned. This behavior exists on both 2006 R2 and 2009, and thus most likely on 2006 as well. The query was simple:

select    *
from MSBTS_MessageInstance
where ServiceInstanceID = ‘{9DD50CE0-CC9C-478C-B19D-A3AAFD33ACA3}’

This was supposed to return two messages, but only one was returned, illustrated below in WMIExplorer:


image


He came up with a solution where he could instead do a LIKE query and get both message instances returned:

select    *
from MSBTS_MessageInstance
where ServiceInstanceID LIKE ‘{9DD50CE0-CC9C-478C-B19D-A3AAFD33ACA3}’

image


Now I was ok with this as a solution, but I wanted to find out a bit about why this happened.


Using SQL Profiler to see what this WMI query meant I found a call that looked like this when I used ‘=’:

exec BOM_LookupMessageReferences
@nvcHost=NULL,@nServiceClass=127,@uidServiceType=NULL
@uidInstanceId=‘9DD50CE0-CC9C-478C-B19D–3AAFD33ACA3’,
@uidMessageId=NULL,@snStatus=63,@nReferenceType=15,
@dtFrom=‘Oct 25 3009 12:06:31:360PM’,@dtUntil=‘Oct 25 1809 12:06:31:360PM’,
@nMaxMatches=200

and like this when using ‘LIKE’:

exec MBOM_LookupMessageReferences
@nvcHost=NULL,@nServiceClass=127,@uidServiceType=NULL,
@uidInstanceId=NULL,
@uidMessageId=NULL,@snStatus=63,@nReferenceType=15,
@dtFrom=‘Oct 25 3009 12:06:42:867PM’,@dtUntil=‘Oct 25 1809 12:06:42:867PM’,
@nMaxMatches=200

Spot the difference?


Sure enough in one case we send in the (service)instanceId and in the latter, we don’t. This in effect, causes the latter query to return all messages matching the other criteria, and filtering on the serviceInstanceId is made elsewhere, presumably in the code executed by the WMI call, although I haven’t investigated that further.


So what makes the first query return only one message? It’s got the service instance Id with it, and nothing else, so what’s causing it to filter out the single message.


Looking further into the call chain in SQL, the method MBOM_LookupMessageReferences uses methods named MBOM_LookupMessageReferences_<host>, for example MBOM_LookupMessageReferences_BizTalkServerApplication.


In this (these) procedures you can find the following code:

if (@uidInstanceId IS NOT NULL)
set ROWCOUNT 1
else if (@nMaxMatches > 0)
set ROWCOUNT @nMaxMatches

So if we send in a serviceInstanceId we will just get a single message instance returned. I’m not sure what the point of this is really, but it seems to be interfering with what we want.


It’s an universal truth that you do best to stay out of the BizTalk databases and their queries. I’m not going to suggest something that I will call a solution in this post, especially not since I haven’t done sufficient testing to see that this doesn’t interfere with something else.


However, from the test I have done, it seems as if the following code change might be what was intended:

if (@uidMessageId IS NOT NULL)
set ROWCOUNT 1
else if (@nMaxMatches > 0)
set ROWCOUNT @nMaxMatches

Which gives the result I want for a serviceInstanceId query:


image


as well as for a messageInstanceID query;


image


We are not likely to use this alteration, since I’m ok with the way that the LIKE query works, even though it takes a wider scope then necessary. But perhaps this might help or enlighten someone that finds themselves with a similar puzzle.

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

64-bit, Administration, BizTalk Server 2009, Installation

BizTalk Server 2009 Installation Errors

I just thought I’d mention these install errors since I’ve gotten them now on several occasion when installing BizTalk Server 2009 Enterprise 64-bit Single Sign On Master Secret Server on Windows Server 2008 and SQL Server 2008 (although I doubt the last one has any role in these errors).

This page describes the procedure of Installing and Clustering the Enterprise SSO Master Secret Server, although it mentions nothing about these specific peculiarities.

Error1

Log

[10:03:05 Error] Setup runtime files for AMD64 platform: Fatal error during installation.
[10:03:05 Info] Marking Stage: Install/Installing components as Completed in TaskInfo XML
[10:03:05 Info] ReadTaskInfoXML: Attempting to load TaskInfo xml from string
[10:03:15 Info] Showing MessageBox with text: The following platform components failed to install and will need to be manually installed before setup can proceed: Setup runtime files for AMD64 platform: Fatal error during installation. Check the log for details. Return Code: 1

MSI (s) (8C:FC) [10:03:04:688]: Product: Microsoft BizTalk Server Setup Bootstrap Files (x64) — Error 1310. Error writing to file: atl90.dll. System error 0. Verify that you have access to that directory.
Error 1310. Error writing to file: atl90.dll. System error 0. Verify that you have access to that directory.
Action ended 10:03:04: InstallFinalize. Return value 3.
Action ended 10:03:05: INSTALL. Return value 3.
MSI (s) (8C:FC) [10:03:05:867]: Product: Microsoft BizTalk Server Setup Bootstrap Files (x64) — Installation failed.
MSI (s) (8C:FC) [10:03:05:868]: Windows Installer installed the product. Product Name: Microsoft BizTalk Server Setup Bootstrap Files (x64). Product Version: 3.8.368.0. Product Language: 1033. Installation success or error status: 1603.

Resolution

I have received this error if I connected to the server using Remote Desktop/Microsoft Terminal Service Client without using the /admin flag (former /console flag). Read more here.

Error2

Log

[10:34:48 Info] Showing MessageBox with text: The following platform components failed to install and will need to be manually installed before setup can proceed: Enterprise Single Sign-On Server: Unspecified error Check the log for details. Return Code: 1

[10:34:35 Info] Error 1928.Error registering COM+ application. Please ensure that DTC is enabled. Contact your support personnel for more information.
[10:34:35 Info] Showing MessageBox with text: Error 1928.Error registering COM+ application. Please ensure that DTC is enabled. Contact your support personnel for more information. Return Code: 0
[10:34:35 Info] Action 10:34:35: Rollback. Rolling back action:
[10:34:39 Info] Detailed Log information for product D:InstallBiztalk 2009PlatformSSO64SSO64.msi is available at <a href="C:UsersxxxAppDataLocalSetup(072909 103411).log">DetailedLog</a>
[10:34:39 Info] MSI installation returned 1603 – Fatal error during installation.
[10:34:39 Error] Error 1928 occurred during MSI installation.
[10:34:39 Error] Action 10:34:30: InstallComplus.8E665C9D_5561_45FC_AAA0_3878B87F3B86. Installing COM+ components
[10:34:39 Error] Error 1928.Error registering COM+ application. Please ensure that DTC is enabled. Contact your support personnel for more information.
[10:34:39 Error] c:depotsetupv2privatecommonsetupwizardexesetup.cpp(1670): FAILED hr = 80004005

Resolution

This error has occurred in clustered environments when the clustered instance of MSDTC was not active on the node on which the installation was taking place. Failover the MSDTC to the current node that installation is to be run on and try again.

Administration, Blogging

Captcha updated – Email re-enabled

Just a short note and apology to those that have used the contact form in the last few weeks. While we have been working to find a suitable method to stop spam we have disabled the email functionality altogether – which has affected the contact form as well. Messages sent through the contact form over the last couple of weeks may therefore not have reached us. Since enabling a new captcha, reCAPTCHA, spam has stopped and the email functionality is once again enabled. I can highly recommend it. If you feel you have not received a response to your message, please accept our apology and feel free to try again.

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.