Some time ago I wrote a blogpost on how to enforce your tracking strategy:

http://www.biztalkadminsblogging.com/index.php/item/84-enforce-your-tracking-strategy-with-a-powershell-script

I did this because one of my customers had a tracking strategy stating that by default all tracking in the production environment should be disabled. The problem was that it was difficult to enforce this strategy. New applications were put into production with tracking enabled or tracking was enabled for troubleshooting reasons never to be disabled again. The only method they had to enforce this strategy was to manually check the tracking settings. Since they have a lot of artifacts this took about an hour of clicking (and was extremely boring).

The is a new version of this script. You can find it here:

http://www.biztalkadminsblogging.com/index.php/item/99-new-version-enforce-your-tracking-strategy-with-a-powershell-script

One of my customers has a tracking strategy stating that by default all tracking in the production environment should be disabled. The problem is that it is difficult to enforce this strategy. New applications were put into production with tracking enabled or tracking was enabled for troubleshooting reasons never to be disabled again. The only method they had to enforce this strategy was to manually check the tracking settings. Since they have a lot of artifact this took about an hour of clicking (and was extremely boring).

I often perform BizTalk health checks for my customers. One of the checks I do is to see if they are using software that is still supported by Microsoft. I do not think it is per definition wrong to use software that is out of support. It is however a risk that they should know about, so that they can accept the risk or resolve it.

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

The Backup BizTalk Server job uses the MarkLog table to write marks. These marks are actually timestamps which are used by the job to determine until what time a (Log) backup must be made. Unfortunately BizTalk has no out-of-the-box possibilities to clean up that table.

Luckily Microsoft provides Terminator to clean up this table and do a lot of other things. In this article I’ll describe the capabilities from Terminator in short and more detailed on how you should use it to clean up the MarkLog table.

I regularly advise my clients about the latest service packs and cumulative update packages. Since all my clients are running different versions of BizTalk Server I often have to look this information up. Sandro Pereira experiences the same problem, so he created an overview of all the available service packs and cumulative update packages on his blog:

http://sandroaspbiztalkblog.wordpress.com/2011/11/22/biztalk-server-list-of-service-packs-and-cumulative-updates-available/

Something to keep in your bookmarks!

Besides your BizTalk databases your SQL Servers also have the following system databases:

• master - contains all system-level information for a SQL Server system
• model - template for creating new databases
• msdb - used by SQL Server Agent for scheduling alerts and jobs
• tempdb - used for amongst others temporary user objects

Since most of these databases are relatively static, they don't need to be in the Backup BizTalk Server job, but they do need to be in a backup. Such a backup can be made with a Maintenance plan. In this article I show you how to create such a Maintenance Plan in the most easiest way, with the Maintenance Plan Wizard.

A few days ago I wrote a post on how to automatically remove old backup files for your BizTalk databases. Every system administrators also has to deal with other types of old files, for example log files. So I was planning to write a post on this topic with a sample PowerShell script. It just so happens that Tord Glad Nordahl already wrote a script that does exactly that. Tord, like we say in dutch, mowed the grass away right from under my feet. You can find his script here.

First of all, keep this in mind: "If for any reason your BizTalk Environment has to be restored, or there is a massive change that messed up your SSO and you do not have a backup of the Master Secret Key you will have a problem."

So why this warning?

At my company we are running over 10 BizTalk development and test servers. On those servers I enabled the SQL Server BizTalk backup job. I do not however want to manually delete old backups of BizTalk databases for all those servers. I want those old backups deleted automatically. This will prevent the database files from growing indefinitely (or till your disk is full…). Also, on my production servers I do not want old backups files to take up all free disk space and cause incidents. To automatically remove old backup files I use a maintenance plan. This blog post shows you how to create this maintenance plan.