Automating and Managing BizTalk Server 2013 with PowerShell

By Nick Hauenstein

This post is the ninth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

A lot of people want to be able to manage BizTalk Server from the command line or from within scripts – it is enterprise level server software after all. In the search for the right tool for the job, it seems most reach for the old stand-by BtsTask utility. Some come to realize that BizTalk Server also has pretty decent WMI support (wrapped around the Microsoft.BizTalk.ExplorerOM.dll assembly). Even fewer realize that BizTalk Server 2013 provides a nice PowerShell alternative (out-of-the-box) to that WMI interface that can be used to fully control your BizTalk installation. In this blog post, we will examine how to make use of that new functionality and we will see how we might also accomplish the same things in BizTalk Server 2010.

NOTE: The focus of this week’s post is as of yet undocumented in the official product documentation 🙁

If you spend enough time rummaging through the installation directory for BizTalk Server, you will inevitably eventually locate the figurative gold mine of tools that live in the %PROGRAMFILES(X86)%Microsoft BizTalk Server 2013SDKUtilities folder:

image

One of those folders recently caught my eye, as it was absent from my BizTalk Server 2010 installations – specifically the PowerShell folder.

image

Inside, one finds that this folder contains the soafactory PowerShell Provider for BizTalk. This is actually a project that wasn’t initiated by Microsoft, has some history before BizTalk Server 2013, but has now found its way to be bundled alongside the other Utilities in the SDK – and I couldn’t be happier about that.

Getting Started

In order to get started, fire-up the readme.txt, and follow along with the instructions listed:

  1. Open a command prompt as an administrator
  2. Change the directory to the folder containing the binaries
  3. Run the following command to install/register the dlls:
    %windir%Microsoft.NETFrameworkv4.0.30319InstallUtil.exe .BizTalkFactory.PowerShell.Extensions.dll
  4. Open a powershell console as admin in x86 mode and set execution policy as remote-signed:
    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
  5. Add the PS snap-in using the usual approach:
    Add-PSSnapIn -Name BiztalkFactory.PowerShell.Extensions

What Do I Get?

Any time that you add a PowerShell Snap-in, there is actually a relatively easy way to find out what new powers (in the form of cmdlets) that it gave you. If you’re not familiar fully with PowerShell, each cmdlet returns objects – not just strings of text that spill forth from the console. As a result, we can use a cmdlet called Get-Command to get a list of commands that are available, and then filter that list based on a specific property that each item in the list may have. In this case, the property that we want to filter on is the ModuleName (to see a listing of all the properties we could filter on use Get-Member | Get-Command).

I know some of you right now are saying, “Just tell me what to type so it will tell me what it gave me already!” So, here you go (here I’m using BizTalk* in place of typing the full name of the snap-in, so that you don’t have to type as much):

Get-Command | where { $_.ModuleName -like "BizTalk*" }

As you can see, you now have quite a bit of control of your BizTalk group at your finger tips:image

So how do you know how to use each of these cmdlets, and what it does? In the days before PowerShell, you may have typed something like this to see a given command’s (an executable of some kind) help screen and usage:

commandname.exe -?

Given that cmdlets aren’t actually independent .exe files, that’s not going to do you much good. Instead, PowerShell provides you a common way to access the documentation for any cmdlet through the use of the Get-Help cmdlet. Here’s an example:

Get-Help Enable-ReceiveLocation

Unfortunately, you may notice rather quickly that these particular cmdlets are lacking in the documentation department:

image

Traversing a BizTalk Group

Another interesting thing about PowerShell is the concept of providers themselves. They have the ability to provide visibility into the worlds of specific technologies. To be more specific, consider your hard drive. We think nothing of opening a command prompt and being able to type something like dir to see into that world and retrieve a listing of files. In PowerShell, dir is actually a helpful alias for the Get-ChildItem cmdlet (which is technically, again, returning a listing of objects).

If you happen to get a listing of PowerShell providers using the Get-PSProvider command, you will find that the snap-in we added also added a new world for us to explore:

image

In order to get to the world of BizTalk and start looking around, we can do things as simple as typing and executing the following:

cd BizTalk:
dir

image

I can then continue to naturally interact with what I’m presented, and navigate into the Applications “directory”, and then into a specific application I may have installed:

cd Applications dir

cd ‘.Which Runs Fastest’

image

image

Interacting with an Item

So that’s cool that we can see a listing of items in a given scope within our farm, but how can we actually interact with it? For that, PowerShell gives us the Get-Item cmdlet. As an example, consider my installation wherein I have the Which Runs Fastest application. I can back up to BizTalk:Applications and then perform a Get-Item on that application. Likely when I do that, I want to store it in some sort of variable so that I can then interact with that. So I am going to do that with the following:

$myApp = Get-Item '.Which Runs Fastest'

From there, I can investigate both the properties and methods (operations) that I can use to interact with that application using the Get-Member cmdlet:

image

So let’s try to make use of the Orchestrations property shown to give us a listing of Orchestrations alongside their ports (some prior investigation into that property using Get-Member was done for this one):

$myApp.Orchestrations | Format-Table FullName,Ports

image

Here we told PowerShell to provide us with a table formatted list by enumerating the values returned by that property, and then for the objects returned to show us the value of the FullName and Ports properties on those objects.

The sky is the limit though. You have full and scriptable access to the world of BizTalk, and the power of PowerShell at your disposal!

Take it to the Next Level

If you’re hungry for more and want to see more about how you can use PowerShell to manage your BizTalk environments, come join us for one of our upcoming BizTalk 2013 Administrator Immersion classes and you won’t regret it 🙂

4 thoughts on Automating and Managing BizTalk Server 2013 with PowerShell

  1. Timely post, NIck. Do you know if there are any licensing issues with using the PowerShell scripts in pre-2013 versions of BizTalk. I believe to use the BizTalkExplorerOM.dll, you needed a BizTalk license on the server you’d run your admin tools from (or am I wrong about that?), so just wondering if there is the same limitation with the PowerShell solution. Thanks!

  2. Pingback: BizTalk Server 2013 New Features Series Index | QuickLearn Training Blog

  3. Pingback: Installing the BizTalkFactory PowerShell Provider on BizTalk 2013 | Jeroen Maes

Leave a Reply

Your email address will not be published. Required fields are marked *