Identifing the BizTalk Host from the Process Name

In a production system, it’s likely that you’ll have multiple hosts (and therefore multiple instances of the btsntsvc.exe process) running on a particular server. If one of the btsntsvc processes is performing particularily badly – e.g. hogging all of your CPU – how do you identify the host?

Windows Task Manager - BizTalk Processes
Fire-up Task Manager and identify the PID of the offending process (if you don’t have the PID column, add it by clicking View -> Select Columns). Armed with that information, use the tasklist command to view which Windows Service (i.e. Host) relates to the PID, as follows:

tasklist /svc /fi “imagename eq btsntsvc64.exe

The tasklist command will list the processes matching the query string, their PID and service name (something similar to the screenshot below). With your PID from the Task Manager, making the correlation between process and Host is straightforward.

Tasklist Command Results for BizTalk Host Instance Process
Note that in the tasklist example above, I’m specifically searching for 64-bit processes – if you’re working on a 32-bit system (or you’re search for 32-bit processes on a 64-bit system), your search string will just be ‘btsntsvc.exe’. My Thanks to Francois Malgreve who originally helped me with this problem.

Biztalk Explorer OM not Supported in a 64 bit Environment

Imagine a scenario where you want to create 1400 receive locations; to make life simpler, you’d probably want to use WMI or the BizTalk Explorer OM.

Not much of an issue there, however what happens when you try an run some custom C# code that creates the receive locations (and therefore references the Microsoft.BizTalk.ExplorerOM assembly) from within an orchestration [expression shape] that executes as a 64-bit process?

You get the following error XLANG/S error:

Event Type: Error
Event Source: XLANG/s
Event Category: None
Event ID: 10034
Date: 14/08/2007
Time: 19:22:49
User: N/A
Computer: WINBT01
Description:
Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘Demo.Integration.CustomerLink.Orchestrations.UserAdministration(108ace24-3b9d-e084-c9ea-f342878676e6)’.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 95ae9c6b-9af4-468b-9a3c-6398d7fba629
Shape name: CreateFileReceiveLocationExpression
ShapeId: 3695bc5d-cec3-4c9b-b2ca-84e0917a7bc1
Exception thrown from: segment 1, progress 22
Inner exception: Explorer OM is not supported in a 64bit process.

Exception type: BtsException
Source: Microsoft.BizTalk.ExplorerOM
Target Site: Void .ctor()
The following is a stack trace that identifies the location where the exception occured

at Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer..ctor()
at Demo.Integration.CustomerLink.FileReceiveLocation.Create(String user)
at Demo.Integration.CustomerLink.Orchestrations.UserAdministration.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)

Hmmm, that’s a bit odd, especially given that both the custom and Explorer OM assemblies are compiled to MSIL (not a target platform), which should suggest that when invoked from the 64-bit orchestration the JIT-Compiler will compile both to run a 64-bit process:

Explorer OM Assembly configurationThis doesn’t appear to be the case at all – in order to successfully run, you need to force the Host under which the orchestration is executing to run in a 32-bit process (rather than the native 64-bit) using the ’32-bit only’ checkbox on the Host Properties page:

Host Properties PageThis doesn’t make much sense to me, so I plan on doing more investigation into the problem. I’ll post my findings once I have a definitive answer.

Help Wanted: Receive Locations Disabling Unexpectedly

A colleague of mine is running into an issue with a large number of receive locations on a single port and I would appreciate some community advice on how to resolve the issue.

He is running approx. 1400 file Receive Locations on a single Receive Port and after starting all of the locations, they slowly start to disable themselves with the following error message in the Event Log (note, the share isn’t actually called ‘sharename’ in the environment):

The receive location “33183-FTP Receive Location” with URL “\sharenameFTP33183IN*.*” is shutting down. Details:”The FILE receive location \sharenameFTP33183IN*.* exhausted the network retry attempts.”.

For reference, the BizTalk environment is based on 2 servers participating in a group (Enterprise Edition), with the 1400 receive locations using a single Host (one Host Instance per server). The receive locations are polling a Windows SMB share hosted on a separate system; the authentication credentials are confirmed as being correct.

We have increased the maximum number of NetBIOS connections from the default of 50 to 2000 (well within the limit of 65,000) after reading this blog entry and KB article 810886. We have also turned the file Receive Location polling off as per Rasmus Kristensen newsgroup entry.

Unfortunately, I’ve yet to take a look at the environment, but my initial thoughts are:

  • The host instances are exhausting their available threads / memory – creating additional Hosts and moving the Receive Locations out to multiple Receive Ports may stop this problem.
  • There are still NetBIOS connection issues – the ‘exhausted the network retry attempts’ seems to imply that this may be the case.
  • Are we exceeding the maximum number of usable Receive Locations per Receive Port? Does anyone know how many locations a port can contain?

I’ll be traveling to the client early site next week to investigate (I imagine that PerfMon and I will become close friends), however in the meantime it would be good to get any advice from the community – have I missed anything obvious here??

