Geeks With Blogs

News View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn
Michael Stephenson keeping your feet on premise while your heads in the cloud

Article Source:

I've recently been reviewing some BizTalk setups for various reasons. These include:

  • Is the setup correct
  • Performance analysis and issues
  • General troubleshooting

I thought it would be useful for me and others who might want to look at doing a review of a BizTalk setup to make some notes on some of the activities you might want to do.


Comparing Servers

I've come across a couple of instances previously when servers had been setup incorrectly with missing hot fixes or in one case a missing service pack for the .net framework on one server in a group. When you have a BizTalk group or a clustered SQL Server you want to ensure the servers in the group are all the same. In most cases they should have the same hardware and same software installed on them.

I had a bit of a Google on this and there doesn't seem to be that many tools which easily allow you to do this (if you know of any, or I have missed something obvious let me know), but the main way for doing this is with the PsInfo tool from Microsoft/SysInternals. The key thing with this tool is that I'm looking to validate that all servers have been setup with the correct software and hardware and they are all consistent. PsInfo is available from the following location and there are examples to show you how to do this.

 Update - Ive done a tool to help with this:


Reviewing Security with Microsoft Base Line Security Analyser

This is a free tool from Microsoft which will allow you to compare a set of servers against most of the recommended security standards. It will identify any vulnerabilities on the servers you have analysed and highlight them and offer recommendations on how to fix or mitigate the risk associated with it.

I would use this tool on all BizTalk and SQL Servers in the setup. This tool is available from the below link:


Reviewing SQL Server with SQL Server Best Practice Analyser

Most people are probably familiar with the SQL Server BPA, but if not this tool will collect information about your SQL Server instance and then compare this against best practice rules to highlight any issues with your setup. The tool also makes recommendations on how to resolve these issues. This is a very useful tool and is available from the following location:


Reviewing BizTalk Server Group with BizTalk Best Practice Analyser

The BizTalk BPA is a tool which will inspect your BizTalk Group and compare it against well known best practice rules for a BizTalk setup and identify any issues you may have. It also offers recommendations on how to resolve these. The BizTalk BPA is available from the following location:


Reviewing BizTalk Group with Message Box Viewer

MsgBoxViewer is an excellent tool developed by Jean-Pierre Auconie which allows you to run a whole bunch of queries against your BizTalk Group. It will provide you lots and lots of information about the group and also perform some analysis to advise you of things you might need to review. Rather than get into a lot of detail about it, I would like to refer you to Jean-Pierre's post where he gives you all the information you could want.

This tool is available from the following link:


Reviewing BizTalk Application setup with the BizTalk Documenter

When your application has been deployed one common problem is incorrect configuration of one of the many settings that are available. By using the BizTalk Documenter you can quickly and easily document your BizTalk system and then review the chm file to easily see what settings are applied. This gives you a change to look over the settings and potentially spot any problems.

The BizTalk Documenter is available from here:


Reviewing Activity by Parsing the IIS Logs

Lots of BizTalk projects will utilise IIS to expose web services to other applications. Using Log Parser to analyse the IIS logs is a good way to get an idea of the activity you are getting in IIS and also identify any errors that are happening. Below is some of the queries I often use to analyse IIS.



IIS Calls by hour

This will give you a breakdown of the number of calls per hour across the chosen day

Calls by hour and URL

This will give you a breakdown of the calls by hour and url across the day

Calls by minute

This allows you to get an analysis of the load on the server in terms of IIS calls per minute

Calls by minute and url

As above but with an additional split by url

IIS Errors

This will list all IIS requests which have responded with an error on that day

IIS Errors by url

As above but summarised by url

Request message size

Lists any large messages which have been sent to IIS (note this required additional IIS logging parameters to be enabled)

Response message size

Lists any large response messages which have been returned through IIS (note this required additional IIS logging parameters to be enabled)

Time taken

Lists the calls in terms of the overall duration of the request (note this required additional IIS logging parameters to be enabled)

Requests per day

Breaks down the calls to count how many there have been for each url for a given day


I have provided a sample of these queries from the samples folder at the bottom of the document.

The RunIISQueries.cmd file shows how to run the queries. You basically need to provide the following parameters

  • The output path where to place the reports
  • The path to the IIS log files which can be a remote server
  • The path to LogParser
  • The data to inspect for (in the format yyyy-mm-dd)

These queries tend to be useful on a project when you have limited information about expected volumes. We were able to analyse various servers and work out what the current volume information is, and also we used them to occasionally review the usage on test environments. The beauty of Log Parser is that it is very easy to do your own queries so if you use some different queries feel free to mention them in the comments.

Reviewing Activity by parsing the Event Log

The event log is one of the most important resources available to anyone managing or reviewing a BizTalk setup. It will contain information about any problems that have been experienced etc. On one of my projects we have setup some daily reports which will analyse the event log and give us different views on what has been logged daily. This is in addition to any alerts which get created by monitoring the event log with Openview or MOM.

Some of the event log queries we use are as follows:



This query will review the event log and find all events for the BizTalk event source

