In an earlier post I posted a PowerShell script that automatically deploys BizTalk applications:
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.
In my scripts I regularly check the status of host instances on a BizTalk system. For example, if I want to start a host instance in a script, I first check if it isn’t in started state already.
To show how you can check the status of a host instance, I created a small script. The scripts returns the state of all host instances on all servers in the array servers:
$servers = ("BizTalk2010n1", "BizTalk2010n2")
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.
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.
"More" Can Be Dangerous - There is a Better Alternative
When you pipe output to more.com, the output is displayed page by page.
You will not get any results for a long time, and your CPU load increases.
Windows Server 2008 R2 comes with the GroupPolicy PowerShell module.
You might have to install that feature first before you can use it – run these lines with full Administrator privileges:
Once installed, the GroupPolicy module provides you with a lot of new cmdlets to manage group policy objects.
When launching a PowerShell script from outside PowerShell, it is a good idea to return an Exit Code to the caller so the caller will know if the script ran successfully.
You can send back an Exit Code by using the statement:
XX would be a numeric value
The folowing is an example:
One of my clients asked for an easier way to stop and start BizTalk applications. I created a PowerShell script with a Windows forms GUI. You can use it to stop or start all host instances and or IIS on a server in a BizTalk group.
Following my last two posts, I will now demonstrate how we can create a script that allows us to automatically change user credentials of a BizTalk Host Instance.
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