Posts Tagged ESB
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, http://support.microsoft.com/kb/974479 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: http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/2f3d0378-3175-49ae-acb7-012594a1bf3c):
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.
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 http://geekswithblogs.net/andym/archive/2010/02/02/137753.aspx 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.
- 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.
- On the default web site or the one which hosts your ESB Portal, enable windows authentication.
- Stop iis, w3wp.exe (World-wide web service)
- Run the following commands to enable credential negotiation:
cscript.exe adsutil.vbs set w3svc/NTAuthenticationProviders “Negotiate,NTLM”
- Restart iis, w3wp.exe.
- To check this, open c:\windows\system32\inetsrv\metabase.xml and then search for NTAuth to see if it is just “NTLM” (which is the wrong value) or “Negotiate,NTLM” which is the correct value.
- To get the portal to work again, uninstall the management portal using the powershell script and then reinstall it. The script is found at C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\ESBSource\Source\Samples\Management Portal\Install\Scripts\Management_Install.cmd
Event Source: UDDIRuntime
Event Category: Config
[[Error reading configuration settings:
Unable to read the Database.WriterConnectionString or Database.NotificationConnectionString configuration setting.]]
- Open the UDDI management console.
- Right-click on the UDDI item in the treeview and click Properties…
- Go to the Security tab and choose “Windows integrated publisher authentication” rather than the mixed mode default setting of Windows integration and UDDI publisher authentication.
- Click OK. Here is a photo of the setting page:
- To check if the tModels exist on your UDDI server, open http://localhost/uddi, and click on the Publish tab. This will open a split frame page with a treeview on the left. If you do not see the microsoft-com:esb:runtimeresolution items, then you need to do step 2. Here is a picture of the tModels in the UDDI site:
2. Run the following command:
cd “c:\program files\microsoft biztalk esb toolkit 2.0\bin”
3. This will install the ESB tmodels into UDDI. Hit refresh or do an iisreset and refresh the page to see the tModels.
Event Source: BizTalk ESB Toolkit 2.0
The HTTP request is unauthorized with client authentication scheme ‘Negotiate’. The authentication header received from the server was ‘NTLM,Basic realm=”localhost”‘.
Server stack trace:
at System.ServiceModel.Channels.HttpChannelUtilities.ValidateAuthentication(HttpWebRequest request, HttpWebResponse response, WebException responseException, HttpChannelFactory factory)
at System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory factory, WebException responseException)
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.Practices.ESB.UDDI3.UDDI_Inquiry_PortType.get_bindingDetail(get_bindingDetailRequest request)
at Microsoft.Practices.ESB.UDDI3.UDDI_Inquiry_PortTypeClient.Microsoft.Practices.ESB.UDDI3.UDDI_Inquiry_PortType.get_bindingDetail(get_bindingDetailRequest request)
at Microsoft.Practices.ESB.UDDI3.UDDI_Inquiry_PortTypeClient.get_bindingDetail(get_bindingDetail get_bindingDetail1)
at Microsoft.Practices.ESB.UDDI3.UddiClient.GetBinding(String bindingKey)
at Microsoft.Practices.ESB.Resolver.UDDI3.ResolveProvider.ResolveUddi(String config, String resolver, String keyPrefix, Dictionary`2 resolutionOrig)
at Microsoft.Practices.ESB.Resolver.UDDI3.ResolveProvider.Resolve(String config, String resolver, XmlDocument message)
at Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve(ResolverInfo info, String message)
at Microsoft.Practices.ESB.Resolver.ResolverMgr.ResolveFromService(String config, String message)
at Microsoft.Practices.ESB.Resolver.ResolverMgr.ResolveEndpointWithCache(String config)
at Microsoft.Practices.ESB.Resolver.ResolverMgr.ResolveEndpointWithCache(Dictionary`2 resolverCache, Object resolverCacheSyncRoot, String config)
at ResolverService.Resolve(String configuration)
- Open ResolverService.svc’s web.config
- Set proxyCredentialType in config to Windows, new values shown below:
<transport clientCredentialType=”Windows” proxyCredentialType=”Windows” />
3. In the test client, modify the web.config transport security to use clientCredentialType of Windows and a proxyCredentialType of Windows, new values shown below:
<transport clientCredentialType=”Windows” proxyCredentialType=”Windows realm=”” />
This is tip is partially based on this blog post: http://www.kodyaz.com/blogs/software_development_blog/archive/2008/02/25/849.aspx
- Build all BizTalk projects with custom pipelines using the ESB Toolkit components
- Copy all compiled BizTalk assemblies and referenced ESB assemblies to the BizTalk pipeline components folder (usually C:Program FilesMicrosoft BizTalk Server 2009Pipeline Components)
- GAC all compiled BizTalk assemblies and referenced ESB assemblies
- Add BizTalk assemblies and ESB pipeline component assemblies to relevant BizTalk application