PowerShell for BizTalk Administration: Suspended Message Counts

Continuing on with using PowerShell to help with BizTalk administration, I'd like to focus on suspended messages.

Sometimes, one of our internal departments expects a message to come in at a particular time. There are times, however, that the message was never sent to BizTalk for processing. Either way, the "I don't see an expected message, can you see if it failed?" routine is communicated our way. Keep in mind that we already have put mechanisms in place to notify if something failed... :)

At any rate, I've developed a quick PowerShell script to see if anything indeed has suspended. This one uses SQL, and it hooks into the BizTalk MessageBox Database; make sure permissions are set accordingly. This post is rather code agnostic, but the approach is to use PowerShell to be consistent with the other scripts which our group has put in place.

The query is a common, read-only script that you may have seen elsewhere:


The next step is to do the traditional SQL routine, create the SQL connection, open it, put it into a SQL adapter, and so on.


Now you have a list of all suspended messages in a typical .NET DataSet. From there we can slice and dice the information. I like sorting and grouping everything out, and PowerShell does a fantastic job of that.


The result is a list of unique BizTalk applications in your environment with a suspended message count for each application. If there aren't any suspended messages, obviously you won't have any rows in your DataSet, and you can notify your customers that everything is operating as expected in BizTalk. ;)

Interesting...

Google and Microsoft agree on something.

PowerShell for BizTalk Administration: Is this thing on? Part 3

In Part 2 I outlined getting the status of BizTalk artifacts (Recieve Locations, Send Ports, and Orchestrations) using PowerShell. All 3 of those use the same pattern. Validating the status of the Host Instances, however, can be done without using the Microsoft.BizTalk.ExplorerOM.

Looking at the Host Instances (not Hosts) at a high level, they are nothing more than a Windows Service on a server. So two ways to get information on a service via PowerShell is use use either the Win32_Process or Win32_Service objects using the PowerShell Get-WMIObject command. However, there is a unique WMI object specifically for BizTalk: MSBTS_HostInstance. I chose the last one for my script.  This does assume you have this class installed on the server you are making the call from.

Instantiating the object is a one-liner (no need to establish the SQL Server, as in the previous post).  At that point you can loop through each host instance and get the state of the Host Instances.

PowerShell for BizTalk Administration: Is this thing on? Part 2

In Part 1, the story is set up that we may need to get some information on BizTalk in a quick, detailed way.  We could certainly use the BizTalk Administration console, but I'd have to remote in to the server.  Our security model makes that a little difficult.

So the first thing I'd like to check are the Receive Locations and the Send Ports.  I want to create this in a script so I can run this at-will.  There are a few ways to do this: NotePad being the most basic, or we could download the PowerShell ISE.  But my favorite is SAPIEN PowerShell Studio.  I'm still trying to figure out why Microsoft hasn't tightly integrated this kind of functionality to Visual Studio.

So back to the scenario.  The object to use in both cases is the Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer:

You may notice the hard way that this object is a 32-bit only object.  So, if you are running in a 64-bit mode of PowerShell, your script won't run.  You will need to force 32-bit mode.  This can be done with the following:

The above two snippets are the basis of setting up both Receive Locations and Send Ports.  I'll first focus on the Send Ports.  The first thing is to instantiate an object using the BizTalk Explorer Object Model.  Once that's done, we'll need to connect to the proper BizTalk database.  After that's done, it's a simple loop to go through each Send Port:

Receive Locations are nested one level deeper than Send Ports, otherwise they are essentially the same process.

And (surprise, surprise) the Orchestration model is very similar as well.
And that's it.  Nothing incredibly complicated.  Obviously you'll want to code additional functionality (write out to a log file, for example) to tailor to your specific needs.  As a side note, a wonderful tool which helped me discover most BizTalk WMI objects is the PowerShell WMI Explorer.

Part 3 will cover Host Instances.

PowerShell for BizTalk Administration: Is this thing on? Part 1

I've been heavily involved with BizTalk administration - making sure our environment is healthy and keeping pace with processing well over 1,000 messages/second (yes, that much and more).  This is all done between 40+ applications, which uses hundreds of recieve ports, send ports, orchestrations, host instances, etc.  Our BizTalk environment pulls this off without a sweat.

There are times, however, when we need a quick response to "is this thing on?"  I've found, like many others, that using WMI calls and the Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer class within Powershell is mighty, mighty powerful (and easy)!  Placing these calls into PowerShell scripts are a quick, convenient way to find those answers.

As a highlight, the initial tasks are to verify the status (i.e. running/started) of the following BizTalk artifacts:

1. Receive Ports
2. Send Ports
3. Orchestrations
4. Host Instances

You could certainly make a call to get Application status (running, partial, stopped), but you'll find quickly that the above list goes into greater detail.  There are many cases where a particular send port may have stopped, and we may want to know that sooner than later.

Furthermore, it would be nice to get a quick view of suspended messages.  Later on, we'll discuss how to validate other artifacts outside of BizTalk (i.e. IIS) which are closely hooked into BizTalk.

We'll get into the Ports in Part 2.

Failed to Update Binding Information

Sometimes you may come across the error "Failed to update binding information" when trying to import bindings for a BizTalk application.

Your bindings may indeed be correct, and you likely also have the proper Host created (you checked THREE times already!).  However, you may not have added the host within the BizTalk Adapters.

This is especially common when building a new BizTalk server or have a BizTalk application which will be using a new Host.