Although we will have this fixed in the 1.0 final release I decided to provide a hotfix right now for those who want to play with the beta and have a remote SQL server. This is major show stopper.

If you want to receive the hotfix please drop me an e-mail (see about page of my blog) and I will send you the fix and instructions a.s.a.p.

As an alternative you can download the latest sources from codeplex and compile them yourself.

The hotfix will also fix other reported issues:

- #3042
- #3170
- #3280
- #3390
- #3391
- #3393

When debugging BizTalk solutions you find yourself many times in a situation where you need to attach the Visual Studio debugger to the running BizTalk host instance. This is very easy to do. In Visual Studio you simply select ‘Debug’ then ‘Attach to Process’. From the dialog you select the ‘BTSNTSvc.exe’ process and finally click the ‘Attach’ button.

It gets a little more tricky when you have multiple host instances running on your development box. The dialog now shows all host instances and you need to pick the one running the artifact (pipeline component, orchestration, etc.) that you want to debug. The bad thing is that there is no readable name displayed and the only property that distinguishes between the instances is the PID (column: ID). So how do you know how to pick the correct one and go on debugging?

There are basically two approaches:

- You select all the ‘BTSNTSvc.exe’ process in order to attach the debugger to all of them.

- You use some tooling to find out the PID.

Although the first option works, it is not the best solution. Attaching to all processes takes more time and resources so it is better to just pick the right one.

Now this is nothing new and there have been a number of smart people that blogged about methods to find out the PID for a host instance. Samples are here and here.

In this post I want to show the PowerShell way of doing this.

When I use the ‘Get-ChildItems’ cmdlet on the host instances container PowerShell shows a list of ‘BTSHostInstance’ objects in the console:

Since the process id is not a property of the ‘BTSHostInstance’ object it is not shown in the list.

Fortunately the nice thing about PowerShell is that you can extend properties with extra members using the Add-Member cmdlet. In the script below I create a function that adds a a property containing the process id to every non isolated host.

function GetHostPID
{
    Get-ChildItem -Path 'Biztalk:\Platform Settings\Host Instances' | ForEach-Object {

        if ($_.HostType -ne 'Isolated')
        {
            [string]$a = (Get-WmiObject Win32_Process -filter "CommandLine Like '%$($_.HostName)%'").ProcessId
       
            $_ | Add-Member -MemberType NoteProperty -Name PID -Value $a
       
            Write-Output $_
              
        }
    } | Format-Table PID, Name, HostName, NTGroupName, RunningServer, HostType, ServiceState
}

When I execute the function I get a nice list similar to the list above but with the PID added to every row:

I can add this function to my function library so it loads automatically on startup and is always available in my PowerShell console.

Of course you can do this without the PowerShell provider for BizTalk and use WMI only. In that case it would be hard and require far more lines of code to get a nice formatted list like show above.

Another option is that a new development team member has just started on a fresh development box and you want him to use the same host configuration that you have. There are a lot of other scenarios where you want to copy the configuration of your hosts and host instances to another machine.

A lot of great BizTalk people have already showed how this can be done in an automated way. Some samples are:

- VBScript and WMI
- Custom tool 1
- Custom tool 2

In this post I want to show you how this can be done using PowerShell and the PowerShell provider for BizTalk. So this is actually the next post in my series on more advanced things you can do with the provider.

I use a slightly different approach compared to the existing tools. I use a PowerShell script that can be executed on the source server. This is the server that already has the host configuration set up, for example a development server. The output of running this script is actually another PowerShell script that you can run on the destination server. This output scripts contains all necessary statements to create the hosts, corresponding host instances and settings.

This is how it works:

- execute the script
- the script prompts for the name and path of the output file:

- after a short while the script is finished and a PowerShell script is created. You can run this script on the destination server or send it to an administrator who will run it on another server.

This is the created script:

#Determine BizTalk root and switch to host container.
$BizTalkRoot = (get-psdrive -PsProvider BizTalk).Root
Join-Path $BizTalkRoot 'Platform Settings\Hosts' | Set-Location

$RunningServer = $Env:ComputerName
#Create hosts
#Create host 'ReceiveHost' and set properties.
New-Item -Path 'ReceiveHost' -HostType 'InProcess' -NtGroupName 'BizTalk Application Users' -AuthTrusted:$False
Set-ItemProperty -Path 'ReceiveHost' -Name HostTracking -Value False
Set-ItemProperty -Path 'ReceiveHost' -Name Is32BitOnly -Value True

