SSO Configuration Road Block

24 11 2010

Recently I’ve had the need to setup a BizTalk Server 2006 R2 virtual machine. Quietly confident about my experience with this version of BizTalk, I jumped in head first to *quickly* get a simple single server based installation configured on a 32-bit VMWare based VM.

Lesson learned today…never, ever underestimate the obscure errors that BizTalk Server can produce. The install was smooth sailing. But when the time came to configure SSO, this:

Failed to generate and backup the master secret to file: C:\Program Files\Common Files\Enterprise Single Sign-On\SSO07AB.bak (SSO) Additional Information (0x80070005) Access is Denied.

I wracked my brain for a previous solution to this, but never have I seen this. There is speculation this may be a very rare bug that arises only in the context of doing single server VM based configurations. Regardless of the cause, it is not helpful.

Thank you to Mikael Sand, for detailing the solution to this. Un-configure and manually blast away any features and/or databases the configuration tool may have created. Create the two groups “SSO Administrators” and “SSO Affiliate Administrators” (alternatively name them whatever you like) manually. Add the account you are running the configuration tool under, and the BizTalk service account to these newly created groups. Log off. Re-run the configuration tool.


BizTalk Servers Slow First Hit

2 08 2010

Lately I been thinking about BizTalk Server, and a particular behavior that it consistently demonstrates without fail. It takes a dreadful amount of time to service a “cold” request, however once “warmed”, it hums.

Its challenging at best to justify this behavior to a technology ignorant client.

Without getting too deep into BizTalk Servers internals (I would love to spend some time with windbg and the SOS extension digging around), I wanted a way to have partial control over how BizTalk Server manages the actual processes that invoke the code we make. All mainstream BizTalk artefacts (orchestrations, maps, pipelines) boil down to managed code (IL). BizTalk consumes our crafted “business” assemblies (dll’s) by loaded them into its address space through one or more AppDomain’s, at which time the messaging engine can call out to them when it sees fit.

This spawns a number of related questions; how many dll’s per appdomain? Under what conditions does an appdomain’s get “garbage collected” by the messaging engine? And so on. So I digged a little deeper.

Thanks to Tomas Restrepo for posting the excellent MSDN link to Orchestration Engine Configuration, which in essence sums up everything I wished for. Basically it involves hacking the BTSNTSvc.exe.config, which host instances take into account when started. While you can do cool things like control dehydration behaviour, and more, I was more interested in this:

Assemblies are assigned to named domains using assignment rules (see more below). If no rule is specified for some assembly, the assembly will be assigned to an ad hoc domain. The number of such assigned assemblies per ad hoc domain is determined by the value of AssembliesPerDomain.

Which translates to this in btsntsvc.exe.config:

<AppDomains AssembliesPerDomain="10">
      <AppDomainSpec Name="FooDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
      <ExactAssignmentRule AssemblyName="Foo.Orchestration, Version=, Culture=neutral, PublicKeyToken=9f3a0f87e62e465c" AppDomainName="FooDomain" />

The interesting properties SecondsEmptyBeforeShutdown and SecondsIdleBeforeShutdown, are defined as follows:

SecondsEmptyBeforeShutdown is the number of seconds that an app domain is empty (that is, it does not contain any orchestrations) before being unloaded. Specify -1 to signal that an app domain should never unload, even when empty.

SecondsIdleBeforeShutdown is the number of seconds that an app domain is idle (that is, it contains only dehydratable orchestrations) before being unloaded. Specify -1 to signal that an app domain should never unload when idle but not empty. When an idle but non-empty domain is shut down, all of the contained instances are dehydrated first.

Thanks to Mick Badran, who has posted a handy BTSNTSvc.exe.config template, which includes the AppDomain configuration section discussed above.

UPDATE: Here’s a copy of my own *no frills* template:

<?xml version="1.0" ?>
    <section name="xlangs" type="Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess" />
      <add address="*" maxconnection="48"/>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking;Tracking\interop" />
        <provider id="sspi" type="Microsoft.BizTalk.XLANGs.BTXEngine.SecurityServerChannelSinkProvider,Microsoft.XLANGs.BizTalk.Engine" securityPackage="ntlm" authenticationLevel="packetPrivacy" />
        <channel ref="tcp" port="0" name="">
            <provider ref="sspi" />
            <formatter ref="binary" typeFilterLevel="Full"/>
      <AppDomains AssembliesPerDomain="10">
          <AppDomainSpec Name="FooDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
          <AppDomainSpec Name="BarDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
          <PatternAssignmentRule AssemblyNamePattern="Net.benCode.Foo.*, Version=\d.\d.\d.\d, Culture=neutral, PublicKeyToken=.{16}" AppDomainName="FooDomain" />
          <PatternAssignmentRule AssemblyNamePattern="Net.benCode.Bar.*, Version=\d.\d.\d.\d, Culture=neutral, PublicKeyToken=.{16}" AppDomainName="BarDomain" />

BizTalk 2006 Install Problems on WinXP

21 12 2008

Today while doing some vanilla BizTalk 2006 R2 installs, discovered the installer was choking with:

Error 5003.Regsvcs failed for assembly C:\Program
Files\Microsoft BizTalk Server 2006\Microsoft.BizTalk.Deployment.dll.
Return code 1.


Awesome. Other cases of a malfunctioning regsvcs executable have been reported. For reasons that remain unknown to me regsvcs.exe stop functioning following the installation of SP1 for VS.NET 2005 and the .NET 2.0. regsvscs.exe appeared to be intact, but invoking any of it functionality (including listing its command line help) would return nothing—hence the return code 1 problem.

Solution: Repair the .NET Framework 2.0 binaries. I grabbed a fresh copy of the service pack. It is important that regsvcs.exe functions correctly—you can test it while reinstalling the service pack by running “regsvcs.exe /?“. If it lists out help your good to go.

