A while ago I created a post on using the BizTalk Deployment Framework for automated build and deployment. Since then I have worked this out to be more easy and maintainable using PowerShell, which I will show in this post. BizTalk Deployment Framework is one of those pearls for BizTalk developers, allowing complex BizTalk solutions to be deployed easily, having all our artifacts and dependencies together in one MSI. The code with this post can be downloaded from here.
Using PowerShell we will make scripts which will handle all steps of the build and deployment process for us. This will make sure our applications are always deployed in the correct order, using the right versions, and with minimal effort. We have some general helper functions, which will help us clear log files, wait for user input, iterate through directories, etc. We assume you have are using some of the BTDF best practices for these scripts, where it comes to naming conventions and folder structure. Of course, in case anything differs in your environment, you can easily adjust the scripts to meet your requirements.
In my previous post I showed how I automated creating hosts and host instances. In this post I will continue on that, but then by creating the users and groups according to the BizTalk best practices. They are created on the local computer, I will see if I can adjust the script to create them in an AD at a later time. As with my last post, I have commented my code thoroughly, so it should pretty much explain itself.
I regularly have to do new deployments of BizTalk environments. Off course I try to follow the best practices as best as I can, which means I always try to have a seperate send, receive, orchestration and tracking host. Because I don’t want to spend to much time creating these, I decided to make a PowerShell script to do this for me. I used the BizTalk PowerShell Provider to do so. This blogpost will show the code I used. I commented my code, so it should be pretty self-explanatory.
Today I ran into a problem while trying to use the BizTalk PowerShell Provider on a Windows Server R2 installation. I allready knew I would have to use the 32 bit version when working with the provider, however on starting up the console I received the following message:
Add-PSSnapin : Cannot load Windows PowerShell snap-in BizTalkFactory.Powershell.Extensions because of the following err or: Could not load file or assembly ‘file:///C:Program Files (x86)BizTalkFactory PowerShell ProviderBizTalkFactory.P owerShell.Extensions.dll’ or one of its dependencies. This assembly is built by a runtime newer than the currently load ed runtime and cannot be loaded. At C:UsersAdministratorDocumentsWindowsPowerShellprofile.ps1:5 char:13 + Add-PSSnapin <<<< BizTalkFactory.Powershell.Extensions + CategoryInfo : InvalidArgument: (BizTalkFactory.Powershell.Extensions:String) [Add-PSSnapin], PSSnapInE xception + FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
In the documentation for the provider it states it targets .NET 2.0, and that the configuration files should be changed to the following:
<supportedRuntime version="v4.0.30319" />
This did however not solve my problem. After further investigation I found out you actually need following in the PowerShell configuration file:
<supportedRuntime version="v4.0.30319" />
<supportedRuntime version="v2.0.50727" />
On a x64 system this file can be found here:
If the file does not yet exist, simply create it.
This post is deprecated, check this new post for improved scripts.
At one of our customers, I set up a BizTalk environment with several applications, like applications for warehouse, subsidiary and customer interfaces. Some of these applications also use 2 separate servers, one in the internal network, and one in the DMZ network. These servers have completely different ports; for example. the DMZ server has ports connected to the outside world, which aren’t present on the internal server. Also, some applications are dependent on others, so deploying and undeploying has to be done in a specific order. To make this easy, I have set up a fully automatic BizTalk build and deployment setup. This is done by using PowerShell in combination with the BizTalk Deployment Framework. For my own reference, as well as for helping others set up an automated BizTalk deployment, I wrote this document. A basic understanding of BizTalk and PowerShell is needed to work with these examples. Special thanks go out to the blog of Randy Paulo.