Archive for February, 2013

ESB Toolkit 2.2 Beta (Windows Azure VM): Configuration

February 25, 2013 4 comments


The following is a “brain-dump” of my experiences configuring ESB Toolkit 2.2 on a Windows Azure VM using the BizTalk Server 2013 beta (February 15th 2013 revision) on Windows Server 2012.

What’s New

There have been some enhancements made to the ESB Configuration Tool.

Default Configuration

The ability to apply a default configuration, similar to that provided with the BizTalk Server Configuration Tool, has been added. Clicking on the root tree node, ESB Configuration, produced an empty screen in previous versions of the ESB Toolkit but with ESB Toolkit 2.2 the following screen containing default configuration properties appears.


Using this screen we can set default values for the Database Server, IIS Web Services and the BizTalk User Groups and have those applied across to the Exception Management and ESB Core Components.

This simplifies the configuration for typical installations. For greater control of the configuration the Exception Management and ESB Core Components can be customised using the approach provided with previous versions of the ESB Toolkit.

ESB BizTalk Applications

This is a new node that has been added to the configuration tool. It consists of two options; Enable ESB Core Components in BizTalk Server and Enable ESB JMS/WMQ Components in BizTalk Server.


These replace the post configuration steps that were required with previous versions of the ESB Toolkit which involved manually running MSI’s to create the BizTalk Server Applications.

Moving these steps of the configuration process to the configuration tool is an obvious progression and you’d have to wonder why they were ever left as a manual step when the configuration tool was first introduced with ESB Toolkit 2.0.


As mentioned above a custom configuration is similar to the steps followed in previous versions of the ESB Toolkit, so we’ll cover a default configuration here.

1. Launch the ESB Configuration Tool.

2. Click on the ESB Configuration node and enter the Database Server, User Account and Password. The Website Name can be selected here – I’ve left it as the Default Web Site. I’ve also left the default BizTalk User Groups as this is an isolated configuration.


3. Click on the ESB BizTalk Applications node.


4. I am just going to install the ESB Core Application so select the Enable ESB Core Components in BizTalk Server checkbox and leave the Use Default Binding option selected.


5. Click Apply Configuration


The steps above should result in a fully configured ESB Toolkit. Some of the issues I encountered in reaching this point have been listed below.

IIS Install Registry Key is missing. Check that you have IIS 6.0 Extensions installed.



The ESB Toolkit is still reliant on IIS 6.0 extensions which are not installed by default on the Windows Azure BizTalk Server 2013 Beta image. To resolve this issue you must install the IIS 6 Management Console feature.


Note: The IIS 8 Management Console feature is not installed by default either on the Azure image but that is not a pre-requisite for the ESB Toolkit.


Cannot open database BizTalkMgmtDb on server XXXXX. Verify that you have the required security permissions and that communication between…(the error message cuts off here).



So far I have been unable to reproduce this error.

Application: Microsoft.Practices.ESB already exists



In an attempt to resolve the error in 2 above I decided to test out the resilience of the ESB Configuration Tool when things go wrong. I re-applied the configuration again and this time received the error above informing me that the Microsoft.Practices.ESB application already exists. Clearly the ESB Toolkit Configuration Tool still doesn’t support rollbacks or idempotency.

DeployPolicyAsResource failed (full error message is not visible)



After my attempt to re-apply the configuration in 3 above was unsuccessful I carried out the following steps to allow me to retry the configuration.

1. Click Unconfigure Feature


2. Select EsbBizTalkApplications and click Accept


3. The ESB BizTalk Applications features are now unconfigured


The reason for just unconfiguring the ESB BizTalk Applications is because I was able to identify this step as the one where the original error occurred. I could see that each of the other steps had completed successfully by viewing their state. This is done by clicking on their nodes in the ESB Toolkit Configuration Tool; a greyed out screen indicates a configured component.

After unconfiguring the ESB BizTalk Applications I selected Enable ESB Core Components in BizTalk Server again and applied the configuration which produced the “DeployPolicyAsResource failed” error.

As can be seen in the screen shot above the full error message is not visible. However, hovering over the ESB BizTalk Applications node (or any node that resulted in an error) will briefly show a tool tip containing the full error message. Depending on the size of the error message this can take a number of attempts to view the full error, as was the case here.

I was able to see that the error was being caused by the existence of the ESB.Deployment.Policy policy in the BRE which couldn’t be overwritten as it was in the “Deployed” state.

This was confusing as I had assumed that unconfiguring the ESB BizTalk Applications would have resulted in the Microsoft.ESB.Practices artefacts, including the ESB.Deployment.Policy policy, being removed.

I unconfigured the feature again and performed a visual check and confirmed everything had been removed even going as far as checking the database tables. However, no matter what I tried the same error appeared.

As a last resort I decided to unconfigure the ESB BizTalk Applications, close the ESB Toolkit Configuration Tool, launch the ESB Toolkit Configuration Tool and configure the ESB BizTalk Applications.


Result! It appears that caching in the ESB Toolkit Configuration Tool was the cause.


The enhancements that have been made to the ESB Toolkit Configuration Tool fully automates the configuration process and will hopefully remove the initial barrier to adoption I have spoken about on previous posts. There is still room for improvement though, particularly when things go wrong. Not being able to view the full error message is frustrating. Hopefully with it being a cosmetic fix this will be resolved in the final release.

Be sure to install the IIS 6 Management Console feature prior to configuring the toolkit and in the event of an error during configuration:

  1. Unconfigure the offending component
  2. Close the ESB Configuration Tool
  3. Launch the ESB Configuration Tool
  4. Re-configure the component