#Create host 'ProcessingHost' and set properties.
New-Item -Path 'ProcessingHost' -HostType 'InProcess' -NtGroupName 'BizTalk Application Users' -AuthTrusted:$False
Set-ItemProperty -Path 'ProcessingHost' -Name HostTracking -Value False
Set-ItemProperty -Path 'ProcessingHost' -Name Is32BitOnly -Value True

#Create host 'SendHost' and set properties.
New-Item -Path 'SendHost' -HostType 'InProcess' -NtGroupName 'BizTalk Application Users' -AuthTrusted:$False
Set-ItemProperty -Path 'SendHost' -Name HostTracking -Value False
Set-ItemProperty -Path 'SendHost' -Name Is32BitOnly -Value False

#Create host 'TrackingHost' and set properties.
New-Item -Path 'TrackingHost' -HostType 'InProcess' -NtGroupName 'BizTalk Application Users' -AuthTrusted:$False
Set-ItemProperty -Path 'TrackingHost' -Name HostTracking -Value True
Set-ItemProperty -Path 'TrackingHost' -Name Is32BitOnly -Value False

#Switch to host instances container.
Join-Path $BizTalkRoot 'Platform Settings\Host Instances' | Set-Location

#Create host instances
#Create host instance 'Microsoft BizTalk Server ReceiveHost BTS2K9-DEV' and set properties.
$Credential = $Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''ReceiveHost''', '', '')
New-Item -Path 'hostinstance' -HostName 'ReceiveHost' -RunningServer $RunningServer -Credentials $Credential
Set-ItemProperty -Path 'Microsoft BizTalk Server ReceiveHost BTS2K9-DEV' -Name IsDisabled -Value False

#Create host instance 'Microsoft BizTalk Server ProcessingHost BTS2K9-DEV' and set properties.
$Credential = $Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''ProcessingHost''', '', '')
New-Item -Path 'hostinstance' -HostName 'ProcessingHost' -RunningServer $RunningServer -Credentials $Credential
Set-ItemProperty -Path 'Microsoft BizTalk Server ProcessingHost BTS2K9-DEV' -Name IsDisabled -Value False

#Create host instance 'Microsoft BizTalk Server SendHost BTS2K9-DEV' and set properties.
$Credential = $Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''SendHost''', '', '')
New-Item -Path 'hostinstance' -HostName 'SendHost' -RunningServer $RunningServer -Credentials $Credential
Set-ItemProperty -Path 'Microsoft BizTalk Server SendHost BTS2K9-DEV' -Name IsDisabled -Value False

#Create host instance 'Microsoft BizTalk Server TrackingHost BTS2K9-DEV' and set properties.
$Credential = $Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''TrackingHost''', '', '')
New-Item -Path 'hostinstance' -HostName 'TrackingHost' -RunningServer $RunningServer -Credentials $Credential
Set-ItemProperty -Path 'Microsoft BizTalk Server TrackingHost BTS2K9-DEV' -Name IsDisabled -Value False

There are a couple of things to mention about the generated script:

- This is by no means a script applicable for all situations and environments. The purpose is just to show the output script as a result of running the source script. The source script will probably need some modification to make it apply to your environment. For example the script does not take into account multi server configurations, etc.
- The output script will prompt for credentials for each host instance it will create. There are also ways to script this from source to destination. See for example here. In most cases hosts in different environments will run under different accounts which is why I choose to show a prompt each time.
- Also in this script the windows group for the host is kept the same for the destination environment. This might not be the case in your particular situation.

After running this script on the destination server I have a exact copy of my host environment on the source server.

The source script looks like this:

$ScriptFile = Read-Host 'Enter full path of script file:'</pre>
'#Determine BizTalk root and switch to host container.' | Out-File $ScriptFile
'$BizTalkRoot = (get-psdrive -PsProvider BizTalk).Root' | Out-File $ScriptFile -Append
'Join-Path $BizTalkRoot ''Platform Settings\Hosts'' | Set-Location' | Out-File $ScriptFile -Append
'' | Out-File $ScriptFile -Append

'$RunningServer = $Env:ComputerName' | Out-File $ScriptFile -Append

$BizTalkRoot = (get-psdrive -PsProvider BizTalk).Root
Join-Path $BizTalkRoot 'Platform Settings\Hosts' | Set-Location

