In an earlier post I posted a PowerShell script that automatically deploys BizTalk applications:

http://www.biztalkadminsblogging.com/index.php/item/44-installation-script

This version of the script stops when a older version of a BizTalk application that you are installing is detected. I had some discussions with other BizTalk admins and most of them wanted a ‘overwrite’ feature. I added this to a newer version of the script.

Deploy Scripts

Based on previous article , we have developed a set of scripts using the PowerShell Provider for BizTalk version 1.2.0.4 and Visual Basic for Applications (VBA).

This set of scripts performs the tasks of installation and upgrade that we need in our environment, as well as other necessary tasks in our distributions such as the creation of folders from Backup of the Assembly you are updating, to preserve the possibility of backtracking( if necessary) and the import of bindings.

BizTalk Deployments

All of us that somehow we are involved in the deployment and configuration of Microsoft BizTalk solutions know or have read about the existence of software packages, either owner or open source with aim of this cumbersome task. The reality is that there is not a unique solution to these issues, and in many cases we decided to implement our own strategies, based on the environment that we manage.

For this reason I would like to contribute to the community of BizTalk administrators/developers with this set of scripts developed in PowerShell and Visual Basic for Applications (VBA), which enable deployments on a large scale in a few minutes and maintaining guidelines imposed by the developments that we do.

In this series of articles I will explain the different steps that I have made to achieve a comfortable platform for deployment of BizTalk applications. It is neither more advanced nor more convenient method. It is simply another method.

Note: You can find a new version here

In my first series of blog posts I blogged about useful (sample) PowerShell scripts, working towards a simple BizTalk application deployment script. This script is now finished. You can download the script and the example xml-files below or here. The script does the following:
• Import the msi
• Import the binding file
• Install the msi
• Create directories
• Create event sources
• Restart host instances

Recently after I deploy a new version of one BizTalk Application in production environment, in order to provide a new service and after having validated all the normal steps of an installation:

• Check the correctly deployed (in BizTalk Management Console and in the Global Assembly Cache (GAC))
• Correctly Application Binding
• Restart Host instances

I did a little more work on the deployment script. Before starting the installation I want to know if the BizTalk Servers and SQL Server are running. It is a little difficult to install software on a server you cannot connect to!
I created three function. The first function I created is the function that does the actual work. It checks if a server is online:

I have been working on the PowerShell deployment script yesterday night. The script handles files based on a file location and filename. When working with files we need error-handling. I can, for example, tell the script that the MSI needed for installation is C:\Deploy_script\My_BizTalk_application.msi without actually placing it there. Typos also are common errors which have to be handled.

Steef-Jan wrote an excellent blog post introducing this blog. So I guess that means that the only thing left for me to do is just start blogging and hopefully produce some useful information (but I’ll let you be the judge of that).
One of the responsibilities of a BizTalk administrator is deploying BizTalk applications. This can be quite a hassle. You have to import a msi, import a binding file and install the msi on one or more servers. Depending on the solution additional steps have to be performed like creating file locations, event sources, etc. Performing to many manual steps is error-prone and not to forget plain boring. Luckily we are in the business of automating, things so why not automate are own work?