MIME Decoder and 64bit

22 04 2008

This week I got a great introduction to the subtle difficulties that are waiting to be encountered when running a 32-bit component in a 64-bit environment. In short, an orchestration that employed the standard (ships with BizTalk) MIME Decoder pipeline component was consistently failing with the following:

The invocation of a pipeline component continued to raise the following exception.
The pipeline “Net.Bencode.Pipeline.Decoder” could not be created for execution. Error Details: “Retrieving the COM class factory for component with CLSID {254B4004-2AA7-4C82-BB2E-18BA7F22DCD2} failed due to the following error: 80040154.”

WTF. After much digging around and troubleshooting, found the problem related to a partcular BizTalk (MIME Decoder) component that only supports a 32-bit execution mode. When executing in a native 64-bit execution environment (e.g. Windows Server 2003 R2 x64) serious instability issues arose (the component would just fail with leaving extremely misleading/confusing diagnostics behind). BizTalk is capable of provide an emulated 32-bit execution mode by using WOW64.

The solution to this problem was to run the orchestration (which uses the MIME Decoder component through a custom pipeline) under a 32-bit host instance. The original problem (“Retrieving the COM class factory for component with CLSID”) can be easily reproduced by switching off the 32-bit emulation mode.

Apparently this applies to a small handful of components in BizTalk. As stated on technetRunning the WSE adapter, FTP adapter, SQL adapter, POP3 adapter, and MIME Decoder on 64-bit host instances is not supported“.

Debugging Pipeline Components

16 03 2008

Of late I have been spending most of my free time (which isnt a great deal) with pipeline components. BizTalk pipelining is very intriguing and potentially a powerful tool in any BizTalk developers toolkit.

Pipeline component development like most BizTalk related development, seems to involve allot of boilerplate code. Others have tried to counter this with VS.NET wizards (eg. pipeline component wizard, adapter wizard, etc). For some reason I just dont like these… they are a little heavy for my needs.

The BizTalk SDK (to my surprise) includes several useful pipeline samples—ranging from using the standard pipeline components that ship with BizTalk, to crafting custom stream classes that plug-in to the standard component model. I hope to create a small suite of component templates and streamers that I can keep handy for various scenarios.

When you actually start writing custom pipeline components the inefficiency of the BizTalk build-deploy-test cycle becomes unbearable. Gilles (back in 2004) posted about a very handy technique (How to Debug a BizTalk 2004 Pipeline) for interactively debugging pipeline components—it removes the need to perform BizTalk deployments in order to test your pipeline components. The BizTalk SDK ships with a number of managed executables specifically designed to exercise pipelines in the same way BizTalk Server would. By configuring a pipeline component C# class library to bind against a startup application of pipeline.exe and defining the test input message and  pipeline definition (.btp) arguments, it becomes a simple affair of hitting F5 to get interactive debugging—I couldn’t believe how effective this simple technique was.

Missing Tracking Data?

4 03 2008

BizTalk’s tracking capabilities are a wonderful diagnostic feature when in thick of core BizTalk development work, or when a curly situation raises its head in a production environment. Typically when involved with BizTalk development it is not uncommon to find yourself integrating with COTS (Commercial Off The Shelf) products. Participating systems can (and do) deviate from the agreed contracts, sometimes in ways never foreseen. Doing integration between business units and their systems is a political hotspot when things go wrong—being able to identify the cause of an integration problem quickly is crucial. BizTalk tracking can be easily switched on and off at runtime—at both the port and orchestration level. The actual information (message bodies and/or context properties) and the granularity (pre and/or post processing) of tracking can be easily controlled using the administration console.

In my current “work” environment tracking never worked as expected. 99% of the time I could never extract message bodies using the HAT (Health and Activity Tracking) tool. Although frustrated, I never spent the time to investigate why this was until recently. After a bit of digging around, soon discovered that tracking data is actually shipped out of the message box at (by default) one minute intervals by the SQL Server Agent job TrackedMessages_Copy_BizTalkMsgBoxDb. When I attempted to manually invoke the job I quickly found that the job failed to execute due to a lack of sysadmin privilege to the SQL Server.

The SQL Server Agent windows service had been setup to run under a low privileged domain account which in-fact had no (let alone sysadmin) privileges to the SQL Server. After reconfiguring the account under which the windows service ran under I was in-luck—the job was now happily shipping message tracking data into the BizTalkDTADb database.

Now message tracking was 100% reliable and I felt invincible—having the knowledge that I could now reliably capture the complete message bodies and context properties of incoming and outgoing messaging is very comforting.

So if your having problem with tracking and everything looks to be enabled, make sure you check out the TrackedMessages_Copy_BizTalkMsgBoxDb job.

Reserved words and Distinguished Fields

13 02 2008

The other day I built a schema that was the cause of much confusion and time wasting. Basically the tiny schema was being used by a centralised error handling process, that was designed to subscribe to and publish errors. The schema had a number of child elements, two of which were named “message” and “source”. Each field in the schema was distinguished (not promoted) to allow participating orchestrations to examine and/or manipulate the error message instances.

So thinking it be business as usual (BAU) I went about assigning the distinguished message fields using various expression and assignment orchestration shapes. To my frustration the VS.NET XLANG editor (the one you get when editing an expression or assignment) kept red-squiggly underlining the “message” and “source” distinguished fields whenever I attempted to reference them (as below)—with the unhelpful error message of “Unexpected keyword: message, cannot find symbol”.

myMessage.myRoot.message or myMessage.myRoot.source

It turns out that I was unlucky, message and system are reserved words in the XLANG grammar. Be careful of XLANG reserved words when distinguishing message fields.