'#Create hosts' | Out-File $ScriptFile -Append
$HostArray = @()
Get-ChildItem -Path . |  Foreach-Object {
    if (!$_.IsDefault -and $_.HostType -ne 'Isolated') {
   
        $HostArray += $_.Name
   
        "#Create host '$($_.Name)' and set properties." | Out-File $ScriptFile -Append
        "New-Item -Path '$($_.Name)' -HostType '$($_.HostType)' -NtGroupName '$($_.NtGroupName)' -AuthTrusted:`$$($_.AuthTrusted)" | Out-File $ScriptFile -Append
        "Set-ItemProperty -Path '$($_.Name)' -Name HostTracking -Value $($_.HostTracking)" | Out-File $ScriptFile -Append
        "Set-ItemProperty -Path '$($_.Name)' -Name Is32BitOnly -Value $($_.Is32BitOnly)" | Out-File $ScriptFile -Append
        '' | Out-File $ScriptFile -Append
                   
    }
}

'#Switch to host instances container.' | Out-File $ScriptFile -Append
'Join-Path $BizTalkRoot ''Platform Settings\Host Instances'' | Set-Location' | Out-File $ScriptFile -Append
'' | Out-File $ScriptFile -Append

Join-Path $BizTalkRoot 'Platform Settings\Host Instances' | Set-Location

'#Create host instances' | Out-File $ScriptFile -Append
Get-ChildItem -Path . |  Foreach-Object {
    if ($HostArray -contains $_.HostName) {
      
        "#Create host instance '$($_.Name)' and set properties." | Out-File $ScriptFile -Append
        "`$Credential = `$Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''$($_.HostName)''', '', '')" | Out-File $ScriptFile -Append
        "New-Item -Path 'hostinstance' -HostName '$($_.HostName)' -RunningServer `$RunningServer -Credentials `$Credential" | Out-File $ScriptFile -Append
        "Set-ItemProperty -Path '$($_.Name)' -Name IsDisabled -Value $($_.IsDisabled)" | Out-File $ScriptFile -Append
         '' | Out-File $ScriptFile -Append
       
    }
}

In the script I skip the default and isolated host. As with the generated output script this is just a sample and might not apply to your specific situation. The source script should be modified to confirm to your requirements and environment.

You can download the source script from here.

The best way to for any application to support management and automation is to implement such functionality on top of Windows PowerShell. Windows PowerShell contains a comprehensive API which enables the implementation of Cmdlets or a Cmdlet provider and the implementation of custom hosts.

Cmdlets or a cmdlet provider
PowerShell has uniform syntax for working with commands working and container hierarchies. This is a great advantage for administrators as they only need to learn a single way of working to manage it all. By implementing cmdlets we can “translate” this PowerShell way of working in calls to an applications native management API.

This is exactly what we have done in the provider for BizTalk. Internally we call BizTalk management APIs like ExplorerOM to perform things like starting applications, exporting MSIs, etc.

A custom host
Besides implementing custom cmdlets you can also implement a custom PowerShell host. The host can be any sort of application as long as it implements the PowerShell host interfaces. It can be a Win32 app, a web app or a text console for example.

This is exactly what Microsoft has done in the most recent versions of Exchange server (2007 & 2010). Management is done using PowerShell. The graphical management console is a PowerShell host. Exchange can be managed using this GUI or for example using scripts or commands running in the command shell console that comes out of the box with PowerShell.

The diagram below shows this architecture:

Things get even more interesting since we have PowerShell 2.0. It has a new feature called remoting which allows for remote administration and automation. Remoting uses WinRm (Microsofts implementation of the WS-Management standard). Goods news is that WinRM is firewall friendly. It only uses http(s) for communication. Now the diagram looks like this:

Is this secure? Yes it is, both PowerShell and WinRM have been designed with focus on security. Both come out of the box with security enabled. Of course you still need to pay attention especially when exposing things outside the enterprise.

Back to BizTalk
For BizTalk we have a couple of options to remotely administer a BizTalk server. We can choose between: Remote Desktop, client installation of Admin console, custom web services for management tasks, etc. Of course all have their pros and cons. With PowerShell remoting we have a new additional option.

Below I’ll show a couple of screens to see how this works.

I used two virtual machines in this demo. I installed the following software on those machines:

