I have an interesting question in my blog yesterday: “CU is a collection of hotfixes and we should only install if our system experience problems on the list of the fixes. If we don’t have any problems, should we still install the latest CUs?”
Indeed, CU is a collection of hotfixes for one specific version of the product but I disagree with the part that “you should only install if our system experience problems…”
In my option, you always should install the latest CU and why?
Yesterday I was performing a Health Check at a client. One of the checks is looking at the database autogrowth settings. In the operations guide Microsoft states the following about the BizTalk database autogrowth settings:
Pre-allocate space for BizTalk Server databases and define auto-growth settings for BizTalk Server databases to a fixed value instead of a percentage value
BizTalk uses multiple databases. Think about the Configuration database (BizTalkMgmtDb), the MessageBox database (BizTalkMsgboxDb), the Tracking database (BizTalkDTADb) etc. etc. Beside these databases, your system might also have its own ‘custom’ database(s). Together these databases define the state of your application or system.
All these databases should be backed up by the Backup BizTalk Server job on SQL Server. This job makes both Full and Log backups. Normally a Full backup is made every 24 hours and a Log backup every 15 minutes.
In this article I’ll describe how you can force the Backup job to make a Full backup, which might be handy when you are preparing an upgrade of your application or system. Further I’ll describe how you can monitor the progress of the Backup job and how you can see where the backups are written to.
During Health Checks I check the file transfer speed between the BizTalk servers and the SQL server. To do that, I copy a 100 MB file from the BizTalk servers to the SQL server. Even though this is not an exact science, it gives a good indication about the network and disk speed.
I normally do not carry a 100 MB test file with me. Luckily it is easy enough to create one by using FSUTIL:
FSUTIL FILE CREATENEW 100MBTest.file 104857600
My first book written by myself is ready to be published. At the end of this month the BizTalk Server 2010 Cookbook will be available throughout the world. It took a year to complete this book filled with over 50 recipes. Recipes that even BizTalk administrators will appreciate as at least two or three chapters are targetted towards them. They will recipes on monitoring BizTalk, using PAL, the BizTalk BenchMark Wizard, BizTalk MessageBoxViewer, BizTalk Deployment Framework, and configuring the vital BizTalk components like ESSO and MSDTC.
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.
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.
This article describes the steps which must be taken to perform a migration of a BizTalk application. Since each migration has its own specific matters, the attached document can be used as a template and can be modified for each specific migration.
If you give the host instance where your file adapter is running under modify rights on a file location that a receive port is using that port will fail to start. You will see the following error in your log:
Hello all, its time for me to do a blog post here as well. There has been so much going on that I just haven't had any time at all to do any blogging here, nor on my blog. However there is some time now and I wanted to start a discussion around, and come with my ideas when it comes to how you should install BizTalk, and why you shouldn't install it on all operating systems, even though they are supported.
