|This is the third installation for installing the Microsoft ESB 2.0 Toolkit. This blog outlines the steps for installing the ESB Toolkit in a 64-bit multi-server environment. This article assumes a two node BizTalk Cluster. If you have questions please feel free to email me email@example.com. Again sorry for the images .. its was my most direct approach to getting the article up.|
Instructions for installing BizTalk, SSO, and BAM can be found here.
One thing to note is to make sure that you have UDDI installed on each BizTalk node. You can follow the instructions for installing UDDI on a passive node found in this post. The goal on the BizTalk nodes is to connect to the existing UDDI3 database, so you use the "use existing" options in the UDDI Configuration console.
In our environment we have a three server load balanced web farm that is our primary host for the UDDI 3.0 Web Site, so BizTalk is not our primary UDDI server in our scenario.
If you do not install UDDI on the BizTalk tier the Microsoft.Practices.ESB.UDDIPublisher.exe will fail and not put the appropriate entries in the UDDI resposity and that will cause the ESB Managment Portal to throw errors, among other things.
I am sure this is not the only way or necessarily the best way to install the Toolkit but it worked for us on what proved to be a challenging installation. I will continue to add information to this post as to provide clarity in response to questions.
A shout out goes to Mark London for helping with the deployment of UDDI, SSO, BizTalk, and the Toolkit in production.
Physical View Diagram
This is a target production environment. Currently we have 2 BizTalk nodes per Datacenter but will be scaling over the coming year. Our BizTalk Tier is Active/Passive from a Windows Clustering perspective and Active/Active from load balancing perspective for the OnRamps.
|Pre Installation Notes|
AD Groups and Permissions
|BizTalk Server Local Group Permissions|
BizTalk Tier IIS 7 Configuration
App Pool Sites
ESB Management Portal Web.Config
In order to get the portal working remotely we had to modify the web.config and enable asp.net impersonation. The Portal runs in the user context of the svcesbportal service account.
Also, we modified the webHttpBinding to have the following setting:
|Microsoft.Practices.ESB Application Bindings|
During the installation we went with the default bindings provides by the MSI. Doing so will leave the OnRamps running under the BizTalkServerIsolatedHost Receive Handler.
We manually created a WCF-WSHttp Adapter Hander and associated it with the OnRamp.Itinerary.WCF ReceiveLocation since it is our primary ESB OnRamp.
Also, I mention running a script against the ESBExceptionDB. The script is shown in an image. Here is the text for the script.
Note: this step may be redundant with the SA permissions that are added later. It was a step that we took in the process ... so its included here.