Virtual machine 1 (name: BTS2K9-dev):

- Windows Server 2008 R2 (I know not supported for hosting BizTalk)
- SQL Server 2008
- BizTalk Server 2009
- PowerShell 2.0
- PowerShell provider for BizTalk 1.0 (beta)

Virtual machine 2 (name: Client):

- Windows Server 2008 R2
- PowerShell 2.0
- PowerShell provider for BizTalk 1.0 (beta)

The obvious but important thing to note here is that the only thing that I have installed on virtual machine 2 that is related to BizTalk is the provider. In other words I did NOT NEED ANYTHING from the BizTalk installation CD on this machine.

The first thing I needed to was to enable remoting in PowerShell. This very simple and only requires the execution of a single command ‘Enable-PSRemoting’.

Second thing I needed to do was to add the client to the list of trusted computers on the BizTalk box. This mainly needs to be done because I just wanted to communicate over http instead of https for this demo.

On the BizTalk Box the management console is shown. Note that the default host instance is stopped:

Back to the PowerShell console on the Client to do the following:

- Create a new remote session on the BizTalk Box.
- Add the PowerShell provider snap in to the session.
- Switch to the default BizTalk drive.
- Switch the location to the host instances.
- Start the default host instance.

Finally a check on the other box to see if the host instance is running to verify this has worked (need to refresh the admin console first):

As you can see in the screen shots this is really easy to do. In my opinion it is a great new, location transparent, firewall friendly, client only way of managing BizTalk Server.

The only thing left to be done is to rebuild the BizTalk Administration Console on top of Windows PowerShell.

I usually do a lot of tryouts and proof of concepts on my development box. In my urge to get things working I never spend too much time on descriptive application names. I also never clean up things after I’m done.

This will in inevitably lead to the following mess after a couple of weeks:

From time to time I feel the need to clean up this mess. I used to do this with the BizTalk Administration Console. I start on top of the list right click the application to first stop and then delete it. Then I go to the second, etc.

The problems start to arise when there are references between applications. If I delete an application that is referenced from another application I get the following warning:

I can still delete the application but the warning is annoying and takes time. The last thing I want is to lose too much time cleaning up

Things get even worse when there are assembly resources inside the application which are referred to by assembly resources in other applications. This time it is not a warning but a serious error preventing me from deleting the application.

This means I need to take this reference dependency tree into account and delete the “child” applications before their “parents”.

This all makes cleaning up my development box very annoying and time consuming which is probably why I keep postponing it in the first place.

You can nicely automate this procedure using a generic application removal script that uses the PowerShell provider for BizTalk. In the script I take advantage of the exception handling possibilities of PowerShell. I sort of do a “on error resume next”.

This is how the script works:

• - Build a list of all the applications and put them in a array variable.
• - Loop through the list and try to delete the application on top of the list.
• - When the deletion fails because of dependencies we catch, in PowerShell terms “trap”, the exception and shuffle the array a little bit so that the application that failed is moved to the bottom of the list.
• - We then continue with the application that is now on top of the list.
• - The loop will end when all the applications are removed.

This is the script:

Some details about the script:

In the fragment below we use the provider to get a list of all applications. We make sure exclude the system and default application because they cannot be deleted.

The second thing to show in detail is the error handling routine. The provider (or actually the BizTalk Management Classes library) throws an exception of type BtsException since the application is referenced and cannot be deleted. We catch this exception by using a trap statement. In the exception handler we do two things. First we make sure to set a variable in the main scope so that we know what to do with the array later. Either move the top item to the bottom or remove the top item. Second we use “continue;” to have the main routine continue with the next statement.

After running the script this is what the admin console shows:

Nice!!!!

The script can be downloaded from here

The setup (and source) can be downloaded from codeplex.

I hope BizTalk developers and administrators will find this a useful addition to their toolbox.

In the coming weeks we will provide more information on usage and show some tips.

Every time Microsoft releases a new version of BizTalk we are all very disappointed that they did not make the expression window resizable or at least bigger.

There are rumors that this is done to discourage developers to write a lot of code in those windows and move to external assemblies with helper classes instead.

Although I agree with that I still think it would be very nice to have a bigger window occasionally.

Like the “Orchestration Variable Retriever Functoid” this was on my “experimental things to do list” for a long time. I never had or took the chance to try it until BizTalk king Stephen W. Thomas announced his competition for the best BizTalk tip or trick.

