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.

enableBizTalkCompatibilityMode in SAP adapter bindings

I've installed the BizTalk SAP adapter (more specifically, the WCF LOB Adapter SDK) to my development box and have successfully connected to our test SAP environment.

Within Visual Studio, I created a new BizTalk solution, used the Consume Adapter Service, and selected the sapBinding option. I went through the process of configuring the connection string, credentials, contract type, and, in this case, which IDoc was needed to create the schemas and binding information.

It all works wonderfully well. Two things, however, make me scratch my head a little bit.

First, the binding xml file (you could import this at the application level within the Administration Console) which is created by the wizard assumes you will be using the WCF-Custom transport type instead of WCF-SAP. This isn't really that big of a deal, more of a curiosity, since the configurations are essentially the same, just displayed a bit differently.

Second, the binding file has the binding configuration/property enableBizTalkCompatibilityMode set to false. When I mouse-over this property when selecting the WCF-SAP transport, I get this:

Set to True when used within BizTalk. Set to False otherwise.

So why doesn't the wizard set this to True in the first place?

To be honest, I'm not sure what this property does, as the documentation for it is a bit light.

I'll keep you posted as I come across new findings.

BizTalk Install: "RPC server is unavailable"

I'm in the process of upgrading BizTalk 2009 to 2010. The new BizTalk environment is a two-server active/active environment - the operating system for both aren't using a clustered configuration. The SQL back end is a separate tier (SQL Server 2008R2).

The first BizTalk tier went flawless with the install and configuration. The second tier installation was successful as well.

However, when I tried to configure the second tier, I got the error "(RPC: 0x800706BA: The RPC server is unavailable.) (SSO)" when trying to Join to the existing Enterprise SSO.



There is a bit of documentation out there, and most of it led to information on MSDTC issues. One of the configurations within the BizTalk install is to ensure that the DTC rules are enabled within the firewall configuration. Those were enabled, yet I still recieved errors.

A Microsoft tool called DTCPing, helped me out considerably. I copied the executable to my app tiers and also to our SQL Server tier. You have to run them all simultaneously on each tier. I was able to ping from my BizTalk Sever tier to SQL, but I couldn't successfully ping in the opposite direction.

Hmmm, firewall?

Initial test: Turn the firewalls on the BizTalk app tiers off. Restart the DTCPing process. SUCCESS with ping!

So now we know it's a firewall issue. A new rule added to the firewall was the fix.

As a side note, Chris Forster does a decent job describing some background to MSDTC and SQL.

BizTalk 2010 and BAHS

If you have installed BizTalk Adapters for Host Systems (BAHS) in the past and are now looking to do the same for BizTalk 2010 (i.e. migrate from previous BizTalk version), Microsoft has rolled the adapters into BizTalk Host Integration Server 2010.

Licensing for HIS 2010 is included as part of BizTalk 2010 (6th bullet point down), so there are no worries about that.

If you just want the BizTalk adapters, configuration of HIS 2010 is not neccessary. Thanks to Stephen Jackson and Ben Cline for quick response and clarifications.

BizTalk 2010 Adapter Pack 2.0 install issues

I'm installing a new instance of BizTalk 2010 server, and wanted to add the WCF-SQL adapter. This requires the BizTalk LOB Adapter SDK 2010 as a prerequisite. The OS is Windows Server 2008R2, 64-bit.

After I downloaded and installed the SDK (x64), I installed the x64 version of the Microsoft BizTalk Adapter Pack (v2.0). I figured at this point I could now go into the BizTalk Administration console and add the WCF-SQL adapter by selecting Platform Settings/Adapters/(right-click) new/Adapter.

The Adapter dropdown list was empty.

It doesn't seem clear, but it seems apparent that you also need to install the x86 version of the Adapter Pack as well. I did not need to install the x86 version of the LOB SDK. Can anyone verify/clarify this?