Posts Tagged UDDI

ESB Toolkit 2.0 Configuration Tips

I have been working more and more with the ESB Toolkit 2.0 but occasionally run into issues where samples do not work or there are other miscellaneous errors. Here are a couple of my tips for common errors I have encountered while using the toolkit. All of these suggestions have been things I have done for a single BizTalk server installation. Through the forums some people have mentioned you should do different things for a multi-server BizTalk install.
I. Bad Request 400 Errors
I received this error quite a bit when first configuring the ESB Toolkit 2.0 on the ESB Portal page. This error is really not descriptive of the root problem. To resolve this issue I did the following steps:
  1. On the default web site or the one which hosts your ESB Portal, enable windows authentication.
  2. Stop iis, w3wp.exe (World-wide web service)
  3. Run the following commands to enable credential negotiation:
    cd “c:\inetpub\adminscripts”
    cscript.exe adsutil.vbs set w3svc/NTAuthenticationProviders “Negotiate,NTLM”
  4. Restart iis, w3wp.exe.
  5. 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.
  6. 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
Also, I found that if you install the UDDI components from BizTalk 2009 this will remove the credential negotiation from the IIS setting set above so you will need to redo the steps above after the UDDI install is run.
II. The BizTalk 2009 UDDI tools fail to connect to the UDDI registry. Here is one of the errors I was getting:
Event Type: Error
Event Source: UDDIRuntime
Event Category: Config
[[Error reading configuration settings:
Unable to read the Database.WriterConnectionString or Database.NotificationConnectionString configuration setting.]]
For more information, see Help and Support Center at
This problem happened to me when trying to use some of the UDDI samples in the ESB toolkit. I could also not use the UDDI website or the UDDI management tools except the UDDI management console. The root of this problem was that there was an authentication issue. Here is what I did to resolve it:
  1. Open the UDDI management console.
  2. Right-click on the UDDI item in the treeview and click Properties…
  3. 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.
  4. Click OK. Here is a photo of the setting page:

III. The Registry tab of the ESB Management Portal gives you an error. This occurs because the UDDI built-in tModels have not been loaded yet into the UDDI registry site. To resolve this issue, do these steps:
  1. 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.  

IV. The Resolver service sample does not work. Here is one of the errors I got:
Event Type: Error
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”‘.
Service: ResolverService
Method: Resolve
Error Id: ce981d9c-3745-45d1-bf98-f4cea7ef89b8
Error Source: mscorlib
Error TargetSite: Void HandleReturnMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessage) 
Error StackTrace:
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)
Exception rethrown at [0]:
   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.<>c__DisplayClass4.<CreateSearch>b__0()
   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)
For more information, see Help and Support Center at
To resolve this error, I did:
  1. Open ResolverService.svc’s web.config
  2. 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: 


, ,


BizTalk Dream Machine

I have been playing with the new features of BizTalk 2009 and have been finding a few bugs. But some of what is available with this release is awesome. For example, due to Visual Studio 2008 integration you can reference a WCF Service library from your BizTalk project. You can also reference a project that uses LINQ so will be able to use LINQ indirectly in a BizTalk map. Another cool thing is that you can reference a WF library from your BizTalk project. This makes it possible to call a WF method directly from BizTalk and potentially move logic over to a WF process from BizTalk. I have not tried running a workflow from the BizTalk host but that will be the next thing to try. I have not seen any new BizTalk orchestration shapes for calling WF activities or workflows either.
The new UDDI functionality included with the BizTalk 2009 beta is a little buggy at this point but the functionality seems to be a big step forward. More details on this soon.
Lots of the wish list ideas I have had for where BizTalk could be going are things I am testing right now. Check back here as I find new features as part of the beta.

, , ,

Leave a comment