Archive for October, 2010

BizTalk 2010 Likely Compatible with Commerce Server 2007 Adapters

Based on a thread today on the MSDN forums I tried working with BizTalk 2010 RTM and the Commerce Server 2007 adapters. These are the same adapters used for Commerce Server 2009. I had worked with these adapters on a recent project with BizTalk 2009. I just wanted to post that the adapter install went successfully and I was able to add the adapters in the BizTalk 2010 administration console and able to create ports like normal. So this is an excellent compatibility story.

I had already confirmed these adapters worked with W2K8 R2 about a year ago. My test today of BizTalk 2010 RTM was also on W2K8 R2 with SQL 2K8 R1. Be aware that I only tested the BizTalk adapters and did not work with the Commerce Server business applications or any other aspect of Commerce Server.

Last year Cactus eventually certified/verified that these same adapters appeared to work successfully with BizTalk 2009:, so I would expect a similar announcement eventually.



, ,

Leave a comment

Known Compatibility Issue between Windows SDK 6.1, VS 2008 Team Suite affects ESB Toolkit 2.0


As part of my work installing the ESB Toolkit 2.0 on BizTalk 2009 I have been encountering some significant traps in the configuration of VS 2008 Team Suite and ESB Toolkit 2.0.  I have found that it is very important for you to install Visual C++ as part of the VS 2008 install if you want to build the ESB Toolkit locally. This is not a directly expressed dependency in the documentation so this is something to watch out for. On my VMs to preserve space I will typically avoid installing extra features (such as C++, SQL replication, or Books online) that I usually do not need on the applications I work with but I found out the hard way that you should not take the C++ shortcut with the ESB Toolkit.

Another gotcha I have encountered deals with the Windows SDK 6.1. The current version of the ESB Toolkit 2.0 install documentation will refer you the SDK 6.1 download but I think the install originally referenced Windows SDK 6.0A. For all general purposes, the SDK 6.1 is fine but you are recommended to also install a hotfix, if you install the SDK 6.1 after having installed VS 2008 SP1.  This hotfix overcomes some of the changes brought with 6.1 that alter the behavior of the SDK 6.0A. VS 2008 itself installs the SDK 6.0A if it is functioning correctly. The problem I experienced was that VS 2008 Team Suite does not work properly after VS 2008 SP1 and this leads to many unresolvable problems.


The issues I experienced were because VS 2008 Team Suite does not correctly keep track of the installed features after VS 2008 SP1 is installed. The Team Suite installer behaves unpredictably and will not adequately keep track of the extracted files found in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC or C:\Program Files\Microsoft SDKs\Windows\v6.0A.  If I leave C++ checked during the Team Suite install I will usually always need to go back and repair the install after VS 2008 SP1 because some of the C++ components will be missing or the Windows SDK 6.0A files will be missing by the time I try to compile the ESB Toolkit.