logparser "Select TO_STRING( TimeGenerated, 'yyyy-MM-dd' ) as Date, TimeGenerated, EventId as ID, SourceName Into <OutputPath>\EventLogBizTalkEvents.txt From \\<ComputerName>\Application Where Date Like '%<Date>%%' And SourceName Like 'BizTalk%%' Order By SourceName, EventId, TimeGenerated" -i:EVT -rtp:-1

This query will review the event log and find all events logged for our custom event source

logparser "Select TO_STRING( TimeGenerated, 'yyyy-MM-dd' ) as Date, TimeGenerated, EventId as ID, SourceName Into <OutputPath>\EventLogBupaEvents.txt From \\<ComputerName>\Application Where Date Like '%<Date>%%' And SourceName Like '<CustomEventSourceName>%%' Order By SourceName, EventId, TimeGenerated" -i:EVT -rtp:-1

This will review the event log and give a count of events for each event source and number

logparser "Select TO_STRING( TimeGenerated, 'yyyy-MM-dd' ) as Date, EventId as ID, Count(*) as NoEvents, SourceName Into <OutputPath>\EventLogSummary.txt From \\<ComputerName>\Application Where Date Like '%<Date>%%' Group By Date, ID, SourceName Order By SourceName" -i:EVT -rtp:-1


On the back of this analysis we keep a library of known events in Share point so we have information about all of the events we typically would expect to see. We run these reports and build up our knowledgebase through testing phases and then by the time we move into production we have already got a good ability to support our solution in place.

Quite often too we have come across intermittent problems which are difficult to track down, using Log Parser helps us to analyse the event log for information across multiple servers which might help us to solve this.


Reviewing Activity from HAT with the Orchestration Profiler

The BizTalk orchestration profiler is another useful tool to help you review activity on a BizTalk Group. One of the most common ways I use the tool is integrated into an automated testing process to ensure I have good code coverage. But it can also be used to point at a BizTalk Group and just analyse how the orchestrations are being executed. To be honest it is not really one of the first things I would do when doing a review, but it can help you look for unused orchestration paths and also be useful if you are doing a BizTalk upgrade project and want to see how often orchestrations are used. If I remember right you can also analyse the execution of orchestrations to look for performance bottlenecks within an orchestration.

There is lots of information in the community about this tool so rather than going into it in detail here I would like to refer you to the following site:


Reviewing activity from HAT with some custom queries

All BizTalk developers will be familiar with HAT. There are a bunch of out of the box queries which can give you various information and you can create your own queries specific to your solution. This section is more for completeness of the article as there is plenty of documentation about the standard queries, and you will make your own up to suit your own needs.


Performance Analysis with Perfmon and PAL

I'm often surprised how many times I've done a BizTalk interview and asked a candidate about how to analyse a specific performance issue with BizTalk and how few times anyone mentions perfmon. There are loads of performance counters for all of the different features of BizTalk, and you can also create your own to compliment your solution. These counters can give you valuable information about the health of your BizTalk Group.

If you want to perform a very simple performance analysis of your BizTalk Group both Perfmon and PAL can help you do this. The steps would be as follows:

  1. Use Chapter 9 of Darren Jeffords excellent book to review a simple way to setup your perfmon trace for your BizTalk Group using the spreadsheet he provides.
  2. Start your Perfmon trace and run it while your Group is doing its work
  3. Stop the perfmon trace
  4. Run the PAL tool (available here) against the Perfmon output file
  5. Review the PAL report

The PAL tool will review the captured performance information against recognised benchmarks and produce a report which will highlight any problems or things to be reviewed.

Review Configuration Files

One of the other common deployment mistakes comes when you have configuration information held in configuration files such as BTNTSVC.exe.config or possibly held in SSO or some other configuration store. When you have this kind of configuration it often changes depending on which environment you have deployed to and it is a common issue in deployment that the wrong configuration values have been deployed.

I usually give these files a quick sanity check manually, but also to mitigate the risk of this problem happening in the first place I usually use the approach I discuss in my article about configuring binding files to allow me to have a template and way of producing configuration and binding files for different environments by abstracting the values from the binding/configuration file template.

There is also the spreadsheet option available as part of the deployment framework which Scott Colestock created check the following link for details:,guid,b9c45d34-85c8-449f-b1a6-deafc2d89084.aspx


Operational Monitoring Tool

Finally if you read my blog regularly you will have seen me going on about how important it is for organisations to monitor their systems with a tool such as MOM/SCOM or HP Openview. These tools will highlight lots of the things which you might find using the above reviewing techniques because they would have preconfigured alerts in them. My two most common questions when reviewing a BizTalk solution related to this are:

  • Is the customer monitoring their BizTalk environments with something like MOM
  • Are they staying on top of the alerts that are being raised

If the answer to the above 2 questions is yes then it's a good indicator than an overall review would be good.



This article was intended to discuss some of the various techniques you might use to perform different types of review of a BizTalk environment. These reviews would aim to ensure that a group has been setup and deployed correctly, and then is managed and operates effectively when it is used.

Id be interested in any thoughts or other things people do in terms of this.



Posted on Saturday, September 13, 2008 8:59 PM BizTalk | Back to top

Comments on this post: Reviewing a BizTalk Group

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Michael Stephenson | Powered by: