I regularly install upgrades of BizTalk applications for clients. Before I delete the BizTalk application that is being upgraded I export the MSI and binding file. If needed, you can easily restore the old application. Also it is normally easier to edit (if needed) the old binding file then the one supplied by a developer. Besides being able to reinstall the old BizTalk application in case of upgrades, I am definitely not looking forward to the day that I am called in to completely reinstall a live production server for whatever reason. Just try and find all the sources that were installed in the production environment! Not only do you need the correct MSI but also an up-to-date binding file. To overcome this problem I created a backup-script for BizTalk applications for a client of mine. Today they gave me the OK to share scripts I wrote for them with the community. So here’s the first one.
From the Group Hub in BizTalk 2010 you can have a look at all existing subscriptions. However to have a look at the expression which is related to the instance, you have to open the Subscription Details screen and go to the Expression tab page.
If you need to know all the expressions, you can use the query below:
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.
The Microsoft Operations Framework 4.0 (MOF) consists of integrated Best Practices, Principles, and Activities that provide comprehensive guidelines for achieving reliability for IT solutions and services. MOF provides question-based guidance that allows us to determine what is needed for our organization now, as well as activities that will keep our IT organization running efficiently and effectively in the future.
The guidance in the Microsoft Operations Framework encompasses all of the activities and processes involved in managing an IT services; its conception, development, operation, maintenance, and—ultimately—its retirement.
Dear BizTalk developers/architects,
We all love BizTalk. More in general, we love integrating information systems! We do our job from different perspectives, but in the end our goal is the same: making happy customers with integrating their information systems with internal or external parties.
Before my current assignment I was a BizTalk developer too. Since no BizTalk developing project came along, I decided to accept an assignment as a BizTalk administrator. My main motivation was, besides short travel times, that I was interested in having a look at how all these BizTalk artifacts would do it in a live situation.
In a BizTalk group with multiple BizTalk servers it is important to keep the servers as much alike as possible. Differences between servers can lead to unpredictable results. To reduce the change on incidents and problems administrators should regularly check for differences. I will elaborate further on which checks an administrator could do in future blog post, but for now I want to focus on checking the patch levels.
A new blog site on BizTalk Administration is born. Why? BizTalk administrators have a strong urge to share their knowledge with each other. The BizTalk community is strong and shares an incredible amount of knowledge through blogs, wiki's, presentations and other channels. Yet the focus is strong on development and less on administration. Development is cool and very popular. Is administration dull and less appealing?
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?