In the last two chapters we went through the main tools and procedures that we can use to be up to date about how our environments are behaving. A system administrator is in a better position to react against a potential outage when has all the information possible about the issue as soon as it happens. But yet having all the information at hand, we will still have to separate the wheat from the chaff, and find the root cause of the problem before being able to come up with the right fix.

When you look at Microsoft’s documentation about restoring your BizTalk databases they always talk about restoring your databases by using log shipping. Most of my client have various reasons (unfamiliarity with the technique, requires extra servers and licenses, etc.) for not wanting to use log shipping. Alternatively you can manually restore the BizTalk databases.

My concern with manually restoring the databases is that it can take a lot of time and is prone to errors. By default the Backup BizTalk Server job creates a full backup once a day and a log backup every 15 minutes. Worst case scenario you will have to restore one full backup and (24 * 4) 96 logs times at least 5 databases. That means you will have to do 485 restore actions to restore the BizTalk databases to the latest state!

For quite some time now Andres Del Rio Benito, Howard Edidin and Steef-Jan Wiggers have been working on a book called Microsoft BizTalk 2010 Administration Essentials. This book is about (you guessed it) BizTalk administration. It talks about all relevant topics that every BizTalk admin should be concerned with. After some rounds of technical reviews done by Ben Cline, Sandro Pereira and myself the book is now ready to be published.

I am very happy to announce that the writers choose BizTalkAdminsBlogging.com as a platform to publish their book. We will be releasing a new chapter every two or three weeks.

Some major technical updates were done on the blog. These updates were purely technical so no new functionality has been added. During testing we did not find any problems, but if you find one, please let us know. You can use the contact page to contact us, or contact us on Twitter (@bizadmblogging)

One of the SQL jobs created during the configuration of BizTalk is the DTA purge and archive job. This job purges tracking data from the tracking database (BizTalkDTADb). By default it also archives this data to disk. To do this the job calls the stored procedure dtasp_BackupAndPurgeTrackingDatabase.

However, most of my customers do not use the archived data and just remove it periodically.

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).

Microsoft has released the beta of BizTalk Server 2013. This means that the initial name BizTalk 2010 R2 has been changed. You can download the beta here:

http://www.microsoft.com/en-us/download/details.aspx?id=35553

This new release contains some new features:

When the BizTalk Best Practice Analyzer starts it tries to connect to the internet to get an update of the latest best practices. However, quite often servers do not have a direct internet connection. This will result in the following error:

 
Within time this will leave you with a BizTalk Best Practice Analyzer that uses outdated best practices.

One of the responsibilities of a BizTalk admin is to ensure that BizTalk performs according to business requirements. One of the aspects that can impact performance is hyper-threading. Hyper-threading is a technology that makes the server appear to have more processor cores than it actually has. It seems logical that more cores will give the server a better performance. However, it is not as simple as it seems. Some applications suffer from performance loss when hyper-threading is enabled. BizTalk Server is among the applications which encounter performance loss from hyper-threading. The Microsoft document “General Guidelines for Improving Operating System Performance” states that the overall performance will decrease when hyper-threading is enabled. This is because of the self-tuning algorithms within BizTalk (for more information see: http://msdn.microsoft.com/en-us/library/ee377075.aspx).

System Center Operations Manager is one of the popular monitoring tools for monitoring IT infrastructures (including BizTalk Server). Since there are so many IT-organizations using this product I wanted to give you a heads-up that the mainstream support for SCOM 2007 ends on the 10th of July 2012. If you have SCOM 2007 R2 your good for another two years till the 8th of July 2014.

For more information see:

http://technet.microsoft.com/en-us/systemcenter/bb497976