UDDI 3 Configuration crashes when clicking on the Web Application page

When setting up UDDI 3 on a BizTalk multiserver configuration, the configuration tool might crash when clicking on the Web Application page. The following message will be logged in the event log:

Event Type:    Error
Event Source:    BizTalk DW Reporting
Event Category:    None
Event ID:    1000
Date:        2010-02-06
Time:        23:17:15
User:        N/A
Computer:    CONTBTS2K9
Description:

Faulting application configuration.exe, version 3.8.368.0, stamp 49b1da6c, faulting module configframeworkhelper.dll, version 3.8.368.0, stamp 49b1da6b, debug? 0, fault address 0x000823ba.

The reason for this error is that the account used to run the configuration tool is not local administrator on the SQL Server used for UDDI 3.

Installing UDDI 3 with a separate SQL Server

The installation documents doesn't explain how the setup for UDDI 3 is to be done when the SQL Server is installed on a separate machine than where the UDDI services are to be placed (in my case on the BizTalk 2009 server). Here is the steps I take.

1. Run setup.exe from the BizTalk media on the SQL Server and choose to install UDDI 3. Install only the database components.
   
   
   
   
   
   
   
   
2. When the installation finishes, choose to configure the UDDI services.
3. Select to do a custom configuration and specify the service account to use.
4. Go to the UDDI Services Database Component page of the configuration and choose to enable UDDI Services Database Component and deselect the SSL requirement.
   
   
   
   
   
   
   
   
   
5. Apply the configuration.
   A failure with the apply task will most likely be due to a lack of permissions to the SQL Server. Make sure that the account you are logged in as (or use to run the configuration tool) has the appropriate permissions to SQL Server.
   If successful, you should end up with a UDDI3 database on your SQL Server.
   
   
   
   
   
   
   
   
6. Start the UDDI3 setup from the BizTalk media on the BizTalk server.
7. Choose to install the components necessary, except for Database Components.
   
   
   
   
   
   
   
   
8. Finish the installation and select to run the configuration tool.
9. Enter the SQL Server name and the credentials for the service account and select to do a custom configuration.
10. Check the Enable UDDI Services Web Application box.
    
    
    
    
    
    
    
    Note! If you lack the proper credentials to the UDDI3 database on the SQL Server, you will see a red cross next to the Data Store name with an error message of "The database UDDI3 on BTSSQLSRV01 is not a valid UDDI database.". The database is in fact just fine, but the account used to run the configuration tool doesn't have all the required permissions to access the database.
    
    
11. Go to the next page and check the Enable UDDI Service Notification Service box. Enter the information for SMTP server and E-mail address.
    
    
    
    
    
    
    
12. Apply the configuration.
13. Go to the URL specified for the UDDI services and verify that everything is up and running.
    

Complete installation of ESB Toolkit 2.0

Here is my guide for installing the ESB Toolkit 2.0 in BizTalk 2009. It's for 32bit and everything is located on the same server.

1. Import ESB.Core into BizTalk
2. Import ESB.Exceptions into BizTalk (overwrite resources)
3. Import ESB.JSM into BizTalk (overwrite resources)
4. Install each msi onto the server as well (checkbox at the end of the import wizard)
5. Give SQL Service Account permission to BAM databases by running this query in SQL Management Studio
   USE BAMStarSchema
   GO
   CREATE USER SQLService FOR LOGIN [W1BTS3\SQLServiceAccount]
   GO
   EXEC sp_addrolemember db_datareader, SQLService
   GO
6. Deploy BAM activities
   "c:\program files\microsoft biztalk server 2009\tracking\bm.exe" deploy-all -definitionfile:"c:\program files\microsoft biztalk esb toolkit 2.0\bam\microsoft.biztalk.esb.bam.exceptions.xml"
   "c:\program files\microsoft biztalk server 2009\tracking\bm.exe" deploy-all -definitionfile:"c:\program files\microsoft biztalk esb toolkit 2.0\bam\microsoft.biztalk.esb.bam.itinerary.xml"
7. Run ESBConfigurationTool.exe and apply the configuration before hitting the next page.
8. Install UDDI from the BizTalk media. Make sure to uncheck the SSL requirement.
9. Run the UDDI Publisher tool \Bin\Microsoft.Practices.ESB.UDDIPublisher.exe).
10. Run "C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" -r -y
11. Extract ESBSource.zip to C:\Projects\Microsoft.Practices.ESB
12. Remove the read-only attribute on all files and folders.
13. Open PowerShell and run Set-ExecutionPolicy unrestricted
14. Open ESB.AlertService sln, set setup project platform to x86
15. Build ESB.AlertService
16. Open ESB.Portal, verify web.config
17. Verify ExceptionService web.config
18. Build ESB.UDDI.PublisherService
19. Run portal install script
20. Enable TCP/IP connections in SQL Server
    

With this done, everything should be up and running properly.

