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.

Sheesh!





BizTalk Server 2010 Prerequisite CAB Files

3 10 2010

Exciting times! BizTalk Server 2010 is out and as per every major release of the product there are a fresh set of redistributable CAB links to hunt down. These links available from the official installation guides.

 

Windows Server 2008 and 2008 R2

Language

Windows Server 2008 32-bit Edition

Windows Server 2008 64-bit Edition

Windows Server 2008 R2

EN

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x409

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x409

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x409

CN

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x804

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x804

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x804

DE

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x407

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x407

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x407

ES

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x40a

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x40a

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x40a

FR

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x40c

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x40c

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x40c

IT

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x410

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x410

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x410

JA

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x411

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x411

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x411

KO

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x412

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x412

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x412

TW

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x404

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x404

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x404

 

Windows Vista and 7 64-bit Editions

Language

Windows 7

Windows Vista

EN

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x409

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x409

CN

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x804

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x804

DE

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x407

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x407

ES

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x40a

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x40a

FR

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x40c

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x40c

IT

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x410

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x410

JA

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x411

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x411

KO

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x412

http://go.microsoft.com/fwlink/?LinkID=189405clcid=0x412

TW

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x404

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x404

 

Windows Vista and 7 32-bit Editions

Language

Windows 7

Windows Vista

EN

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x409

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x409

CN

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x804

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x804

DE

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x407

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x407

ES

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x40a

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x40a

FR

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x40c

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x40c

IT

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x410

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x410

JA

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x411

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x411

KO

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x412

http://go.microsoft.com/fwlink/?LinkID=189406clcid=0x412

TW

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x404

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x404





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">
   <AppDomainSpecs>
      <AppDomainSpec Name="FooDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
   </AppDomainSpecs>
   <ExactAssignmentRules>
      <ExactAssignmentRule AssemblyName="Foo.Orchestration, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f3a0f87e62e465c" AppDomainName="FooDomain" />
   </ExactAssignmentRules>
</AppDomains>

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" ?>
<configuration>
  <configSections>
    <section name="xlangs" type="Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess" />
  </configSections>
  <system.net>
    <connectionManagement>
      <add address="*" maxconnection="48"/>
    </connectionManagement>
  </system.net>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking;Tracking\interop" />
    </assemblyBinding>
  </runtime>
  <system.runtime.remoting>
    <channelSinkProviders>
      <serverProviders>
        <provider id="sspi" type="Microsoft.BizTalk.XLANGs.BTXEngine.SecurityServerChannelSinkProvider,Microsoft.XLANGs.BizTalk.Engine" securityPackage="ntlm" authenticationLevel="packetPrivacy" />
      </serverProviders>
    </channelSinkProviders>
    <application>
      <channels>
        <channel ref="tcp" port="0" name="">
          <serverProviders>
            <provider ref="sspi" />
            <formatter ref="binary" typeFilterLevel="Full"/>
          </serverProviders>
        </channel>
      </channels>
    </application>
  </system.runtime.remoting>
  <xlangs>
    <Configuration>
      <AppDomains AssembliesPerDomain="10">
        <AppDomainSpecs>
          <AppDomainSpec Name="FooDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
          <AppDomainSpec Name="BarDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
        </AppDomainSpecs>
        <PatternAssignmentRules>
          <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" />
        </PatternAssignmentRules>
      </AppDomains>
    </Configuration>
  </xlangs>
</configuration>




Why Enterprise Service Bus?

3 10 2008
  • To provide a messaging infrastructure that will:
  1. Break the communication complexity problems associated with distributed software – such as the ability to deal with ongoing change, providing management mechanisms for the complex sea of distributed service interactions that typically take place in today’s IT environment,
  2. Provide reliable end-to-end messaging,
  3. Apply distributed software security.

 

  • To provide a configurable, reusable architecture.
  • Deal with common messaging problems generically—i.e. routing, transformation, exception handling and unification.
  • Enforce consistency and unification.
  • Leverage modern standards.
  • Support legacy standards and interaction.
  • Promote agility, through increased abstraction and loose coupling.
  • Speed implementation turn-around, through configuration versus coding