Of course I want to join this competition so I started coding. Now that it is finished I must admit it has become quite a hack but it seems to work .

Anyway the “ExpressionMaximizer” will be my entry for the competition.

A quick walkthrough:

I have an orchestration with an expression shape containing a lot of code:

I double click the expression shape to open it (in normal mode):

With expression window still open I press CTRL+SHIFT+ALT+M (nice key combination ) and ……:

I have a big expression window where I can type many long lines of code!!!!

Everything is back to normal when you close the window and open it again.

Note that you first have to open the expression shape before pressing the key combination.

Want to try it yourself?
(description below is based on Visual Studio 2008)

- Download this zip file and extract it somewhere.
- Click ‘Tools’ –> ‘External Tools…’
- Press the ‘Add’ button
- Type a title, e.g. ‘Expression Window Maximizer’
- Fill in the command text box by browsing to the extracted ‘ExpressionMaximizer.exe’

- Press the ‘OK’ button
- Select ‘Tools’ –> ‘Customize…’
- Press the ‘Keyboard…’ button
- In the ‘Show commands containing:’ text box type ‘Tools.External’
- Select the correct ‘Tools.ExternalCommandX’ from the list. (You need to find out the correct entry by counting the external tools in the Tools menu).
- Click in the text box ‘Press shortcut keys:’ to set the focus to it.
- Press CTRL+ALT+SHIFT+M
- Click the ‘Assign’ button.

- Press the ‘Ok’ button.
- Press the ‘Close’ button.

I tried this on ‘Windows Server 2008 R2/VS2008′ and ‘Windows Server 2003 R2/VS2005’ without problems but I still take no responsibility for malformed windows or other disasters After all it is a big hack!

If you’re interested you can find the (VS2008) source code here.

Every now and then you need to do some BizTalk management things in code. This is where the classes come in very handy.

Last week I wrote a small sample to show and explain the use of the classes to a co-BizTalker. He was excited about this but told me it would be a good thing if we provide some more sample code. I’m sure we (me and the great people I work with on this project) will come up with a lot more information when we release the final version. For now I will only post this small sample.

It shows that a lot of “BizTalk management work” can be done using only a couple lines of code. Also this is done in a uniform way (using a single API).

This is what the sample does:

• connect to a BizTalk group (management database).
• create an application.
• add a BizTalk assembly (resource) to the application.
• import a binding file.
• creates and exports an MSI file from the new application.
• Starts the application.
• Resets the BizTalk Host.

Here is the code:

As you can see below I only need 8 lines of code to accomplish it. I don’t know how much code this would take when it was done using the “regular” API’s but I’m very sure many more lines are needed.

If you like this please download the beta from codeplex and start using the classes.

The PowerShell Provider for BizTalk lets you browse BizTalk as a file system. The primary goal for writing this provider is to aid me in my day to day BizTalk development work. With this in mind the first thing I wanted to be able to do is stop, start and restart host instances in an easy manner. I also wanted to replace my host manager tool with something with more flexibility. You can read more on host instances and PowerShell here.

Download link can be found here

Some features:

- Browseable BizTalk Adminstration Console like hierarchy and structure of artifacts. Read more here

- Tab completion saves you from a lot of typing

- Custom cmdlets aimed at BizTalk.

Installation instructions:

prerequisites: PowerShell 1.0 installed, BizTalk Server 2006 R2 (haven’t tried R1 yet) installed and configured.

steps:

1. run ‘PowerShell.BizTalk.msi’ and follow instructions.

2. Start a new PowerShell shell.

3. Type the command:

Add-PSSnapin PowerShell.BizTalk

4. Optionally verify that the snap-in is loaded by executing the command:

Get-PSSnapin

You should see the snap-in in the list of loaded snap-ins (see example below).

5. Add a connection to the local BizTalk installation by executing the command:

New-PSDrive LocalBTS BizTalk LocalBTS: -scope global -server <ServerName> -database <DatabaseName>

Replace <ServerName> and <DatabaseName> with the name of the server and database with the name of the management database.

For example:  New-PSDrive LocalBTS BizTalk LocalBTS: -scope global -server BizTalk01 -database BizTalkMgmtDb

This will create a new PowerShell drive object pointing to the BizTalk management databases.

Automatically load the snap-in:

Step 3,4 & 5 need to be executed every time you start a new PowerShell and want to use the BizTalk provider. To prevent you from typing the commands every time you can of course create a personal profile script. This will be loaded every time a new PowerShell shell is started. In order to do this:

1. Create a new folder in your ‘My Documents’ folder. Name this folder ‘WindowsPowerShell’.

2. Create a new text file in the folder created in step 1. Name the file ‘Microsoft.PowerShell_profile.ps1′.

3. Set the contents of the text file like below and save it.

When opening a new shell the snap-in should be loaded automatically.

Supported artifacts:

Compared to BizTalk Adminstration Console this release of the provider has a limited set of artifacts that are browseable. Also each artifact has less properties than you’re used to in the console.

Limitations in this version:

- The provider makes heavily use of ExplorerOM model. As far as I know this is only supported on 32 bit platforms. So be aware when using the provider on a 64 bit platform.

- The provider does not (yet) (fully) support connections to remote BizTalk installations. Some things like e.g. browse applications work, while other browse host instances will not work.

- Make sure you have enough rights (BizTalk administrator) before using the provider. It does not check role membership or authorizations before executing code so insufficient rights may lead to nasty errors.

- Many other……

Please send me an e-mail or post a comment if you have questions, remarks, bugs, etc…

In BizTalk Server 2009 it looks like Microsoft has continued to move functionality from the Health and Activity (HAT) tool to the BizTalk Administration Console (MMC).

When we went from BTS2K4 to BTS2k6 we saw that some of the tasks we did with HAT (and other tools) on 2k4 now could be done with MMC on 2k6.

The biggest improvement for me personally was the inclusion of the subscription viewer function in the MMC. I still have nightmares about the user interface of the 2k4 subscription viewer tool .

In BizTalk Server 2009 Microsoft took it a step further and removed the HAT tool. This means the remaining functionality is now also included in MMC.

To be more precise the HAT is not completely removed you only don’t need to start it as a separate tool anymore. If you for example use things like ‘Message flow’ or the ‘Orchestration debugger’ you’ll still get a HAT style window. Also the task manager shows a process called ‘BTSHatApp.exe’ which I think I saw somewhere before . Of course I also couldn’t resist typing ‘BTSHatApp.exe’ from the start prompt, but that results in the following error message:

Anyway I think it is a good thing because we now really have one tool (or at least one entrance point) to do everything. I also never liked the HAT user interface very much.

There are (or were) basically three functions/queries that I use in HAT:

• Most recent 100 service instances
• Messages sent in the past day
• Messages received in the past day

The query expression pane in the 2k9 MMC now has values for ‘Tracked Message Events’ and ‘Tracked Service Instances’. This will allow me to do the same thing in MMC that I previously had to do in HAT.

Screen shot 1 shows the ‘Most recent 100 service instances’ in the 2k9 way. Screen shot 2 shows the ‘Messages received in the past day’.

Screen shot 1: Most recent 100 service instances.

Screen shot 2: Most recent 100 send messages.

I would be great if BizTalk developers or administrators:

• just could walk through the biztalk artifacts in the same way we do with file folders.
• have a (rich) set of powershell cmdlets aimed at BizTalk.

In other words we need a: Powershell provider for BizTalk. Searching the internet resulted in nothing. I found one initiative but that did not seem to have started and there were also no downloadable bits.

Anyway I decided to code a BizTalk provider myself. I have copied the artifact hierarchy tree used in the BizTalk Administration Console as much as possible (see screenshots below). The provider also supports tab completion which makes it very easy to navigate through the BizTalk artifacts.

The screenshot below contains an example of a BizTalk cmdlet to stop a specific host.

Although I’ve been very, very busy with this in the last couple of weeks there is still a lot of work to be done. So why am I telling you about this when there are no downloadable bits yet. There are two reasons:

• I hope there are BizTalkers out there that use Powershell and want to test my provider eventually. (If so drop a comment or e-mail).
• I want to make a list of first release cmdlets that should be included. (Suggestions? Let me know!)

Although it was written for BizTalk Server 2004 (.Net v1.1) it also works for BizTalk Server 2006 R1 and R2.

Apparently some people still use it because now and than I receive questions from people asking where it can be downloaded. Because I am not sure if it is still available from the old location, I’ll put it on my skydrive here.

I’m currently working on a new version of the tool. I hope to have it finished soon.