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.

All SQL Server Network Protocols are installed by SQL Server Setup, but may or may not be enabled. And you need to be aware that this protocols can have impact in your BizTalk Environment, for example:

• Under certain stress conditions (such as clients accessing SQL Server from the same computer), the SQL Server Shared Memory protocol may lower BizTalk Server performance.
• BizTalk Server loses connectivity with a remote SQL Server computer that houses the BizTalk Server databases and this may happen if the necessary protocols for SQL Server are not enabled.

In the third chapter we learned about System Center Operation Manager R2 (SCOM) and seen some scenario’s. SCOM is a great product for monitoring your entire enterprise infrastructure. Yet it may be overkill to use SCOM for just monitoring a BizTalk group itself. Or when you do not intend to use an enterprise monitoring system like SCOM for monitoring BizTalk you may have look for alternatives.  

The goal in this chapter is to focus on third party monitoring tools and products available in market and through the community (CodePlex).

You can download the pdf below or by clicking here.

“List of BizTalk Errors and Warnings, Causes and Solutions” is a Microsoft TechNet Wiki article that is intended to be a knowledge base or complete list of possible BizTalk errors and warnings with their causes and solutions for all stages/components.: different stages of development, deployment, adapters, runtime, setup and configuration…

This list can prove to be very useful for BizTalk developers but also to administrators! Because many errors described are associated to the lifecycle installation and configuration of the product as well deployment and runtime issues.

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!