One of the problems I experienced included the problem of the VS 2008 Team Suite installer giving the message (similar to problem identified in this thread:

A selected drive is no longer valid.

The install order I took when encountering this issue was:

  • BizTalk prerequisites – W2K8 R1 x64, SQL 2008 R1, SQL 2008 R1 SP1
  • VS 2008 Team Suite with C++ unchecked (SQL express was also unchecked)
  • VS 2008 SP1
  • BizTalk 2009 x64
  • Other BizTalk 2009 installs such as WCF LOB SDK, Adapter Pack, etc.
  • BizTalk 2009 ESB Toolkit Pre-Requisites such as MSChart, VS 2008 SDK
  • Windows SDK 6.1 


Unfortunately, I was not able to come up with a corrective solution for handling this configuration incompatibility. I tried a couple things but was unsuccessful:

  • Install the hotfix 974479 which should resolve most of the problems with the Windows 6.1 and VS 2008 SP1. I was still unable to get the VS 2008 Team Suite installer to work
  • Uninstall the hotfix 974479.
  • Uninstall Windows SDK 6.1 
  • Uninstall VS 2008 SP1

These last attempts certainly show some despiration but I found that once the Windows SDK 6.1 is installed the VS 2008 Team Suite installer seemed to me to always fail. VS 2008 SP1 is a requirement for BizTalk 2009 so I could not choose to avoid this. I recommend avoiding the Windows SDK 6.1 if possible on a computer or VM with VS 2008 Team Suite and SP1 otherwise you may not be able to compile the ESB Toolkit.



Leave a comment

Using a Named SQL Instance with the ESB Toolkit


Lately I have been working on building out some VMs for working with BizTalk 2009/ESBT 2.0 and for BizTalk 2010/ESBT 2.1. I am working on a project that is targeting BizTalk 2010/ESBT 2.1 but there is a feature we would like to use which is currently only compatible with BizTalk 2009/ESBT 2.0. So I am working on managing the feature migration as well as planning for how things will work with BizTalk 2010.

One of the proprietary systems I work with uses a named instance in development for the SQL database and no default SQL instance exists. To keep everything relatively simple I have been installing BizTalk on the same named SQL instance. For most of the BizTalk prerequisites and setup this is straight-forward, but once I start working on the ESB Toolkit there are so many changes to make because the ESB Toolkit samples are all based on a default SQL instance.

It seems that the documentation is quite poor in this regard so I wanted to make a list of the things I have had to change to get a named instance to work properly. I did see Andy Morrison’s article mentioning bits of my content at but it does not mention all of the relevant items specifically for a named instance. Some of the items listed below are steps done before the ESB Toolkit itself but I am including them here for completeness.

Pre-Requisite Setup

  • Install SQL using a named instance
  • Configure BizTalk using the named instance. Most of the steps in the wizard will work automatically(if SQL is local) but the BAM Tools lines for BAM Analysis and BAM Star Schema databases will still require you to manually enter the named instance information.
  • The UDDI configuration wizard will pick up the named instance automatically (if SQL is local) so no extra work here.

ESB Toolkit Setup

  • During the ESB Toolkit Configuration Tool you will need to specify the name of the named instance. If SQL is local you can use “.\<instance name>”.

ESB Toolkit Management Portal Setup

  • Edit the web.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.Portal
  • Edit the App.Config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.UDDI.PublisherService
  • Edit the web.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.Exceptions.Service\ESB.Exceptions.Service
  • Edit the App.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.Exceptions.Service\ESB.Exceptions.Service.Implementation
  • Edit the web.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.BAM.Service\ESB.BAM.Service
  • Edit the App.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.BAM.Service\ESB.BAM.Service.Implementation
  • Edit the App.config in C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.AlertService
  • Open the ESB.Portal solution in C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.Portal and do a find on “data source=” to find a few other locations where the default SQL instance is used with Entity Data Models and other files
  • Open the ESBFunctions.ps1 file in C:\Projects\Microsoft.Practices.ESB\Source\Install\Scripts and search for “sqlcmd” to find places where SQL is being called using the default instance. I did a find/replace on “sqlcmd” and replaced it with “sqlcmd -S .\<instance name>” because my named instance was local. You can enter something different if your named instance is remote.

As you can see, there are so many different places that must be changed in order to use the ESB Toolkit with a named SQL instance. This list holds true for both BizTalk 2009 and BizTalk 2010.


, ,

1 Comment

Installation Challenges for BizTalk 2010 RTM


Today I kicked off the install of BizTalk 2010 RTM. On Friday of last week the BizTalk 2010 downloads were made available to MSDN customers and over the weekend the ESB Toolkit 2.1 RTM downloads also became available ( For some reason the Standard and Enterprise edition downloads are now almost twice the size of the Developer edition download.

In this post I just wanted to document a couple installation differences and challenges I encountered when installing BizTalk 2010 RTM. I decided to try to install onto the same VM where I had installed BizTalk 2010 Beta. Usually this has worked for me in the past unless there was some uninstall problem. For the timid, please start with a clean VM image.


Here are the things you should do if you are installing on a VM where BizTalk existed already:

  1. Remove all existing installs with BizTalk in the name.
  2. Remove Microsoft Enterprise Single Sign-On
  3. Remove all existing BizTalk databases
  4. Remove all existing BAM DTS packages – Open SQL Management Studio under Integration Services and check the packages under MSDB. Remove all of them. These are not removed by the uninstaller.
  5. Open the SQL Configuration manager and disable Shared Memory from the connectivity options. *new*

Next  I will give a little extra background and mention a few errors I got.

My first step was to uninstall anything with “BizTalk” in the name. So I did this. I started the installer next and got a message that a previous version of  Microsoft Enterprise Single Sign-On was installed and asked to remove this. I am guessing the version information in the registry must have changed between Beta and RTM. So I allowed it to uninstall and remove the SSO component. It ran a little longer but then I got an error about SSO:

The following platform components failed to install and will need to be manually installed before setup can proceed: Enterprise Single Sign-On Administration.

This problem was a little difficult to understand. I handled the problem by uninstalling SSO before running the BizTalk installer again. I had been installing BizTalk over the virtual network share VMWare provides but apparently this causes a problem for SSO. I copied the install files locally and then it no longer had a problem.

Another thing I found out changed with SSO between Beta and RTM is that now it is not acceptable for the SSO install to use the Shared Memory SQL connectivity option. Perhaps this is a security fix. Here is the error I got when trying to setup SSO on BizTalk 2010 with Shared memory enabled:

Failed to create the SQL database ‘SSODB’ on SQL Server ‘<machine name>\<instance name>’ (with SSO Administrator account ‘SSO Administrators’). (SSO)
For help, click:

(0xC0002A21) An error occurred while attempting to access the SSO database.
For help, click:

An error occurred while attempting to access the SSO database. See the event log (on computer ‘<machine name>’) for more details.
(SQL: 0x000000E9: A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 – No process is on the other end of the pipe.)) (SSO)

For help, click:

I had Shared Memory enabled when installing the BizTalk 2010 beta. This is actually now documented in the BizTalk install guide (I saw it in the Win 7 one): I also saw this in a good visual walkthrough BizTalk 2010 install guide made by Jay Kladiva at

It is interesting that Shared Memory actually has to be disabled because enabling Shared Memory or Named Pipes is typically the remedy for errors like this. I am guessing when the BizTalk installer sees this option for connectivity and tries to use it.

Once I get through the rest of the installation I will post back here if I encounter any other issues. Thanks!


1 Comment

Awarded BizTalk MVP again – Woohoo!

Thanks Microosft for again awarding me as a BizTalk MVP today! It is a big honor to be in the program. This will be my third year in the MVP program.

Since I am still in the process of transitioning my blog from the old Live Spaces location, I do not yet have some of the logos for the MVP Award and links to my forums posts. I will be working on getting this added to my blog site this weekend. For anyone that is interested, here is a link to my MVP profile: It mentions some of the various technical communities I am active in as well as some of the publications and speaking sessions I have done.

I realized that I have not really spoken much in a public way about the benefits of the MVP program. I am not sure if these comments about the program will hold true for all MVPs, this is just my experience. What I describe here is above and beyond all the software benefits given through the MVP program. In my mind the greater benefits are the many opportunities for career advancement and extension.

Here are a few things I love about the MVP program:

  • Great opportunities to be a bridge between Microsoft and technical communities – I have advocated on both clients and Microsoft’s behalf in many discussions. This is particularly helpful because there is a lot of miscommunication.
  • Early access to many products, initiatives, and planning sessions
  • Many opportunities for understanding how Microsoft works and functions
  • Excellent networking opportunities for connecting with other industry experts and veterans
  • Being in the MVP program requires me to stay competitive and relevant. This helps me keep up to date on my technical knowledge and focused on the future.

For anyone not in the MVP program, it is definitely something to aspire to and I think it is worth all of the hard, fun work. 🙂