Any comments or suggestions are greatly welcomed.

Nick.

Replicate the IIS6 Metabase Between Nodes

I know that this is a little off-topic, but here goes…. A colleague asked me to have a look at replicating the IIS6 Metabase between two load-balanced web servers that form the front-end of a larger BizTalk environment. After my protests of ‘but I’m a BizTalk guy’ fell on deaf ears and I started to investigate the problem, I was pleasantly surprised with the functionality provided ‘out of the box’ by IIS; of particular interest to the replication problem were following two VBS scripts:

  • IIsCnfg.vbs -Performs Metabase replicated between IIS6 nodes or exported/imported to file.
  • IIsBackup.vbs – Performs Metabase backups/restores and provides the facility to list and delete existing backups.

So how do we go about using these scripts? They exist in the C:WINDOWSSystem32 directory and are all well documented (just execute the script with the help switch (/?) and the list of possible options are presented.

Backing Up the IIS Metabase

To perform a daily (scheduled) backup of the metabase on the local machine, I would suggest running something along the following lines:

C:WINDOWSSystem32iisback.vbs /backup /b DailyBackup

If you wanted to backup the Metabase on a remote machine, simply add the /s (server) switch: this indicates the remote server on which to run the backup (note in the previous example, where no /s switch is supplied, the script defaults to the local server):

C:WINDOWSSystem32iisback.vbs /s winbtiis02 /backup /b DailyBackup

If we wanted to review the backup history, we can list the backups on a local (or remote) server, using the /list switch, as follows:

C:WINDOWSSystem32iisback.vbs /list

which produces the following output (note the last backup in the list – The IIS Setup automatically creates a backup at the end of its run):

Connecting to server ...Done.
Backup Name Version # Date/Time
========================================================================
DailyBackup 0 14/08/2007 17:08:49
DailyBackup 1 14/08/2007 17:08:58
DailyBackup 2 16/08/2007 11:04:38
DailyBackup 3 16/08/2007 11:04:41
DailyBackup 4 16/08/2007 11:04:43
DailyBackup 5 16/08/2007 11:04:44
DailyBackup 6 16/08/2007 11:04:46
DailyBackup 7 16/08/2007 11:04:47
Initial Backup - created automatically by IIS setup 1 15/07/2007 23:28:59

To delete a backup on a local (or remote) server, use the /list switch along with the /b (backup name) and /v (version number) switches:

C:WINDOWSSystem32iisback.vbs /delete /b DailyBackup /v 0

This command would delete version zero of the ‘DailyBackup’ backup. Remember, if you want to run these commands on a remote server, just add the /s switch and the remote server name!

Replicating the IIS Metabase

The IIsCnfg.vbs script performs a number of different functions – including importing and exporting Metabase config files, saving the Metabase to disk etc. – but the one I was particularly in was the replication functionality offered through the /copy switch.

To replicate the IIS Metabase from one server to another, the following command can be used:

C:WINDOWSSystem32iiscnfg.vbs /copy /s winbtiis01 /ts winbtiis02 /tu Username /tp Password

The /copy switch indicates that the Metabase is to be replicated from the source server (specified in the /s switch – not necessarily required) to the target server (the /ts switch) using the target server user (the /tu switch) and target server password (the /tp switch).

The script is essentially a wrapper for a backup and restore operation (using the IIsBack.vbs script mentioned above) – go and have a look at the code if you’re interested (the function in question is called Repl and starts on line 721). In a nutshell, it performs the following operations:

  • Backs-up the source server Metabase (and forces an overwrite of an existing backp if necessary), creating a backup with the name iisreplback;
  • Maps drives on both the source and destination servers using the next available drive letters (which may be different on the two servers);
  • Copies the backup created above to the destination server (the backup is taken from C:WINDOWSSystem32inetsrvmetaback and written to the same directory on the destination server)
  • Unmaps the drive to the source server;
  • Restores the backup (on the remote server) using the IIsBack.vbs script;
  • Unmaps the drive to the destination server;

A Usable Replication Script

Armed with this newfound knowledge, I put together the following batch script to backup the Metabase (on the source and destination servers) and replicate between the two; finally the script lists the backups on both servers for auditing purposes. I’m sure I could have done this in VBS, but any with the words VB in the name gives me the willies…..

# Backup the IIS Metabase on WINBTIIS01 and 02
C:
WINDOWSSystem32iisback.vbs /s winbtiis01 /backup /b DailyBackup
C:
WINDOWSSystem32iisback.vbs /s winbtiis02 /backup /b DailyBackup

# Replicate the IIS Metabase from WINBTIIS01 to 02
C:
WINDOWSSystem32iiscnfg.vbs /copy /s winbtiis01 /ts winbtiis02 /tu Username /tp Password

# List the IIS Metabase backups on both WINBTIIS01 and 02
C:
WINDOWSSystem32iisback.vbs /s winbtiis01 /list
C:
WINDOWSSystem32iisback.vbs /s winbtiis02 /list