Error configuring BizTalk Server 2006

Today I had quite some troubles installing BizTalk Server 2006. As I have previously installed BizTalk many times without being stuck on a problem for so long, I thought I would blog about it. Who knows, it might help some other soul encountering the same issue.

My configuration was the following:

• 1 Windows Server 2003 64-bit running SQL Server 2005.
• 1 Windows Server 2003 64-bit with BizTalk Server 2006 installed but not yet configured.

Both machines had MSDTC and COM+ installed and running, a pre-requisite to install BizTalk on a multiple-server environment.
All the BizTalk Users as well as the Windows Account used to install BizTalk had the necessary rights and belonged to the necessary Groups. See a previous post of mine for more information; Biztalk 2006 multi-server installation guide.

So, after having installed BizTalk Server 2006, the BizTalk Server needs to be configured by using the BizTalk Server Configuration tool and there the weirdest thing happened: it failed, but not completely! Enterprise SSO (Enterprise Single Sign-On) and Business Rules Engine (BRE) components were configured successfully while Group and BizTalk Runtime failed.
Thinking I made some human mistake in the configuration, I retried 2 times but the same problem happened. On a side note, before retrying to configure BizTalk, I had to manually delete the BizTalkMgmtDb as it was created even as the configuration step creating that DB failed.

I then read line by line the log file produced by the configuration tool and searched for the source of the problem. I will paste here the relevant parts:

