Importing ESB BAM definitions without Excel

I was working on a PC on which I wanted to install the BAM definitions that come with the ESB guidance for exception handling.

So I browsed to the <installpath>ESB Exception Handling InstallInstallBAM folder to execute “deploy_exception_tracking.cmd”.

Unfortunately I was unable to run it because it requires Excel to be present to process the Excel file containing the definitions and that wasn’t installed on that machine. On the other hand I wasn’t allowed to install Excel so I had to convert the XLS to XML which also can be used to import the definitions. On my external drive I found an VPC with Biztalk 2006 and Excel installed and used that to let Excel generate the XML.

With renewed energy I changed the ESB deployment file “bmdeploy.cmd” to use the XML instead of the XLS. If you want be able to undeploy it again, also change the “bmundeploy.cmd”.

It ran some time and then returned the following error:

Updating Activity… ERROR: The BAM deployment failed.
Encountered error while executing command on SQL Server “VPC-BT2006”.
New request is not allowed to start because it should come with valid transaction descriptor.

After some searching I found that it had to do with a bug in ADO.NET that would be fixed in SP2 of SQL Server 2005. So I installed it and tried again. Again the same error. Further research was necessary to find the cause.

At the end it turned out to be a SQL Hotfix fixing it because SP2 didn’t.

The XML file with the representation of the BAM definitions in XML can be found here.

Some other thing that I rediscovered is the location of the Excel plugin for BAM. I was used to BizTalk 2004 where BAM.XLS was the Excel sheet to use. Now that one is gone and a plugin is used. Microsoft tells you where to look for it:
If Excel 2003 is not installed, the file BAM.xla is installed to its default location at %System Drive%Program FilesMicrosoft BizTalk Server 2006Exceldir. If Excel is installed, it can directly be added as plugin using the Tools menu.

Delete a locked file in TFS

This is more or less a note to self because I probably will run into this again.

Today I was cleaning up the code tree in TFS and found a project that could be deleted. Unfortunately the developer left the company leaving a file checked out. With the Source Control Explorer it wasn’t possible to remove the project as long as there were locked files. The file status is stored in the workspace, so deleting it would solve the problem

Using the TF.exe commandline tool it was possible to lookup ad delete that workspace.

Getting the workspace name:

tf workspaces /owner:<developers_logonname> /computer:* /server:<your TFS server>

Deleting the workspace:

tf workspace /delete /server:<your TFS server> workspace_name;developers_logonname

Remember that you need AdminWorkspaces global permissions to be able to delete the workspace.


BizTalk ESB Install guidance

In the past few weeks I have been installing the ESB guidance for BizTalk server. Yes, it took me a few weeks because it isn’t as easy as clicking setup.exe. Of course I wasn’t busy all day during that time, but actually it took me longer than I expected. I read the discussions on CodePlex and I ran into some of the problems mentioned there but also found some new ones. During the installation process I decided to create an install script with issues I faced.

I didn’t install the MQ/JMS components so please refer to the guidance documentation if you want that. Here is the script I created, maybe it will help you install the ESB package.