BizTalk 2009, ESB Toolkit 2.0 and UDDI

I have spent numerous hours trying to publish the UDDI services in the ESB Toolkit using UDDIPublisher.exe. I have received pretty much every error possible, from 404 to 503 to the entire IIS falling apart. I just found the solution: don't install UDDI as a normal Windows 2008 role, but install UDDI3 as a part of the BizTalk Server install.

At one point I managed to get UDDIPublisher.exe to install the services properly, but I cannot remember the route I went. Most likely it included changing permissions in IIS, UDDIPublisher.config as well as ApplicationHost.config and also fiddling with the account used to run the whole shebang. By installing UDDI from the BizTalk DVD and then running the publishing exe, it works without a hitch.

The woe of installing ESB Toolkit 2.0

Installing the ESB Toolkit 2.0 by following the official documentation is pretty much a task doomed to fail. There is however quite a number of guides available on the net. One of the better ones I've found is from Quicklearn: Getting up and running with BizTalk ESB Toolkit 2.0.

This one helped me with a basic issue that caused some grief.

After importing and installing the Core and Itinerary msi packages, I tried to run the Management Portal installation script Management_Install.cmd which worked half way before spewing out a ton of error messages.

I started looking at this issue and noticed that a number of exceptions came from IIS related components, for example: "Property 'AppPoolIdentityType' cannot be found on this object; make sure it exists and is settable.".

It seemed I had missed to enable IIS 6.0 extensions properly. The ESB Toolkit uses IIS 6.0 calls and these components are not installed by default when adding IIS 7 in Windows 2008 Server.

Later on I found myself with a minor issue when deploying the BAM activities.
Deploying View... ERROR: The BAM deployment failed.
OLE DB error: OLE DB or ODBC error: Cannot open database "BAMStarSchema" requested by the login. The login failed.; 42000.

Clearly a better error message than before, so I added the appropriate account to the databases.

USE BAMStarSchema
GO
CREATE USER SQLService FOR LOGIN [W1BTS3\SQLServiceAccount]
GO
EXEC sp_addrolemember db_datareader, SQLService
GO

With this change, the deploy was successful.

I'm still stumped on why the installation of the toolkit is so badly documented and lack a proper guide since the amount of settings, scripts and packages to handle is quite vast and it's so easy to miss a required setting/permission/whatever that will make at least parts of the installation process to fail.

BizTalk SQL adapter deadlocking issues

A few months ago I had an assignment at a company that was having issues with their BizTalk installation. When examining their integration platform I noticed that the event log was filled with deadlock exceptions from the SQL adapter. It was the standard error message stating that a message sent to adapter "SQL" is suspended. The transaction was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

The vast amount of deadlocks that occured directly pointed me to the procedures that was being called by the receive locations.

In this particular flow, a number of receive locations where scheduled to poll a database for data every minute. Nothing unusual about this so far. When looking at the procedures, I saw that each one logged the time of execution to a log table used for debugging purposes. This is a valid practise, if it weren't for the fact that the logging was set up wrong. Instead of letting each procedure write it's own row with execution data, the table had one single row with a number of columns, one for each procedure.

So, only one row in the table, which all the procedures tried to write to. The chance of all procedures running at the same time and therefore trying to do an update on this table row at the same time is actually pretty slim if the procedures run fast enough. However, the procedures in this case did take a few seconds to run.

Adding to this is the fact that BizTalk will wrap the call in a serializable transaction meaning that the row will be locked throughout the entire execution of the procedure. The risk of another procedure trying to gain access to the table while its locked increases then quite a bit, resulting in the high volume of deadlocks I saw in the event log.

Since this was in production and a valid test environment was missing (shudder), I made certain that the log table wasn't used for anything (you never know) and then commented out the UPDATE statements in the procedures. Since the entire flow were to be rewritten from scratch, I saw no need to more or less do a transposition of the table to get the procedure timestamps on their own rows since the data were of no more use.

The result: The number of deadlocks were reduced with 97% and according to the server operators, the BizTalk/SQL Server installations now runs a lot better while we build the replacement to this flow.

What to remember from this is that it is both vital to know how BizTalk handles transactions in the SQL adapter and to also know the different table and locking hints available in SQL Server.

BizTalk orchestration expression shape unable to write entries to Windows eventlog

I were just in the process of debugging an orchestration in BizTalk 2006r2 the old fashioned way: writing eventlog entries from an expression shape when I noticed that I got an exception in the eventlog instead. The exception was of type "Security Exception" with an inner exception detailing "Requested registry access is not allowed.". Easy enough, a quick google turned me to this blogpost and the solution which is to add the appropriate BizTalk service account to the eventlog node in the registry. After setting the permission, writing entries work.

The beginning

The professional life is starting to fill up with interesting bits and pieces that I encounter both during my own time as well as when I'm working with a customer. This blog will be a place to keep all those pieces together, so that I can remember them and also so others can (hopefully) learn a thing or two.