[1:57:09 PM Error ConfigHelper] [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
[1:57:09 PM Error ConfigHelper] SQL error: 08001 Native error code: 17
[1:57:09 PM Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(1176): FAILED hr = 80004005
[1:57:09 PM Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(918): FAILED hr = 80004005
[1:57:09 PM Info ConfigHelper] Did not find existing database: BizTalkMgmtDb on computer:
[1:57:09 PM Info RuleEngineConfig] Management database (server = , database = BizTalkMgmtDb) doesn't exist

With this information in hand, I suspected something was wrong with the credentials and I checked all the Users and Groups in Active Directory and also checked that I was admin of the SQL Server machine but everything looked ok. I nevertheless re-tried the configuration a few times, being extra careful with every setting but unsuccessfully. I then moved on to next problem in the log file.

[2:08:41 PM Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\service.cpp(729): FAILED hr = 80070421
[2:08:41 PM Warning ConfigHelper] The account name is invalid or does not exist, or the password is invalid for the account name specified.
[2:08:41 PM Warning ConfigHelper] Failed to validate service credentials for account: %1
[2:08:41 PM Info BtsCfg] Check Your NT Account Specification

Here the configuration log complains about Windows Credential issues again. Everything was pointing out to Active Directory, this would reveal to actually point me in the wrong direction. So, as I could still not find any problem in AD, I moved on to the next problem I could find in the log:

2008-09-12 14:13:16:0075 [INFO] WMI Deploying 'C:\Program Files (x86)\Microsoft BizTalk Server 2006\Microsoft.BizTalk.GlobalPropertySchemas.dll'
2008-09-12 14:13:22:0184 [WARN] AdminLib GetBTSMessage: hrErr=80070002; Msg=The system cannot find the file specified.;
2008-09-12 14:13:22:0184 [WARN] AdminLib GetBTSMessage: hrErr=c0c02560; Msg=Failed to read "KeepDbDebugKey" from the registry.
The system cannot find the file specified.;
2008-09-12 14:13:22:0184 [INFO] WMI Error occurred during database creation; attempt to rollback and delete the partially created database'ny-agbdb-301\BizTalkMsgBoxDb'

Two points here:

• The file “T:\Program Files (x86)\Microsoft BizTalk Server 2006\Microsoft.BizTalk.GlobalPropertySchemas.dll” was present on the file system so it didn’t seem there was anything I could do about it.
• The key “KeepDbDebugKey” did not exist in the registry of running healthy BizTalk systems so I supposed this registry key exists only temporarily during the BizTalk configuration procedure.

I then moved on the next potential problem in the log file:

2008-09-12 14:14:02:0465 [ERR] WMI Failed in pAdmInst->Create() in CWMIInstProv::PutInstance(). HR=c0c025b3
2008-09-12 14:14:02:0465 [ERR] WMI WMI error description is generated: Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.

Here the configuration tool log entry complains about a Transaction from the System.EnterpriseServices library. As this package refers to Distributed Transactions (MS DTC), I doubled checked that MS DTC was running well on both machines, checked firewall configurations but all the necessary ports were open.
I then started to try to troubleshoot DTC following the MSDTC troubleshooting guide from Microsoft and found a utility called dtctester that can be downloaded from the KB 293799.

The dtctester test failed and so I was now sure that the problem was related with DTC. I re-checked the firewall settings, checked the dual network adapter and the DNS as advised by Microsoft and found out that the problem lied with the DNS having some wrong reverse mappings (IP address -> hostname mappings).

As a corollary, notice that the only log information that proved to point me to the actual source of the problem were log entries with the string [ERR] in their header. All others had either [INFO] or [WARN].

To conclude, I would advise to:

• Use dtctester before operating a BizTalk multi-server installation.
• When running into problems, look first at the log entries having either the [ERR] or Error string in their header - It indeed seems there are two different formats of log entry header in the log file produced by the Configuration tool. While looking first for the Error type of log entries sounds obvious, it seems that not many people are aware of the log entry header formats and the log entry types generated in the log file.

How to purge BizTalkMsgDb?

If the BizTalk Message Box database (BizTalkMsgDb) grows too large, performance of the database subsystem will reduce. As a rule of thumb, the BizTalkMsgDb should never grow larger than 5 Gb for large systems with long running transactions. For high-volume environment with no long running transactions, the BizTalkMsgDb size should be much smaller than 5Gb.

Would your message box have already grown too large and the system become unresponsive, you might want to clean up the BizTalkMsgDb database manually but keep in mind that:

• The BizTalk Server must be taken down during the procedure.
• All existing messages will be purged and lost.

There is an article in the MSDN documentation that explains in details how to manually purge data from the Message Box Database.

To make a long story short, here is step by step summary:

• Stop ALL BizTalk service host instances from the Services console.
• Restart IIS by running IISRESET from the command prompt if you are running any adapters in isolated hosts (for example HTTP, SOAP, or WCF).
• Execute the stored procedure bts_CleanupMsgbox on your message box database. If the stored procedure does not exist, create it by running the sql script “msgbox_cleanup_logic.sql” found in the directory “<BizTalk installation directory>\Schema\”.
  Important note: If you are running BizTalk Server 2006, you first have to get an updated version of the Msgbox_cleanup_logic.sql file to (re)create the bts_CleanupMsgbox stored procedure at http://support.microsoft.com/kb/924715. The hotfix is available for download directly without having to contact MS. If you are running BizTalk Server 2006 R2 then the updated version of the Msgbox_cleanup_logic.sql file is already installed and you do not need to download the hotfix.
• Execute the stored procedure bts_PurgeSubscriptions on your message box database. If the stored procedure does not exist, you can create it by inspecting the sql script “msgboxlogic.sql” found in the directory “<BizTalk installation directory>\Schema\”. Copy paste only the part of the script that creates this specific stored procedure and run it.

As deleting data in a database does not reduce the size the database files on the disk; you need to shrink the database files if you want to reduce its physical size. There are 2 simple ways to do it:

• Through SQL Server Management Studio, right click on the BizTalkMsgDb database, click on Tasks > Shrink > Database
• Through T-SQL, using the DBCC SHRINKDATABASE command: DBCC SHRINKDATABASE (BizTalkDTADb);

There is also another useful command to truncate the database logfile, would it be necessary:
BACKUP LOG BizTalkDTADb WITH TRUNCATE_ONLY

Microsoft does not support this procedure on production systems simply because this will purge production data. So, as long as you keep in mind that all existing messages will be purged, it is safe to run it on a production environment.

BizTalkDTADb grows too large – How to purge and maintain the database?

The BizTalkDTADb is a BizTalk database that stores health monitoring data tracked by the BizTalk Server tracking engine. It is commonly called the “BizTalk Tracking Database”. This database can grow relatively quickly in size depending of the kind of load your server is under.

I will explain first what should be done to keep the database healthy (by which I mean to keep it under a reasonable size) and after how to clean up the database if it grew up so large that the normal clean up method doesn't work anymore.

1. How to maintain the BizTalkDTADb?

Each BizTalk service instance running is processing data and while the data is processed, BizTalk tracks it and saves it in the BiztTalk Tracking Database. This means that the Tracking Database will grow indefinitely over time which is obviously not a viable option.
There is an SQL job called “DTA Purge and Archive (BizTalkDTADb)” that is installed on the BizTalk SQL Server which is used for cleaning up (deleting old tracking information) the BizTalkDTADb. That job is not enabled by default so the first thing that should be done after installing BizTalk server is to configure and enable the job. See here for information about how the cleanup process works and here for information on how to configure the SQL job. Basically, the job calls a single stored procedure on the BizTalkDTADb and once edited should looks like the following:

exec [dbo].[dtasp_BackupAndPurgeTrackingDatabase] 1, 0, 1, '\\MyBizTalkServer\backup', null, 0

The 4 first parameters are the one that you need to know about. The 2 first are the number of hours and days for which completed instances will be cleaned up. The third one is the number of days after which even non completed instance will be cleaned up. The fourth is the location of the backup folder.
This means that the SQL job will back up the BizTalkDTADb each time it runs, making that backup files will fill up your disk subsystem pretty quickly if nothing is done about it! Backups are important in case of a Database crash and that the Tracking Database needs to be restored.

If you do not consider the Tracking Database to be of enough importance to be backed up and have the extra burden to manage the backups, you can modify the “DTA Purge and Archive (BizTalkDTADb)” SQL job as explained here. This way, the job will only purge the tracking database without backing it up. It is especially applicable for development and QA environments and might also apply to your production environment.
In short, the only change that needs to be done in the SQL job is to modify the T-SQL statement run by the job. It needs to execute the SP dtasp_PurgeTrackingDatabase instead of dtasp_BackupAndPurgeTrackingDatabase.

The final T-SQL statement executed by the SQL job will be similar to the following:

declare @now as datetime
set @now = GetUTCDate()
exec [dbo].[dtasp_PurgeTrackingDatabase] 0, 3, 6, @now

In this case I keep complete instances in the Tracking DB for 3 days and incomplete one for 6 days, everything older should be purged. As you see there is no path to specify for the backup location as no database backup is executed.

Instead of modifying the original SQL job you could alternatively disable it and create a new job with the appropriate T-SQL call. That is how I have done it myself and consider it to be a best practice.
Moreover, I scheduled the job to run every 5 minutes. This has proven to be a good time interval. I used to run the job every 30 minutes only but I ever encountered cases where the clean up procedure did not keep up with the amount of tracked data and I ended up with a huge tracking database which I had to purge manually, as I will explain next.
So, a 5 minutes interval to run the job seems to also be a best practice from my experience.


2. How to manually purge the BizTalkDTADb?

You will have to manually purge the BizTalkDTADb database if it grew too large either because the clean up procedure was not started or the clean up procedure could not keep up with the amount of data saved in the Tracking Database.
This is explained in details here but, in short, the important points are:

- All the BizTalk services used by BizTalk needs to be stopped. This means all the BizTalk host service instances, Enterprise SSO, BizTalk Rules Engine, EDI service, BAM, BAS and IIS if they are used.

- Open Microsoft SQL Server Management Studio and run the following SQL statement on the BizTalkDTADb: exec dtasp_PurgeAllCompletedTrackingData

Once the procedure is executed, a lot of space will have been freed in the Tracking Database. The database will nevertheless still take the same amount of space on the disk subsystem because deleting data in a database does not reduce the size the database takes on the disk. If you want to reduce its size on the disk, you need to shrink it. You can do that in 2 ways:

1. Through SQL Server Management Studio, right click on the BizTalkDTADb database, click on Tasks > Shrink > Database



2. Through T-SQL using the DBCC SHRINKDATABASE command:
DBCC SHRINKDATABASE (BizTalkDTADb);
The reference of the T-SQL DBCC SHRINKDATABASE command can be found here.

Custom Pipeline Component deployment gotcha.

When you create custom pipeline, you might want to compile and install the custom pipeline component in the GAC first before adding the pipeline component in the toolbox. That way, the custom pipeline solution will reference the custom pipeline component from the GAC instead of its location on the disk.
The reason behind this is that if you install the pipeline component library on your production servers only in the GAC and if you did not GACed the pipeline component before using it in the custom pipeline, an exception is raised saying that the custom pipeline cannot be found (as the custom pipeline refers to a custom pipeline component on the local drive instead of the GAC). See a full explanation of the problem on Stephen W. Thomas' blog.

Note that if you follow the BizTalk documentation on Deploying Pipeline Components, it is advised that the assembly should be deployed in both the GAC and the <installation directory>\Pipeline Components folder. I would advise to follow this way so it won’t matter how you or your developers create and compile the pipeline and their components; it will always work when the code is moved to the production environment and thus avoid unnecessary stress in the case it would have gone wrong because one developer referenced his component in a different way.

EDIT for BizTalk Server 2006 R2:
I have just notice after having published the post that the documentation has been changed for BizTalk Server 2006 R2 and that now the documentation says:

All the .NET pipeline component assemblies (native and custom) must be located in the \Pipeline Components folder to be executed by the server.

and:

You do not need to add a custom pipeline component to be used by the BizTalk Runtime to the Global Assembly Cache (GAC).

So now, Microsoft officially advises to put the custom pipeline component libraries only in the \Pipeline Components and not in the GAC anymore. If you still have BizTalk Server 2006 installed on your machine like I do, you will see that the local BizTalk documentation still says as mentioned in my original post.

BizTalk Server 2006 Custom Functoid Documentation Mistake

When you develop a custom functoid, there are 5 important tasks to do:

1. Create a resource file with the various resources such as functoid’s name, description, tooltip and icon.
2. Create the class that will implement the functoid. This class must derive from the Microsoft.BizTalk.BaseFunctoids.BaseFunctoid class.The constructor must override the bas class constructor and call a certain number of methods and properties so that the custom functoid can run properly at run-time as well as integrate well into the Visual Studio’s mapper.
3. Create a member method in the functoid class that will actually implement the functionality of the custom functoid (its business logic).
4. Compile and sign the functoid project into an assembly with a strong name key file (so that the assembly containing the custom functoid can be deployed in the GAC).
5. Copy the assembly to C:\Program Files\Microsoft BizTalk Server 2006\Developer Tools\Mapper Extensions and add the functoid in Visual Studio’s ToolBox. You must also install the assembly into the GAC so that the functoid is available to BizTalk at runtime.

Today I found out that the BizTalk Server 2006 documentation has a mistake in the custom functoid development section: Using BaseFunctoid, which relates to the point number 2 in my previous list of tasks.
That section says that the constructor of the functoid must make a call to the SetupResourceAssembly method to point to the resource assembly. It details:

Include a resource file with your project. If building with Visual Studio, the resource assembly must be ProjectName.ResourceName.

In my experience this is not true, when I build my custom functoid assembly in Visual Studio, I have to call the SetupResourceAssembly method with FunctoidNameSpace.ResourceName as parameter instead of ProjectName.ResourceName. If I follow the documentation’s advice, the resource information such as functoid’s name and icon do not appear in Visual Studio’s toolbox, proving that the resources could not be found by the IDE.

The only case that it would work as mentioned in the documentation would be if the project name and the namespace of the functoid were identical, which happens by default in Visual Studio. Indeed, when you create a new project with Visual Studio 2005, a default namespace will be created for the project, its value being the project name. You can see the default namespace value by right-clicking on your project files and click “properties”.

BizTalk Expression Shape IntelliSense

Whenever you want to call IntelliSense from the Expression Shape editor, you can do so by just hitting the keys CTRL + SPACE. You will see the different namespaces, classes and objects (such as local variables and messages) available from the scope of your Expression Shape.

Note that this shortcut key combination actually comes from the Visual Studio .Net IDE. Thus, it is available for any “traditional” .Net project types (C#, VB.NET, Windows form, Web App…)

HTTP Adapter and Apache Keep-Alive issue

Problem.

If you notice a high rate of suspended messages due to communication failures between your BizTalk Server and an HTTP server, you should verify if the HTTP Web server you are accessing is Apache, Resin or another similar server of the UNIX / LINUX / Java family. Note that this could apply to other web servers as well, these are just examples I know of.

BizTalk Server always sends HTTP request with the HTTP header setting Connection: Keep-Alive. Moreover, BizTalk expects that the foreign HTTP server obeys to the header setting and does not check the Connection header setting received in the HTTP response.
To be more precise, the problem is double:

• Apache is not obeying to the Connection HTTP header setting and always closes the HTTP connection after every request (as in an HTTP 1.0 fashion). The HTTP/1.1 protocol allows this even if it is not the prefered behaviour.
• BizTalk Server does not react accordingly to the Connection header that is returned back in the HTTP response. This is wrong, following the HTTP/1.1 protocol definition, the client should always check the Connection header returned.

So, on one side there is a Apache closing connections for every HTTP request and on the other side BizTalk is expecting connections to be kept open between requests.

Actually, the source of the problem is not that the Web Server is Apache or not but related to how the Web Server is configured and how it behaves with the connection. Nevertheless, in my experience, this kind of problem only happened with Apache. But I also ever encountered 1 Apache server which kept the HTTP connection open between requests and so no fix was required for that case as no communication problem arose.

For this reason, if you have communication problems between BizTalk and a foreign web server, you should first check if the web server is explicitly closing the HTTP connection after every request.

There is a Microsoft KB that explains the issue and also how to fix it.


Identification of the problem.

As mentioned in the KB, it is important to make sure that your problem is exactly what the KB refers to, so, I will explain how I diagnosed it on my BizTalk Server.

Looking in the BizTalk Administration Console, I saw an abnormal amount of suspended service instances, most of them being of the type “Message”. I also noticed that all the suspended messages belonged to only a subset of our BizTalk applications.
There was clearly something wrong and by checking the Windows Event Viewer, I saw that some BizTalk send ports had an unusual failure rate at the communication level. This explained why so many messages were suspended as messages failing to be sent through a port will be suspended.
The Windows Event Viewer showed messages such as:

A message sent to adapter "HTTP" on send port "XXX" with URI "http://www.zzz.com/Service" is suspended.
Error details: Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.

And

A message sent to adapter "HTTP" on send port "XXX" with URI "http://www.zzz.com/Service" is suspended.
Error details: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

After scratching my head on this issue for a while, I found out that all failing messages where those sent to a port using an HTTP adapter configured with an URI pointing to an Apache server. Other ports using the HTTP adapter but configured to access an IIS server were working fine!

I then used a network sniffer to see what was going on exactly and I saw something inconsistent in the HTTP headers:
The header of the HTTP request contained:
Connection: Keep-Alive
But the header of the HTTP response contained:
Connection: close
server: IBM_HTTP_Server/6.0.2.3 Apache/2.0.47

So, even if the HTTP request specifies “Connection: Keep-Alive”, the Apache Server still close the connection and replies with a “Connection: close” in the header of the HTTP response. For reference regarding the Connection HTTP header, see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10


Solution.

As it is not possible to change the Connection: Keep-Alive header setting in the HTTP adapter shipped with BizTalk Server 2006, I googled a bit and found out the KB 924638 I mentioned earlier in this article which provides 1 solution and 1 workaround for the problem.

The hotfix mentioned in the KB contains a library that makes it possible to modify the Keep-Alive configuration for the HTTP connection. However, as there is no option to set the header setting from the BizTalk Administration Console, it is required to create a custom pipeline which writes a KeepAlive property in the context of the message going through the pipeline. Later on, the HTTP adapter will read the KeepAlive message context property value and create the HTTP connection accordingly.

You can find here a zip file containing 2 Visual Studio projects, one for the Custom Pipeline Component and another one for the Custom Pipeline. In this custom pipeline, the KeepAlive property is not hard-coded and so its value can be set either from the BizTalk Administration Console at run-time or from Visual Studio at design-time.

To summarize, there are 3 steps to apply the solution:

• Call Microsoft Support so that they email you the hotfix containing an executable which updates the Microsoft.BizTalk.HttpTransport.dll (as the hotfix is not directly available to download from the KB).
• Create a custom pipeline which has a property that permits the user to specify the Keep-Alive setting.
• Use the custom pipeline in the send ports that are pointing to web servers explicitly closing connections, such as some Apache web server.

Functoid and BizTalk Application Versioning Problem

1. Problem:

I encountered a problem difficult to diagnose related to deploying a BizTalk Server 2006 application and a functoid that have been compiled together but then deployed with different versions.
For example, let’s say you have developed and compiled a BizTalk application “A” version 1 using a functoid “F” version 1. Later on, you change some of the code inside the functoid and so you have a new version of the functoid, let’s call it functoid “F” version 2.
Note that by version 1 and 2, I do not mean the assembly version number; it is just a nomenclature I use to differentiate the versions. In my case, the assembly’s version number is fixed.
I often deploy new versions of functoids without having to recompile neither redeploy the BizTalk application but this time, the following error message appeared:

Microsoft.XLANGs.Core.XTransformationFailureException: Error encountered while executing the transform XXXX. Error:Unable to create the transform.. ---> System.ArgumentNullException: Value cannot be null.
Parameter name: extension
at System.Xml.Xsl.XsltArgumentList.AddExtensionObject(String namespaceUri, Object extension)
at Microsoft.XLANGs.BaseTypes.TransformBase.get_TransformArgs()
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData..ctor(Type transformBaseType)
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData._creator(Type t)
at Microsoft.XLANGs.RuntimeTypes.MetadataCache._slowFor(Type t)
at Microsoft.XLANGs.RuntimeTypes.MetadataCache.For(Type t)
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData.For(Type t)
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)
--- End of inner exception stack trace ---
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)
at Tourico.Tourico_SmartSearch.segment2(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)


2. Solution:

The message was not recorded in the Windows Event Log but as I catch and log exceptions in an exception handler; I could see the exception in my log.
As the message is rather vague, I spent quite a lot of time checking the maps and schemas used in the orchestration but found no clue.
I finally noticed that a functoid’s code had been changed and once I recompiled and re-deployed the BizTalk Application, everything worked fine!

I am not sure of the exact reason as normally you don’t need to redeploy the BizTalk application after having updated and GACed a functoid.
Anyway, if one day you encounter an error message of the same flavor, recompiling and redeploying the application might just work fine. Maybe this hint can help someone in the future :)


3. Note about exception handler in BizTalk Server 2006.

For the people who do not know, you just need to use a scope shape and its exception handler to have the equivalent of a try-catch block in a BizTalk orchestration. That gives you the opportunity to take action and/or log errors when exceptions are thrown from the orchestration.

To create an exception handler, drop a scope shape into your orchestration, right click on it and select “New Exception Handler”. Note that only scopes that are non-transactional or long running transactional can have an exception handler.
Here is how it looks like:
Everything in the first square (Scope_1) will be the “try” part and everything in the second square (CatchException_1) will be the “catch” part.

Biztalk 2006 multiserver installation

This article explains how to install BizTalk Server 2006 on multiple servers for a configuration with 1 SQL Server and 1 BizTalk Server.

Doing a multiserver BizTalk installation should be done once for practice before doing it on the production servers so that all the specificities to a multiserver install are well understood.
I will here share my experience in a practice multiserver BizTalk installation done on 2 Virtual Machines.

Simplified BizTalk Server Installation scenario.

For a first multiserver installation, I will keep a simplified scenario with only 2 servers and neither BAS nor BAM features installed. Only the following components will be installed:
- Enterprise Single Sign-On (SSO).
- BizTalk Group.
- BizTalk Runtime.
- MSMQT.
- Business Rule Engine.

There will be 2 virtual servers:
- 1 Virtual Machine to host SQL Server and act as a Domain Controller
- 1 Virtual Machine to host BizTalk Server.

This is the most basic multi-server install possible. It will nevertheless help you to understand how a multi-server BizTalk installation works.
For more complex installation scenarios with BAM, BAS and/or clustered servers, Microsoft provides a complete installation guide document, “BizTalk Server 2006 Installation Guide - Multiserver”. See in the reference section of this article for a link to the documentation.

Note that to follow this article as a lab, you will need the following software:
- Microsoft Virtual PC 2007 (Virtual PC is now free and you can download it here)
- Windows Server 2003
- SQL Server 2005
- BizTalk Server 2006

The need for a Domain Controller.

A very important difference between a single server and a multi-server installation is that the multi-server configuration requires you to use domain users and groups to run the various BizTalk services making having a domain controller a necessity.
On the other hand, a single server configuration can run with local windows groups and users.
To be more precise, these domain accounts and groups are used for the security configuration of the BizTalk Server databases. Indeed, the user account which runs the BizTalk server service must have access to the SQL Server. As SQL Server is installed on a separate machine, the use of a domain user account is therefore a necessity so that the account can have access rights on both the BizTalk machine and the SQL Server machine.

The important point to remember is that when you plan to install a multi-server configuration of BizTalk in your production environment, you will have to check with your hosting company to have access to a domain controller or to have them create all the necessary domain users and groups.

Create Domain Groups and Users.

For a single server installation, the setup procedure is able to create the Windows Groups and Users necessary for BizTalk as they are created on the local machine.
On a multi server installation, BizTalk Windows Groups and Users must be created manually on the Domain Controller. The setup procedure is not able to create the Windows Groups and Users on a Domain Controller.

BizTalk Installation, Configuration and Applications Deployment considerations.

To be able to install and configure BizTalk Server 2006, you have to log on the server using a Domain User who has Administrator rights on both the SQL Server and the BizTalk Server. Moreover, that domain user must also be part of the BizTalk Server Administrators group and the SSO Administrators group.
The user must also have the sysadmin role on the SQL Server.

I found out something that is, as far as I know, NOT mentionned in the BizTalk documentation: the user installing BizTalk Server must also have the Domain Administrator role. Technically, this privilege does not have to be granted when installing BizTalk Server but only when configuring it. It is because when the BizTalk Server Configuration tool runs, the tool must be able to check if the Windows accounts assigned to the various BizTalk services belong to the Windows groups set for these services. Only a user being domain administrator has the right to check other users properties.

After BizTalk Server is configured and installed, the user does not have to be part of the Domain Administrators group anymore. Moreover, its privileges on the SQL Server can be lowered to dbo instead of administrator. That way the user can be used to install BizTalk Applications without having unnecessary privileges.
FYI, installing BizTalk application creates tables, and executes SP on the BizTalk DBs.

To simplify things I advise to create a “BTSAdmin” domain user who has these rights. Only the person who will install, configure and manage BizTalk applications should have that user login information.

The BizTalk Server 2006 installation guide provides a list of all the necessary Groups and User that need to be created. Microsoft also provides a best practice guide on how to implement the Windows Groups and Users for BizTalk Server 2006.

Microsoft Distributed Transaction Coordinator (MS DTC) considerations.

Network DTC access and Network COM+ access must but enabled for all BizTalk and SQL servers. It is turned off by default on Windows Server 2003.

SQL Server Considerations.

SQL Server client tools must be installed on all BizTalk servers. The client Tools installed must be of the same version as the SQL Server installed.
SQL server must be started and running when running the BizTalk Server Configuration tool.


1. Creating the Virtual Servers.

To install the Virtual Servers, you will need Microsoft Virtual PC 2007 and Windows Server 2003.

In this step, we will create 2 Virtual Machines, one named SQLServer and another one named BizTalkServer. Windows Server 2003 will be the OS installed on both of them.
The machine named SQLServer will run SQL Server and also act as a Domain Controller while BizTalkServer will host BizTalk Server.

As installing Windows Server 2003 on a virtual machine is particularly slow, please refer to a previous post that explains how to install and clone virtual servers efficiently.

Once the 2 virtual machines are ready, set their networking setting to “Local only”. This option gives you networking support between virtual machines only. For a description of the different network settings available for Virtual PC, check the following link: http://support.microsoft.com/kb/833134


2. Installing the Domain Controller and creating Windows User and Groups.

2.1. Complete the setup of the SQLServer Virtual Machine.

1. Rename the VM. If you created the SQLServer Virtual Machine by using a base virtual machine and “sysprepped” it, you will need to rename it first. To do so, go to Control Panel > System > Computer Name and click “Change”. Input “SQLServer” in the machine name field. When prompted, do not restart the machine yet.
2. Set the Virtual Machine IP address. Set the SQLServer VM to have a static IP address of 192.168.0.1 - The 192.168.x.x address range is a typical IP range for private networks.
To modify the IP address of the VM, go to Control panel -> Network Connections -> Local Area Connection -> Properties -> TCP/IP -> Properties and use 192.168.0.1 for the IP address as well as the DNS server. In the subnet mask field type in 255.255.255.0 and leave the default gateway blank.

You must now reboot the SQLServer virtual machine.

2.2. Installing the Domain Controller.

Start the SQLServer virtual machine as it is the machine chosen to act as a Domain Controller (DC).
For this step, have the Windows Server 2003 installation disk at hand as it might be needed.

1. Make sure that you restarted the server after it has been renamed. This is because Active Directory can’t be installed after you changed the computer name without rebooting first.
2. Run “Manage Your Server”, and click “Add or Remove a Role” (next to “Adding Roles to Your Server” area).
3. Select the radio button “Typical configuration for a first server” and click “Next”.
4. Type in “biztalk.local” for your Active Directory domain name and click “Next”.
5. In the NetBIOS Name screen, accept the default setting and click “Next”.
6. In the Forwarding DNS Queries screen, select “No, do not forward queries” and click “Next”.
7. Click “Next” again and “OK” in the pop up window. If prompted to insert Windows Server 2003 disk, click on “Use Physical Drive” in the “CD” menu of the windows containing the Virtual Machine. You might additionally have to point to some files in the \I386 folder located on the Windows Server installation disk.
8. When the installation is almost complete, the VM will restart and finish the DC setup. Once the virtual machine has rebooted itself, a “Server Configuration Progress” window will open; click “Next” and “Finish”. The domain controller installation is now completed.

Note: Once your server is promoted to be a Domain Controller, the local administrator is promoted to become the domain administrator.
Moreover, it is not possible to log on the local machine anymore; you can only log on the domain. The concept of local Users and Groups doesn’t exist anymore and if you try to run lusrmgr.msc, a message will be displayed saying that is not possible to manage local groups and users on a Domain Controller. Only domain groups and users can be created and managed.

2.3. Create BizTalk Domain Users and Groups.

Start the Domain Controller, the SQLServer VM.
As we don’t install all the features of BizTalk Server, we create only a subset of the Windows Users and Groups defined for BizTalk Server 2006. This subset of Groups and Users is tailored for the features installed in this article.

1. Run “Manage Your Server” and click on “Manage users and computers in Active Directory”, located next to the “Domain controller (Active Directory)” area. This will open the Active Directory Users and Computers MMC (Microsoft Management Console). Alternatively, you can open it by going to: Control Panel > Administrative Tools > Active Directory Users and Computers.
2. Expand biztalk.local
3. Create a BizTalk Organizational Unit. To keep things tidy, we place the BizTalk Users and Groups in an Organizational Unit (OU). To do so, right click on “biztalk.local” and click New -> Organizational Unit. For the Organizational Unit name, enter “Biztalk”.
4. Create the Windows Groups. These groups will be used for the security configuration of the BizTalk Server databases. Right click on the Organizational Unit “BizTalk” and click New -> Group. For each group created, enter the group name specified in the table bellow, keep the default settings and click “OK”.

Group Name

SSO Administrators

SSO Affiliate Administrators

BizTalk Server Administrators

BizTalk Server Operators

BizTalk Application Users

BizTalk Isolated Host Users

There are 6 Groups created in total.
5. Create the BizTalk Windows Service Accounts (Windows Users). Windows Users are required for the various BizTalk services. You might want to set all the users to use the same password so that managing them is easier. Right click on the Organizational Unit “BizTalk” and click New -> User. For each user created, enter the full name and the user logon name specified in the following table (under the “Full Name” and “User logon name” columns) and click “Next”. In the following screen, enter the user’s password, uncheck “User must change password at next logon”, check “User cannot change password” and “Password never expires”. Finally, click “Next” and “Finish”. Repeat the procedure for every Windows User.

Full Name	User logon name
Enterprise Single Sign-On Service	SSOService
BizTalk Administrator	BTSAdmin
BizTalk Host Instance Account	BTSAppHost
BizTalk Isolated Host Instance Account	BTSIsolatedHost
Business Rule Engine Update Service Account	ReuService

6. Add the Windows Service Accounts to their respective Groups.

Windows Group	Windows User
Server Administrators	biztalk\BTSAdmin
SSO Administrators	biztalk\BTSAdmin and biztalk\SSOService
BizTalk Application Users	biztalk\BTSAppHost
BizTalk Isolated Host Users	biztalk\BTSIsolatedHost

7. Close the Active Directory Users and Computers MMC.

Remember that the Windows Users will be used to run the different BizTalk services and the Windows Groups are used to manage security and access rights to the SQL Server.

In case you would install all the BizTalk server features, you can find a complete list of Windows Users and Groups needed for BizTalk Server in the BizTalk Server 2006 installation guide. You should also read the Microsoft guideline to implement Windows Groups and Users for BizTalk Server 2006.

2.4. Chose the Domain User performing the BizTalk multiserver installation.

If you continue the installation procedure logged on the virtual servers with the Domain Administrator, you don’t need to do this step. Nevertheless, in real environments, you will most likely not want or have the possibility to use the Domain Administrator to install BizTalk Server. In that case, you will have to create a domain user who is Administrator on both BizTalk and SQL Server machines and also member of the “BizTalk Server Administrators” and “SSO Administrators” groups.

In this practice installation, we will choose the BTSAdmin domain user that we have just created to execute the BizTalk Server 2006 multi-server installation. As we added BTSAdmin in the “BizTalk Server Administrators” and “SSO Administrators” groups already, the remaining task is to give the user administrator privileges on both the SQLServer and the BizTalkServer VMs.

2.5. Configure the SQLServer VM Administrator and SQL Server sysadmin Role.

To give BTSAdmin administrator privileges of the SQLServer VM:
1. Run “Manage Your Server” and click on “Manage users and computers in Active Directory”, next to the “Domain controller (Active Directory)” zone.
2. Under the “Builtin” folder, add “biztalk\BTSAdmin” to the “Administrators” group. Note that in our lab this will unintentionally make the BTSAdmin user a domain administrator, but in a normal scenario, SQL Server would not be a Domain Controller and so BTSAdmin would just be administrator of the local machine.

As by default the Windows Builtin\Administrators group has the sysadmin SQL role on the SQL Server, the BTSAdmin user will also have the sysadmin role as BTSAdmin is now part of the Administrators group. Once SQL Server is installed, you will be able to check that by opening the SQL Server Management Console, go to “Security\Server Roles” and double click on the “sysadmin” role. The pop up window will show all the windows and SQL logins having the sysadmin role.


3. Installing SQL Server.

3.1. Install SQL Server.

In this step, we will install SQL Server 2005 on the virtual machine that will host the BizTalk databases.

Only a subset of the SQL Server 2005 components are needed for the BizTalk features we have chosen to install. These are: “SQL Server Database Services” and “Workstation components, Books Online and Development tools”.
If you plan to install the BAM component of BizTalk Server, you will have to additionally install the following SQL Server 2005 components: “Analysis Services”, “Notification Services” and “Integration Services”.

The SQL Server service should use the Local System account as the Service Account, and you should configure the SQL Server Agent to start at the end of the setup.

SQL Server 2005 installation procedure:
1. Start the Virtual Machine SQLServer. Log on using the domain user you have chosen to use for the BizTalk multiserver installation (see paragraph 2.4).
2. Start the setup of SQL Server from its installation disk.
3. On the SQL Server Installation welcome screen, click “Server components, tools, Books Online, and samples”.
4. Accept the license terms and conditions and click “Next”.
5. On the Installing Prerequisites screen, click “Install”. Note that all the necessary prerequisites, such as the .Net Framework 2.0, are present on the installation disk.
6. Once the prerequisites are installed, click “Next”.
7. On the Welcome to the Microsoft SQL Server Installation wizard, click “Next”.
8. On the System Configuration Check, click “Next”.
9. Enter the registration information on the Registration screen, click “Next”.
10. On the Components to Install screen, chose the 2 components “SQL Server Database Services” and “Workstation components, Books Online and Development tools”, click “Next”.
11. Leave the “default instance” radio button selected on the Instance Name screen, click “Next”.
12. On the Service Account screen, make sure that the check box “Customize for each service account” is cleared; select the radio button “Use the built-in System account” with “Local System” selected in the dropdown list. Note that you could also use a Windows User account instead and if you do so, enter a local account or domain account and its password. Lastly, tick the check box “SQL Server Agent” in the “Start Services” section so that the SQL Server Agent starts once the setup is completed. Click “Next”.
13. In the Authentication mode select “Windows Authentication Mode”. Note that Mixed Mode can also be used but it is potentially less secure and not advised by Microsoft. Click “Next”.
14. On the Collation Settings screen leave the default and click “Next”.
15. Click “Next” again and then “Install”.

3.2. Configuring the SQL Server Virtual Machine.

Once SQL Server is installed, you need to configure it.

3.2.1 Configure SQL Server for Remote Connections.

In order for the BizTalk servers to connect to SQL Server, remote connections need to be enabled.
To do so you need to:
1. Run SQL Server Surface Area Configuration, found in Programs -> Microsoft SQL Server 2005 -> Configuration Tools
2. Once the tool opens, click on Surface Area Configuration for Services and Connections.
3. Locate “Remote connection” under the Database Engine tree and enable local and remote connections for both protocols by selecting “Local and remote connections” and “Using both TCP/IP and named pipes” radio buttons.

3.2.2. Configure Microsoft Distributed Transaction Coordinator (MS DTC).

In order for BizTalk to run against its databases located on a remote SQL server, you will need to turn on MS DTC options (both on the SQL Server and BizTalk Server).
Follow the next steps on the SQLServer VM:
1. Open the Control Panel and open “Add or Remove Programs”. Once open, click “Add/Remove Windows Components”.
2. Once the Windows Components Wizard open, select “Application Server” and click on de “Details” button.
3. Select the check boxes in front of “Enable network COM+ access” and “Enable network DTC access”. Click “OK”
4. You are now back to the Windows Components Wizard window; click “Next” and then “Finish”.
5. Restart the server.

If your SQL Server is installed on the Domain Controller like in this practice installation, enabling Network DTC Access will not work as there is a bug between DTC and the Domain Controller service. I posted a previous article explaining the problem and how to solve it, see: Enabling network DTC access fails on a Domain Controller server.

3.3 Install and Configure Enterprise Single Sign-On Master Secret Server.

I chose to install the Enterprise Single Sign-On Master Secret Server on the SQL Server virtual machine so that I could try it out.
Nevertheless, it is more common to install the Master Secret Server on the BizTalk Server machine when there is only 1 BizTalk machine.
In case you have a cluster of several BizTalk Server machines, you can chose to either install the Master Secret Server on a separate machine (such as in this example) or install it on one of the BizTalk Server.
The points to remember are:
- There can be only 1 machine being the Master Secret Server. It can either be one of the machines hosting BizTalk Server or any other.
- All machines running BizTalk and the machine being the Master Secret Server will have the Enterprise Single Sign On Windows Service running.

See the Microsoft documentation on installing BizTalk Server 2006 for more details on how to cluster SSO.

1. Start up the BizTalk Server 2006 Installation.
2. On the Microsoft BizTalk Server 2006 Installation Wizard page, click “Install Microsoft BizTalk Server 2006 on this computer”.
3. On the Customer Information page, type your user name and organization, and then click “Next”.
4. Accept the License Agreement and click “Next”.
5. On the Component Installation page, select ONLY “ESSO Administration Module” and “ESSO Master Secret Server”, found under “Additional Software”. Unselect all other components.
6. After the installation, make sure that the checkbox “Launch BizTalk Server Configuration” is selected and click on “Finish”. The BizTalk Server Configuration will start.
7. In the BizTalk Configuration, select the “Custom Configuration” radio button. In the “Service Credential” zone, type in “BIZTALK\SsoService” and its password. It is the domain account that will run the SSO Windows Service. Click “Configure”.
8. In the summary window, click “Next”.
9. On the final window, click “Finish”
10. Use Event Viewer to verify the ENTSSO service has started successfully.


4. Installing BizTalk Server.

In this step, we will install the BizTalk prerequisites, BizTalk Server 2006 and operate the necessary configuration.
Before starting the BizTalk virtual machine, make sure that its network configuration setting is set to “local only”.


4.1. Complete the setup of the BizTalkServer VM.

1. Start the virtual machine BizTalkServer.

2. Change machine name and join the domain. If you created the BizTalkServer Virtual Machine by using a base virtual machine and “sysprepped” it, you will have to rename the VM first. To do so, go to Control Panel -> System -> Computer Name and click “Change”. Change the computer name to “BizTalkServer”.
In the same window, join the domain by selecting the “Domain” radio button and type “biztalk.local” for the Domain name. Click “OK”. You will be prompted to enter the Domain Administrator user name and password.
Before restarting the Virtual Machine you should execute the next step.

3. Set static IP address. To modify the IP address of the VM, go to Control panel -> Network Connections -> Local Area Connection -> Properties -> TCP/IP -> Properties and use 192.168.0.2 for the IP address, 255.255.255.0 for the subnet mask, leave the default gateway blank and set the DNS server IP to 192.168.0.1

You can now reboot the BizTalkServer virtual machine. Note that for the BizTalkServer VM to boot and run properly as being part of the Domain, the virtual machine acting as the Domain Controller will have to be running as well. This means that from now on, the SQLServer VM must already be running when you start the BizTalkServer VM.


4.2. Configure BizTalkServer VM Administrator.

From now on, you will always log on the BizTalkServer VM using a domain account so that you are logged on the domain.

If you chose to execute the installation of Biztalk Server 2006 for a multi-server environment using the Domain Administrator, you don’t need to do this step and you will log on the BizTalkServer VM using the domain administrator account to you install BizTalk Server. Otherwise, continue.
See paragraph 2.4 for more details about choosing a domain account to install BizTalk Server 2006.

Once you have rebooted the BizTalkServer VM, log on the machine using the Domain Administrator account, so you have to log on the domain, not the local machine which is the default choice.

We have previously chosen to give the domain user BTSAdmin administrator privileges on both the SQLServer and the BizTalkServer VMs so that it can execute the BizTalk setup procedure.

To add BTSAdmin user as an Administrator of the BizTalkServer VM;
1. Open “Computer Management” found under Control Panel -> Administrative Tools.
2. Under the “Builtin” folder, add “biztalk\BTSAdmin” to the “Administrators” group.

You can know log off or reboot the BizTalkServer VM and log on again using the BTSAdmin domain user which is now administrator of the BizTalkServer machine.

4.3. Installing prerequisites.

4.3.1 Install IIS 6.0.

BizTalk server requires IIS for the HTTP Adapter, SOAP Adapter, Windows SharePoint Services Adapter, SSL encryption, Business Activity Services (BAS), Human Workflow Services (HWS).

In this step you might need access to the Windows Server 2003 installation disk.

IIS 6.0 installation procedure:
1. Click Start, point to Control Panel, and then click “Add or Remove Programs”.
2. In the Add or Remove Programs dialog box, click “Add/Remove Windows Components”.
3. In the Windows Components Wizard, select “Application Server” and then click “Details”.
4. Select “ASP.NET” and make sure that “Internet Information Services (IIS)”and “Enable network COM+ access” are selected as well. Click “OK”, and then click “Next”.
5. On the Completing the Windows Components Wizard page, click “Finish”.

4.3.2 Install the .Net framework 2.0 or Visual Studio 2005.

If the machine is used for the BizTalk runtime-only (such as on a production environment), you should install the .Net framework 2.0. You can download a redistributable version of .Net 2.0 framework here.
If the machine is used for the BizTalk runtime and/or development, Visual Studio 2005 or the .Net Framework 2.0 SDK should be installed instead.

4.3.3. Install SQL Server 2005 Client Tools.

1. Insert the SQL Server 2005 DVD in the DVD-ROM drive and browse to the \Tools folder and double click "setup.exe".
2. Accept the licensing agreement on the End User License Agreement page and click “Next”.
3. On the Installing Prerequisites page, click “Install”. Once the prerequisites are installed, click “Next”.
4. On the Welcome to the Microsoft SQL Server Installation Wizard page, click “Next”.
5. On the System Configuration Check page, ensure that there are no errors before you continue. Note that as we are running on a virtual machine there will be a warning for the “Minimal Hardware Requirement”, ignore it and click “Next”.
6. On the Registration Information page, click “Next”.
7. On the Feature Selection page, under “Client Components”, select “Will be installed on local hard drive” for the following Components: “Connectivity Components”, “Management Tools”, “SQLXML Client Features” and “Legacy Components”. Click “Next”.
8. Once the components are installed, click “Next” and then “Install”.
9. Once the setup is finished, click “Next” and then “Finish”.
10. Restart the virtual machine.

4.3.4. Configure Microsoft Distributed Transaction Coordinator (MS DTC).

To be able to install BizTalk server (run the BizTalk Configuration tool, to be more precise), install BizTalk applications and run BizTalk applications, network DTC access must be enabled.

Follow the next steps to do so:
1. Open the Control Panel and open “Add or Remove Programs”. Once open, click “Add/Remove Windows Components”.
2. Once the Windows Components Wizard open, select “Application Server” and click on the “Details” button.
3. Select the check box in front of “Enable network DTC access” and make sure that “Enable network COM+ access” is also selected. Click “OK”
4. You are now back to the Windows Components Wizard window; click “Next” and then “Finish”.
5. Restart the VM.


4.4. Installing BizTalk Server 2006.

4.4.1. Considerations:

Before you install BizTalk Server 2006, consider the following:
- If your computer name is longer than 15 characters, BizTalk Server Configuration will not work.
- The account you are logged on as must be part of the local administrators group and have DBA rights on SQL Server. After configuration is complete, you can lower the privileges to DBO.
- When installing BizTalk Server, there will be prerequisites components to install such as ADOMD.NET, SQLXML 3.0 SP3... You can either let the BizTalk Installation Wizard download them and install them for you or you can pre-download a cab file that contains all the prerequisites. You can see a list of all the prerequisite components required by BizTalk server here.
As we don’t have access to the internet from the Virtual Machine in this practice installation (we set the VM Network settings to "Local only"), we first need to download the BizTalk Server 2006 redistributable prerequisites cab file for Windows Server 2003 (32-bit) (BtsRedistW2k3EN32.cab) and then copy it on the virtual machine hard disk.

4.4.2 Install BizTalk Server 2006.

1. Start the BizTalkServer Virtual Machine and log on using the domain user you have chosen to use for the BizTalk multiserver installation (see paragraph 2.4).
2. Start up the BizTalk Server 2006 Installation; Double click on “Setup.exe” located on the root of the BizTalk Server 2006 installation disk.
3. On the Microsoft BizTalk Server 2006 Installation Wizard page, click “Install Microsoft BizTalk Server 2006 on this computer”.
4. On the Customer Information page, type your user name and organization, and then click “Next”.
5. Accept the License Agreement and click “Next”.
6. On the Component Installation page, select the following components: “Documentation”, “Server Runtime (without Base EDI Adapter)”, “Administration Tools” and “Business Rules Components”. Click “Next”.
7. On the Redistributable Prerequisites page, select “Automatically install the redistributable prerequisites from a CAB file” and specify the cab file location. This is the cab file that we pre-downloaded in paragraph 4.4.1. Click “Next”.
8. On the Summary page, verify that the components you selected to install are correct. Click “Install”.
9. On the Installation Completed page, unselect the “Launch BizTalk Server Configuration” check box, and then click “Finish”.
10. You can eventually stop your virtual machine and commit your change if you are using undo disk so that you start a new session when you are running the BizTalk Server Configuration tool.

4.5. Check that MS DTC network access is enabled on all servers participating in the BizTalk multiserver installation.

The last step to install BizTalk Server 2006 is to run the Configuration Tool. For the BizTalk Server Configuration Tool to run, all SQL Server and BizTalk Server machines must have Network DTC access and Network COM+ access enabled. So, before continuing and configure BizTalk, verify that this is the case on all the machines participating in the BizTalk multiserver installation.
In paragraph 3.2.2, I highlighted that there is a bug in turning on Network DTC access on a machine which is a Domain Controller so, double checking that Network DTC access is enabled on all machines can save you from a lot of trouble.

4.6. Configure BizTalk Server and other components.

The BizTalk configuration is the most likely point of failure of the BizTalk multiserver installation. If you use Virtual Machine with undo disks, you should commit your changes to the VM’s virtual hard disk before running the BizTalk Server Configuration Tool so that you have a fresh session when starting the configuration process. In that case, if the configuration fails, you will be able to cancel the change and go back to the state the Virtual Machine was before starting the BizTalk configuration. This means that the only thing you would have to re-do is to run the BizTalk Configuration again (after fixing the cause of the problem) but all previous installation tasks will be preserved.

1. Starts the BizTalk Server Configuration from the Microsoft BizTalk Server 2006 menu (Programs -> Microsoft BizTalk Server 2006).
2. Select the “Custom configuration” radio button. “Basic configuration” can be used for single server installation only. For the “Database server name”, type in the name of the machine hosting SQL Server: "SQLServer". For the “User Name” type in "BIZTALK\BTSAdmin" and its password. Click “Configure”.
3. You are now on the Overview Panel of the BizTalk Configuration tool. You will now configure all the BizTalk components per section.
4. Enterprise SSO. Click on Enterprise SSO; tick the checkbox “Enable Enterprise Single Sign-On on this computer”. Select the radio Button “Join an existing SSO Sytem”. For the Database configuration, make sure the Server Name is “SQLServer” and the DB Name is “SSODB”. Set the account name to “BIZTALK\SsoService” for running the SSO Windows Service.
5. Enterprise SSO Secret Backup. No change as the Master Secret Server is the SQLServer machine, not the BizTalkServer machine. See paragraph 3.3 in which we installed the Enterprise SSO Master Secret Server. Once BizTalk is fully configured, you will be able to verify that by running the SSO Administration snap-in and check the value of "SSO Secret Server" field under the "system" sub-tree.
6. Group. Tick the checkbox “Enable BizTalk Server Group on this computer”. Select the radio button “Create a new BizTalk Group”. Under “Data Stores”, check that the Database Server Name is set to “SQLServer” for the 3 BizTalk databases that will be created. Under “BizTalk Administrative Roles”, change the Windows Group to use “BIZTALK\BizTalk Server Administrators” and “BIZTALK\BizTalk Server Operators”. Be careful that the default values are Windows Groups with the same name but local to the BizTalk machine (not the Groups defined in the Domain).
7. BizTalk Runtime. Tick the checkbox “Register the BizTalk Server runtime components”. Make sure that both checkboxes “Create BizTalk In-Process Host and Instance” and “Create BizTalk Isolated Host and Instance” are checked. There is no need to tick the “Trusted” checkboxes. Select “Trusted” only if you want to pass the credentials (SSID and/or Party ID) of the sender when submitting messages to the MessageBox database. This is equivalent to creating a trust relationship between the servers.
Under “Windows Service”, Change the account names to “BIZTALK\BTSAppHost” for the BizTalk Host Instance Account and “BIZTALK\BTSIsolatedHost” for the BizTalk Isolated Host Instance Account.
Under “Windows Group”, change the Windows Group to “BIZTALK\BizTalk Application Users” and “BIZTALK\BizTalk Isolated Host Users”. Be careful that the default values are Windows Groups with the same name but local to the BizTalk machine.
8. MSMQT. No changes.
9. Business Rule Engine. Tick the checkbox “Enable Business Rules Engine on this computer”. Make sure that the Server Name is “SQLServer” and the Database Name is “BizTalkRuleEngineDB”.
Under “Windows Service”, set the Account name to “BIZTALK\ReuService”.
10. HWS Runtime. No changes.
11. BAM Tools. No changes.
12. BAM Alerts. No changes.
13. The configuration is now finished. Click on “Apply configuration”. Review the configuration settings and click “Next”. This is the most likely point of failure in this lab, hence the usefulness of undo disks. If things go bad, look at the problem carefully (you can find clues from the log file generated by the BizTalk Server Configuration tool) and check that you have completed every step of the setup correctly on each server.

4.7. Verify Configuration.

You can check if the configuration went well by having a look at the Windows Event Log, there should be a lot of Information entries and no errors or warning related to BizTalk.

You should also start the BizTalk Server administration console and verify the BizTalk Server host instance is started (found under BizTalk Group\Platform Settings\ Host Instances). Try stopping and starting the host instance.

Finally, deploy and test a simple orchestration, such as the HelloWorld orchestration found in the BizTalk SDK samples.

5. References.

MS documentation - BizTalk Server 2006 Installation and Upgrade Guides.

Simplified BizTalk Server 2006 Installation.

Guidelines for Implementing Active Directory Permissions on Multi Server BizTalk Installations.

BizTalk Server Pipeline Technology Explained

In this post I will introduce the pipeline technology in BizTalk Server.

1. What is a BizTalk Server Pipeline?

BizTalk server being an integration platform it is most likely that it will have to communicate with systems using various document formats. Because the BizTalk Server 2006 engine works with XML documents internally, it must provide a way to convert other formats to and from XML. Other services may also be required when converting formats, such as authentication of the sender of a message, encryption or decryption, property promotion and so on.
To handle these tasks in a modular and customizable way, a pipeline is constructed from some number of stages; each stage contains one or more .NET or COM (Component Object Model) components. Each component handles a particular part of message processing. It is because all these components are run in sequence that the whole process is called a pipeline.
A stage is a container of components, each stage is itself a component with metadata. Stages have no execution code, as opposed to pipeline components, which do have execution code.

The BizTalk Server 2006 engine provides several standard components that address the most common cases. If these aren’t sufficient, developers can also create custom components for both receive and send pipelines.

To summarize, pipelines enable the developer to define a series of transformations that will be performed on a message as it is being received or sent.

Message processing workflow:


The message is passed from the adapter to the receive pipeline where it is transformed to XML. The message can then be used by orchestrations, or passed to a send pipeline, and then to a send adapter.

As seen in the picture above, there are 2 types of pipelines:
- Receive Pipeline, its purpose is to prepare a message for being processed by the server after being received by an adapter.
- Send Pipeline, its purpose being to prepare a message for sending to an adapter after being processed by the server.

Execution mode

Each pipeline stage can have its own Execution Mode setting, so different stages within a pipeline can have different execution modes.

When the Execution Mode property is set to All, all the components within the stage are run in the configured sequence. A run-time error occurs if any component of the stage encounters an error while processing a message. Use this mode when several components must be run to complete a logical task.

When the Execution Mode property is set to FirstMatch, only the first component that recognizes the message is run. If no components in the stage recognize the message, a run-time error results. Use this mode when the pipeline stage receives messages in several formats.

All the stages execution mode of the standard pipelines delivered with BizTalk Server 2006 are set to All, except for the Disassemble stage of the receive pipeline which is set to FirstMatch.



2. Receive Pipeline.

The receive pipeline is the pipeline executed by a receive port; it is executed after an adapter reads the message from a physical location through a particular protocol (FTP, HTTP, MSMQT …)
The receive pipeline takes the initial message, performs some transformations, and disassembles the raw data into zero, one, or multiple messages which are then processed by the BizTalk server engine.

Details of tasks executed by a Receive Pipeline:


As shown, there are 4 stages executed by a receive pipeline:

2.1 Decode Stage.
- This stage is used for components that decode or decrypt the message. Decoding is the process of transforming information from one format into another.
- This stage takes one message and produces one message.
- This stage can contain between zero and 255 components.
- All components in this stage are run.

2.2 Disassemble Stage.
- This stage is used for components that parse and disassemble the message.
- Disassembling is a process of breaking up a large interchange message into smaller messages by removing the Envelopes. It is also often called “debatching”
For example, instead of sending n messages of the same type sequentially, a system might send 1 large message containing n messages which are the actual purpose of the communication. The message containing the sub-messages is what is called the envelope.
For this feature to take place, the use of an Envelope Schema is necessary. The Envelope schema is a special type of schema that can be created within BizTalk. It defines the schema of the enveloping message.

- This stage creates a BizTalk Message Object and a Message Context Object.
- This stage promotes properties from the interchange message (envelope and individual messages) to the Message Context of each individual messages generated.

- The components within this stage probe the message to see if the format of the message is recognized. Based on the recognition of the format, one of the components disassembles the message.
- If this stage contains more than one component, only the first component that recognizes the message format is run. If none of the components within the stage recognize the message format, the message processing fails.
- This stage should include any custom components that implement special behavior to disassemble the message contents.
- This stage can contain between zero and 255 components. If there are no components in the stage, the message is passed through.
- This stage takes one message and can produce one or more messages.

2.3 Validate Stage.
- This stage is used for components that validate the message format - XML document validation against a XML schema (XSD).
A pipeline component processes only messages that conform to the schemas specified in that component.
- Components in this stage are used to validate the XML messages produced by the Disassemble stage. The XML is validated through the use of XML schemas defined in the component.
- This stage can contain between zero and 255 components.
- All components in this stage are run.
- This stage may be run more than once. This is because it runs once per message created by the Disassemble Stage. So if the disassemble stage produce 10 messages, it will run 10 times.

2.4 Resolve Party Stage.
- This stage is a placeholder for the Party Resolution Pipeline Component.
- This stage may be run more than once. It runs once per message created by the Disassemble stage.
- This stage can contain between zero and 255 components.
- All components in this stage are run.


3. Send Pipeline.

A send pipeline is responsible for processing documents before sending them to their final destinations. The send pipeline takes one message and produces one message to send.

Details of tasks executed by a Send Pipeline:


There are 3 stages executed by a send pipeline:

3.1 Pre-assemble Stage
- This stage is a placeholder for custom components that should perform some action on the message before the message is serialized.
- This stage is run once per message.
- This stage can contain between zero and 255 components.
- All components in this stage are run.

3.2 Assemble Stage
- Components in this stage are responsible for assembling or serializing the message and converting it to or from XML. It is the inverse operation of the disassemble stage in a receive pipeline.
- Assembles the message and prepares it to be transmitted by taking steps such as adding envelopes, move context properties to the message and other tasks complementary to the disassemble stage in a receive pipeline
- This stage accepts zero components or one component.
- All components in this stage are run.

3.2 Encode Stage
- This stage is used for components that encode or encrypt the message. Encoding is the process of transforming information from one format into another. The encoding stage is the inverse operation of the decoding stage in a receive pipeline.
- This stage is run once per message.
- This stage can contain between zero and 255 components.
- All components in this stage are executed.


4. Standard Pipelines and Pipeline Components shipped with BizTalk.

BizTalk is shipped with a series of existing pipeline components ready to use.
BizTalk is also shipped with 2 pairs of default pipelines, which are composed of standard pipeline components.

4.1 Standard Pipeline Components

4.1.1 Standard components provided for each stages of a receive pipeline:


Decode Stage: BizTalk Server 2006 provides one standard component for this stage, the MIME/SMIME Decoder. This component can handle messages and any attachments they contain in either MIME or Secure MIME (S/MIME) format. The component converts both types of messages into XML, and it can also decrypt S/MIME messages and verify their digital signatures.

Disassemble Stage: BizTalk Server 2006 provides three standard components for this stage.

1. The Flat File Disassembler component turns flat files into XML documents. These files can be positional, where each record has the same length and structure, or delimited, with a designated character used to separate records in the file. A typical example of such flat file is the CSV (Comma Separated Values) file format.

2. The XML Disassembler parses incoming messages that are already described using XML.
Main role of the XML disassemble component:
- Removes envelopes.
- Disassembles the interchange. The interchange is the envelope and the documents contained in it. Disassembling is the process of creating individual messages from the messages contained in an Envelope.
- Responsible for promoting properties from the interchange (the envelope) and the individual documents to the message object context.

3. The BizTalk Framework Disassembler. It accepts messages sent using the reliable messaging mechanism defined by the BizTalk Framework, which was implemented in BizTalk Server 2000.

Validate Stage: BizTalk Server 2006 provides one standard component for this stage, the XML Validator. This component validates an XML document produced by the Disassemble stage against a specified schema or group of schemas, returning an error if the document doesn’t conform to one of those schemas.

Resolve Party: BizTalk Server 2006 provides one standard component for this stage, Party Resolution, which attempts to determine an identity for the message’s sender. If the message was digitally signed, the signature is used to look up a Windows identity in the Management database of BizTalk Server 2006. If the message carries the authenticated security identifier (SID) of a Windows user, this identity is used. If neither mechanism succeeds, the message’s sender is assigned a default anonymous identity.

4.1.2 Standard components provided for each stages of a send pipeline:


Pre-assemble Stage: No standard components are provided but custom components can be inserted here as needed.

Assemble Stage: As the Disassemble stage in a receive pipeline, this stage also has three standard components. They implement the inverse operation of the receive pipeline standard components.

1. The Flat File Assembler converts an XML message into a positional or delimited flat file.

2. The XML Assembler supports adding an envelope and making other changes to an outgoing XML message.
Main role of the assembler:
- The assembler creates the envelope by using a specified envelope.
- The component copy the context properties values to the XML message by using the predefined XPaths coded as annotations in the XSD schemas of the message.
- The component copy the context properties to the envelope by using the predefined XPaths coded as annotations in the XSD schemas associated with envelopes.
- The component appends the message to the envelope.

3. The BizTalk Framework Assembler packages messages for reliable transmission using the BizTalk Framework messaging technology.

Encode Stage: The MIME/SMIME Encoder. It implements the inverse operation as the MIME/SMIME decoder component of the receive pipeline.
This component packages outgoing messages in either MIME or S/MIME format. If S/MIME is used, the message can also be digitally signed and/or encrypted.

4.2 Standard Pipelines

The standard pipelines are shipped with the BizTalk server product. They cannot be modified in the Pipeline Designer. The pipeline designer is a tool to create new pipelines from within Visual Studio 2005.
These default pipelines are ready to use and can be selected when configuring a send port or receive location in BizTalk Explorer or during the configuration of a send or receive shape within the orchestration designer.
The two pairs of default pipelines available are the pass-through pipelines and the XML pipelines.

Pass-Through Pipelines.
The pass-through pipelines have no components. They are used for simple pass-through scenarios when no message payload processing is necessary. These pipelines are generally used when the source and the destination of the message are known, and the message requires no validation, encoding, or disassembling.

Particularity of the pass-through receive pipeline:
Because it does not contain a disassembler, the pass-through receive pipeline cannot be used to route messages to orchestrations (as it is the disassemble stage that does the property promotion).
The pass-through receive pipeline does not support property promotion.

Particularity of the pass-through send pipeline:
No particularity, it just sends the message to the adapter as it was received from the MessageBox.

XML Pipelines.
The XML pipelines are the default pipelines that should be used when the message sent or received are already in XML and must be fully functional within the BizTalk system (for example, orchestration must be able to subscribe to them, properties promotion must be possible).

Particularity of the XML receive pipeline:
The XML receive pipeline consists of the following stages:
1. Decode. Empty
2. Disassemble. Contains the XML Disassembler component.
3. Validate. Empty
4. Resolve Party. Runs the Party Resolution component.

Particularity of the XML send pipeline:
The XML send pipeline consists of the following stages:
1. Pre-assemble. Empty
2. Assemble. Contains the XML Assembler component
3. Encode. Empty


Pictures in this post were taken from the BizTalk documentation. Hope that's alright!

BizTalk process and Service name relation.

Under Windows, the simplest way to see the CPU usage and Memory usage of a process is by using the Windows Task Manager.

If your BizTalk server contains many BizTalk applications and no performance monitoring system such as WMI installed or configured, a quick way to check which BizTalk process is using the most resource is through the Task Manager.
The only problem with this method is that all you will see under the Task Manager is something like:



Under Windows XP and Windows Server 2003, the Task Manager will show the executable name of the process and the PID (the Process ID - a unique number across all processes) but does not show the Windows Service(s) name that the process is running.

The Windows Services browser (found in the Computer Management application or by running “services.msc”) shows service names:



In the picture above, you can see that I have many BizTalk Windows Services started; each of them being in fact what is called a “BizTalk host”. A BizTalk host is the windows service process that will host 1 or more BizTalk application. As you can see, each BizTalk host is assigned a different Service name - a concatenation of the BizTalk group name and the BizTalk Host name.

To know which BizTalk application uses the most server resource, I need to relate my readings from Task Manager (the process PID) and the Service Name in the services browser. There are 2 ways to discover this relationship; the first is by using a standard command line utility (tasklist) and the second is by downloading a tool (process explorer).


1. Tasklist command.

The simplest way to know which BizTalk host is run by which process is to use the command line utility tasklist.

Tasklist.exe is a command line utility program available in standard for both Windows XP Pro and Windows Server 2003. XP Home seems to not have that utility but this is a non-issue for BizTalkers.
Tasklist displays a list of applications (processes) running on a system. One interesting thing is that it has an option to display the name of the windows services running under each process. Note that some processes, such as svchost.exe, can host more than 1 Windows Service. Svchost is a special process hosting Windows Services that don’t have their own executable host (process). Basically, svchost is used to run Windows Services which are encapsulated as a dll, such as drivers, network management and other basic services.
If a process does not run any Windows Service, such as normal executables, tasklist will display N/A instead of a service name. For Example the process of MS Word, WINWORD, displays N/A for the service name.

Tasklist usage example:

“Tasklist /svc” will display all the processes with the windows services name running in each process (if any).

“tasklist /svc /fi "imagename eq btsntsvc.exe” will display all the BizTalk host processes and the service (host) name running in each process. In my environment I have the following result:



In this way, through the PID, I can relate which process is running which Windows Service (BizTalk host in my instance). So, I can go to Task Manager and see which BizTalk host is consuming the most CPU and memory resource.


2. Process Explorer.

If you don’t like command line tools and prefer to use a Windows application, you can download and install Process Explorer, available for download on Technet.

Process Explorer is some kind of "Task Manager on steroids” which shows you much more information than Task Manager does. For our particular need is able to show what Windows Services is running under each process.

To see the services running under a process, open Process Explorer, find the services.exe node (under which are all processes running Windows Services), locate the BizTalk.exe processes and right click on them, then click “properties” in the context menu and finally click on the “Services” tab; you will see the name of the Windows Service run by that process.

Screenshot of the properties window of a BizTalk process showing the name of the BizTalk Windows Service host running.

Using the Enterprise Library in Biztalk Functoid.

Enterprise Library.

The Enterprise Library is a set of .Net application blocks providing many useful features that can be re-used across projects. I find it now a more mature library which developers can rely on. At the time of writing, the Enterprise Library 3.1 is available at the Microsoft Patterns & Practices site.


Custom Database BizTalk Functoid implementing Caching.

I created a BizTalk functoid which is responsible to lookup values into a database. This particular lookup not being a simple query, a custom functoid was required. With the database lookups becoming a bottleneck when mapping larger messages, I had to implement a caching strategy within the functoid.
I chose to go with the Enterprise Library to implement the caching functionality as it provides nice features such as scavenging and expirations (similar to the ASP.NET cache engine). Some people might think of using the ASP.NET Cache instead but I did not and I would not advise it. Although some people say it is possible to use it outside ASP.NET application, it is not recommended by Microsoft so I did not even try to go down that road. See the System.Web.Caching.Cache reference.


Enterprise Library application block configuration.

The Enterprise Library instantiates objects through the use of a static factory. The application blocks’ factories create objects and configure them by using information from a configuration file, by default the web.config or app.config XML config file - depending if it’s a running from an executable or an ASP.NET page.

The BizTalk runtime is also a .Net application, so it has an XML config file called BTSNTSvc.exe.config which is located in the root folder where BizTalk is installed.
As the functoid using the Enterprise Library Caching application block will run from the BizTalk runtime, the application block configuration will need to reside in BTSNTSvc.exe.config. It is important to remember that all BizTalk hosts running on a BizTalk server will use the same BTSNTSvc.exe.config file. This is somewhat some kind of limitation.
Note that it is possible to use other configuration source than the default .Net .config file, see the Enterprise Library documentation for more details.


Adding a component in the Visual Studio Toolbox.

Adding a custom functoid in the Visual Studio Toolbox is pretty straightforward. See http://msdn2.microsoft.com/en-us/library/aa559309.aspx
Note that if you deploy the BizTalk solution on the same machine you develop, you will have to add the functoid in the GAC so that the map using it will be able to find it at runtime.

One important thing to know is that when adding a component in the Visual Studio Toolbox, the component constructor is called. This is because the Visual Studio design time service needs to retrieve some of the component properties to be able to display and modify them in the properties window.
Most of you know that when working with .Net Windows Forms, all components or controls have a constructor which calls the InitializeComponent() method where all the properties and members of the component are initialized.
This initialization is of course needed for runtime but also for design time, so that’s why a component’s constructor is called during design time as well.

Example of design time properties for a Windows Application Form control (Button).

The Button control properties are displayed in the “properties” windows correctly because an instance of the component has been initialized by the Visual Studio design time service, so its properties have been initialized and can be read and displayed by the IDE.

In the case of a BizTalk functoid, the same mechanism exists, the properties which are needed for design time are initialized in the constructor.
For example, the functoid’s name, tooltip, description and also the functoid bitmap used to display the functoid in the toolbox and in the mapper editor are set in the constructor using calls to inherited methods:
SetName("ResourceKeyForFunctoidName");
SetTooltip("ResourceKeyForFunctoidToolTip”);
SetDescription("ResourceKeyForFunctoidDescription");
SetBitmap("ResourceKeyForFunctoidBitmap");

Example of design time properties for a BizTalk functoid (Cumulative Sum)

Example of design time properties for a custom BizTalk functoid

As you can see, it is obvious that the Visual Studio Design time environment needs to make an instance of the component so that it can evaluates all its properties to display in the Visual Studio IDE.


Adding the custom functoid in the Toolbox is not working / Testing a map using the custom functoid throws an exception.

During design time and when testing a map, the Visual Studio runtime is used to instantiate and call methods on the functoid. This means that until the configuration block is configured for Visual Studio, the application block’s static factory won’t find its configuration and an error will occur when the call to the application block’s static factory runs.
This error will happen either when:
- adding the functoid in the toolbox, if the call to the application block factory is in the functoid constructor
- testing a map using the functoid, if the call to the application block factory is in the functoid method.
The solution to this problem is to add the application block configuration in the Visual Studio IDE config file, devenv.exe.config, typically located at C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\


Conclusion:

To summarize, when using the Enterprise Library in a BizTalk project – such as a functoid or any other piece of custom code, the application block configuration information must be stored in the BTSNTSvc.exe.config (for the BizTalk runtime) and devenv.exe.config (for the design time experience under Visual Studio runtime).

Mistake in the BizTalk Server 2006 Installation Guide for Windows XP.

I just installed BizTalk Server 2006 on my laptop, a Windows XP machine.
Microsoft provides installation guides for BizTalk 2006 for every Windows version officially supported by BizTalk 2006, see BizTalk Server 2006 Installation and Upgrade Guides.
So, I strictly followed the installation guide provided for Windows XP (BizTalk Server 2006 Installation Guide - Windows XP.doc) and I could not have one of the post-installation tasks to work (Post-Installation Requirements, p.49 of the document):

"Add the HWS Web Service user to the IIS_WPG and STS_WPG Windows groups."

My machine does not have any user named “HWS Web Service”, neither an IIS_WPG nor a STS_WPG Windows user group.


I believe that this post-installation task should not be part of the Installation Guide for Windows XP.
Indeed, I did some research and came with the following thoughts:

1. IIS_WPG is a Windows user group created when installing IIS on Windows Server 2003. Windows Server 2003 runs IIS 6.0 and has the concept of Application Pool. Each Application Pool runs in its own Worker Process (w3wp.exe). The Worker Process must run with a Windows user that belongs to the IIS_WPG as the group provides the minimum set of privileges and permissions required to start and run a worker process.
Windows XP runs IIS 5.1 which does not have the concept of Application Pool – it’s new with IIS 6.0, so, there is no Windows user group needed for it.

2. STS_WPG is a Windows user group related to SharePoint Portal Server. As SharePoint can’t be installed on a Windows XP machine, that user group can’t possibly exists on Windows XP.

So it seems that this post-installation task is needed to give the HWS Web Service Windows user the rights to run some SharePoint component and to run its own IIS Worker Process on Windows Server 2003.

To conclude, I assume that this post-installation task is just a mistake in the installation guide document. It is something that you have to do on Windows Server 2003 but not on Windows XP.

WMI Script to terminate Biztalk 2006 suspended service instances.

In some cases, on your production environment, you might have a lot of service instances that are suspended and for which it is okay to systematically terminate.

Until now, once in a while, I went into the BizTalk 2006 Server Administration Console and terminated manually suspended service instances. As in my case all those suspended instances are part of search functionality for which it is ok to fail or time out, I can purge all of them safely without risk.


WMI Script to terminate suspended service instances.

Getting bored of doing that manually through the Administration Console, I found a WMI script in MSDN that can terminate suspended service instances of any type such as orchestration services, messaging services, routing services…
The script can be found at: https://msdn2.microsoft.com/en-us/library/bb203857.aspx

To avoid having to run the WMI script manually, I created a windows scheduled task so that it runs automatically on a regular basis, which helps me keeping a clean BizTalk Database and is now part of my diverse jobs and script which keep my server as clean as possible.

Note that as the WMI script provided by MSDN displays a lot of alert pop up windows, so you will need to run the script through WScript with the //B option (// B stands for Batch mode which suppresses script error and prompts from displaying).
In my case, my schedule task runs the following command: WScript Terminate.vbs //B -A –nosave

One important note is that this will terminate all suspended service instances for ALL the BizTalk applications installed on your BizTalk server, regardless on the host they are running.
So, you will have to ask yourself if this solution is eligible for you. It is mainly depending on your business scenarios and if it dictates that you have to investigate errors case by case if they happen.
You can nevertheless tweak the WMI script to terminate only specific suspended service instances which shares some common properties.


About WMI.

I am far from being WMI specialist but for people coming across WMI for a first time, WMI can be seen as database holding information about diverse subsystems in a computer (both hardware and software). To retrieve information about a particular subsystem, you will execute a SELECT statement on an object that represents the WMI Database for that particular subsystem.
For BizTalk, you will retrieve an object representing the BizTalk server subsystem with something like:
Set objBtsWmiNS = GetObject("Winmgmts:!root\MicrosoftBizTalkServer")

The object objBtsWmiNS can be viewed as an object representing the WMI database for the BizTalk server subsystem. On that object, you can call the method ExecQuery() taking a query string in parameter - a SELECT statement. This method will return an array of WMI objects that you selected in your SELECT statement. The fictional table name in the SELECT statement is the name of the class in the WMI class model for which you want to retrieve instances.

So, a query like “select * from MSBTS_HostSetting” will return an array of all the instances of the MSBTS_HostSetting class. If you add a WHERE clause in the query, it will return only the instances satisfying the WHERE clause.

In our case this means that you can tweak the WMI script to select only suspended service instances based on some criteria to be more restrictive.


Goodies.

To analyze what you need to add in the WHERE clause of the SELECT statement in the WMI script, I found a cool tool which generates a script that prints out all the properties of all the instances of a selected WMI class. By analyzing the properties values, you can create a set of criteria separating the suspended service instances that can be terminated from the one that must be kept.

The WMI class reference for BizTalk can be found at
BizTalk 2006 WMI Class Reference