Software requirements:
– Microsoft Windows Server 2003 with Service Pack 2 installed
– Microsoft .NET Framework 3.0
– Hot fix KB923028 (this fixes the “Unhandled Exception: System.AccessViolationException” error when you run a .NET Framework 2.0 Remoting application, see
– Internet Information Services (IIS) 6.0 (used for Web services and the ESB Management Portal)
– SQL Server 2005 SP2 including the Database Service, Analysis Services, and Integration Services; or SQL Server 2000 including the Database Service and Data Transformation Service, and with Service Pack 3 or later installed
– Visual Studio 2005 (C# for most projects; C++ for the JMS pipeline component) with Service Pack 1 or later installed
– InfoPath 2003 or InfoPath 2007 (used to render exception details generated by the ESB Exception Management Framework)
– Excel 2003 or Excel 2007 (required only to modify the BAM tracking spreadsheets)
– Enterprise Library 3.1 (this is required only for the ESB Management Portal)
– Windows Sysinternals DebugView; this is highly recommended to enable you to see trace information as messages flow through the ESB, which can be useful when troubleshooting (available from
– Microsoft BizTalk Server 2006 R2, including Business Activity Monitoring (BAM)
– BizTalk MQ Series Adapter installed and configured using the default name (only if using the Microsoft ESB Guidance JMS component or the samples that require MQSeries)
– BizTalk Server 2006 R2 Hotfix KB943871, which adds support for new BizTalk Error Reporting properties (ErrorReport.FailureTime, ErrorReport.FailureAdapter, ErrorReport.FailureMessageID, ErrorReport.FailureInstanceID)
(but the hotfix KB943871 doesn’t seem to be around)

Before moving on make sure the default website is running ASP.NET 2.0 (1.1 is default, which affects all virtual directories expecting ASP.NET 2.0)

– Install UDDI (Add/remove software – Windows Components)
– Install the Dundas Chart for ASP.NET Enterprise (download from

* reminder: Microsoft ESB Guidance source and sample code is distributed as a .zip file. In the current release, the supported installation is for the files to reside in the folder C:ProjectsMicrosoft.Practices.ESB. The BizTalk binding files that ship with the samples depend on this path.

Installation of the ESB package:
– Install ESB by executing ESB Guidance November 2007.msi
– Create a “Tmp” folder and copy the “” archive to it (to avoid long names issues)
– Create folder “C:ProjectsMicrosoft.Practices.ESB”
– Extract “” with folders to “C:ProjectsMicrosoft.Practices.ESB”
– Execute SQL script “EsbExceptionDb_CREATE.sql” to create exception database
– Open “PreProcessingCORE.vbs” and change User and Pwd to your settings
– Execute “PreProcessingCORE.vbs”
– Check to verify if security settings are correct
– Execute “1.Install_Prerequisites.cmd”
– If errors occur, restart the MSSQL$UDDI service (UDDI is a named instance) and try again
– Execute “1. CORE_CreateBizTalkApplication.cmd”
– Change the SQL adapter setting on the All.Exceptions Sendport to the database containing the EsbExceptionDb

Change Biztalk config file %ProgramFiles%Microsoft BizTalk Server 2006BTSNTSvc.exe.config
– Add the following section to the BTSNTSvc.exe.config file immediately below the opening <configuration> element
    <section name=”xlangs” type=”Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess” />

– Add the following section to the end of the BTSNTSvc.exe.config file, immediately above the closing </configuration> element

      <AppDomains AssembliesPerDomain=”10″>
        <DefaultSpec SecondsIdleBeforeShutdown=”1200″ SecondsEmptyBeforeShutdown=”1800″/>
          <AppDomainSpec Name=”Microsoft.Practices.ESB”>
          <PatternAssignmentRule AssemblyNamePattern=”Microsoft.Practices.ESB.*” AppDomainName=”Microsoft.Practices.ESB” />

– Change the [path] placeholder with the location where Biztalk can find the configfile “Microsoft.Practices.ESB.PipelineComponents.config”
That is for example c:ProjectsMicrosoft.Practices.ESBSourceCoreConfig if you used the solution deployent of ESB and If you are installing from the Microsoft.Practices.ESB.CORE.msi Windows Installer, the default path is C:Program FilesGenerated by BizTalkMicrosoft.Practices.ESBConfig.

– Restart the BizTalk NT Services

Change .NET config file %WinDir%Microsoft.NETFrameworkv2.0.50727CONFIGmachine.config
– Add the following section immediately below the opening <configSections> element

<sectionGroup name=”ESBProcessor”>
  <section name=”Resolver” type=”System.Configuration.DictionarySectionHandler, System,Version=,Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  <section name=”AdapterProvider” type=”System.Configuration.DictionarySectionHandler, System,Version=,Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  <section name=”ItineraryCache”  type=”System.Configuration.DictionarySectionHandler, System,Version=,Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  <section name=”Cache” type=”System.Configuration.DictionarySectionHandler, System,Version=,Culture=neutral, PublicKeyToken=b77a5c561934e089″/>

– Add the following section at the end of the Machine.config file, immediately above the closing </configuration> element.

    <add key=”UDDI”  value=”Microsoft.Practices.ESB.Resolver.UDDI,  Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
    <add key=”WSMEX” value=”Microsoft.Practices.ESB.Resolver.WSMEX,  Version=, Culture=neutral,  PublicKeyToken=31bf3856ad364e35″ />
    <add key=”XPATH” value=”Microsoft.Practices.ESB.Resolver.XPATH, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
    <add key=”STATIC” value=”Microsoft.Practices.ESB.Resolver.STATIC, Version=, Culture=neutral,  PublicKeyToken=31bf3856ad364e35″ />
    <add key=”BRE”  value=”Microsoft.Practices.ESB.Resolver.BRE, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
    <add key=”WCF-WSHttp” value=”Microsoft.Practices.ESB.Adapter.WcfWSHttp, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
    <add key=”WCF-BasicHttp” value=”Microsoft.Practices.ESB.Adapter.WcfBasicHttp, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
    <add key=”FTP”  value=”Microsoft.Practices.ESB.Adapter.FTP, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
    <add key=”FILE”  value=”Microsoft.Practices.ESB.Adapter.FILE, ersion=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
    <add key=”MQSeries” value=”Microsoft.Practices.ESB.Adapter.MQSeries, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
    <add key=”timeout” value=”120″ />
    <add key=”UDDI” value=”600″ />
    <add key=”WSMEX” value=”600″ />

Install the ESB Management Portal and Associated Services:

– Make sure you build the portal website located at C:ProjectsMicrosoft.Practices.ESBSourceSamplesManagement PortalESB.Portal
If the DundasWebChart component cannot be found, you’re probably have a newer version than in the references.
The references look for v5.5.0.1697 and the latest from Dundas is v6.0.0.1724.
Remove the reference and add the new one which can be found in C:Program FilesDundas SoftwareChartingWebControlVS2005bin, then build the portal again.

– Create the ESBAdmin database by running the script located at C:ProjectsMicrosoft.Practices.ESBSourceSamplesManagement PortalSQLESB.Administration Database.sql

Create a new Virtual Directory for the ESBPortal:
– Alias: ESB.Portal
– Directory: C:ProjectsMicrosoft.Practices.ESBSourceSamplesManagement PortalESB.Portal
– Allow the following: Read, Run Scripts (such as ASP)
– Allow anonymous access: No (enable Integrated Windows Authentication)
– Application Pool: ESBNetworkAppPool (Application pool is created in an earlier stage by PreProcessingCORE.vbs)
– Make sure ASP.NET 2.0 is selected for the virtual directory of the portal.

– Open web.config of the portal on C:ProjectsMicrosoft.Practices.ESBSourceSamplesManagement PortalESB.Portalweb.config to check the connectionstring settings for “AdminDatabaseServer”(=ESBAdmin) and “EsbExceptionDb”
– Rebuild the portal

Check the portal settings:
– Start http://localhost/ESB.Portal
– If you get a login dialog, check if the “Integrated Windows Authentication” is on
Otherwise check web.config if the “authorization” section is allowing you access.

Install the ESB Management Portal Alert Service:
– Open the solution C:ProjectsMicrosoft.Practices.ESBSourceSamplesManagement PortalESB.AlertServiceESB.AlertService.sln
– Open App.config and check if the connectionstring points to the correct “EsbExceptionDb” database
– Set the buildtype to ‘Release’
– Build the solution to make sure also the setup project gets build
– Run the setup.exe created in C:ProjectsMicrosoft.Practices.ESBSourceSamplesManagement PortalESB.AlertService.InstallRelease
– Use default settings until a dialog shows up for credentials
– Select an account that is a member of the BizTalk Application Users group with access to both the EsbExceptionDb database and the server hosting the alert service.
– Enter the account name in the form: <DomainName><UserName>, if it is a local account use <servername><username>
– You can configure the settings using the portal (Admin -> Fault Settings)
– A service named “BizTalk ESB Exception Notification” is created, make sure it is set to start automatically and start the service

Install the ESB Management Portal UDDI Publishing Service:
– Open the solution C:ProjectsMicrosoft.Practices.ESBSourceSamplesManagement PortalESB.UDDI.PublisherServiceESB.UDDI.PublisherService.sln
– Open App.config
– Check if the ConnectionStrings point to the correct “EsbExceptionDb” and “AdminDatabaseServer”(=ESBAdmin) database
– Check if the ApplicationSettings contain the correct ESB UDDI and BiztalkOperationService webservice addresses
– Add the following to the app.config and change them if necessary

  <add key=”uddiServerUrl” value=”
  <add key=”smtpServerAddress” value=””/>
  <add key=”emailNotificationFrom” value=”>
  <add key=”defaultModelName” value=”microsoft-com:esb:runtimeresolution”/>
  <add key=”serviceInterval” value=”30000″/>
  <add key=”DomainName” value=”YD”/>

– Set the buildtype to ‘Release’
– Build the solution to make sure also the setup project gets build
– Run the setup.exe created in C:ProjectsMicrosoft.Practices.ESBSourceSamplesManagement PortalESB.UDDI.PublisherService.InstallRelease
– Use default settings until a dialog shows up for credentials for the service account for the UDDI Publishing Service.
– Select an account that is a member of the BizTalk Application Users group with access and that has access to the server hosting the UDDI Publisher Service
– Enter the account name in the form: <DomainName><UserName>, if it is a local account use <servername><username>
– You can configure the settings using the portal (Admin -> Registry Settings)
– A service named “BizTalk ESB UDDI Publishing” is created, make sure it is set to start automatically and start the service

Configure Exception Management InfoPath Form Template Shares:
– Share the folder: C:ProjectsMicrosoft.Practices.ESBSourceException HandlingSourceESB.ExceptionHandling.InfoPath.ReportingPublish
– Set “Read” permissions for everyone
– Share the folder C:ProjectsMicrosoft.Practices.ESBSourceSamplesException HandlingSourceESB.ExceptionHandling.InfoPath.ResubmitPublish
– Set the name to “PublishResubmit” and “Read” permissions for everyone

* Ready with installation!!

Now you can start installing samples and play arround.

BizTalk Server 2006 R2 Scale-Out Configurations Poster

While looking for something totally different, I found this very informational poster.
It shows the various scale-out options for Biztalk Server 2006 R2, not in text but in very clear pictures.
I assume the scale-out options are also valid for regular 2006 installations.

In Microsofts own words:

The BizTalk Server 2006 R2 Scale-Out Configurations poster shows typical scenarios and commonly used options for scaling out BizTalk Server physical configurations. The poster illustrates how to scale out BizTalk Server configurations to achieve high availability through load balancing and fault tolerance and how to configure for high-throughput scenarios. The poster is intended for use by IT professionals and developers who need to design, deploy, and manage large-scale implementations of BizTalk Server 2006 R2.

You can download the poster here.

To make the post complete, here some other posters. 🙂