Month: June 2007

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