BizTalk Administrator's Checklist Compiled by Microsoft BizTalk Support

Introduction

This checklist can be used as a guide to maintain a healthy BizTalk environment. It includes proactive tasks that should be done on a weekly basis and also includes To-Do items after BizTalk has been configured.

This list was originally created by the Microsoft BizTalk support team. Feel free to add to it.

Daily Action Items

Use Group Hub in BizTalk Administration to check for suspended and dehydrated instances. This will also give you a chance to investigate why these items are suspended/dehydrated.

Do not let suspended instances accumulate. They should be handled promptly by either being terminated or successfully resubmitted. If these items reach in the thousands, performance can be impacted. MsgBox Viewer also breaks down the suspended instances by host.

Confirm the BizTalk SQL Agent jobs are executing as they should. Pay special attention to the Backup BizTalk Server job and make sure it runs successfully. In case of a disaster recovery, you may need these database backups. For a description of the SQL Server Agent jobs, refer to the following KB:

919776 Description of the SQL Server Agent jobs in BizTalk Server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;919776

Weekly Action Items

Check the BizTalk database sizes and the sizes of all the tables. A good example is the BizTalkDTADb database. The entire database may be a really good size but if a table contains millions of rows (e.g. the dta_DebugTrace), then maintenance needs to be done. Another good example is the BizTalkMsgBoxDb database. The entire database may be a really good size but if one of the TrackingData_x_x tables has 500,000 rows, then there may be an issue.

If a table gets out of hand, it needs to be investigated. In the dta_DebugTrace table example, if you don't need or use the Orchestration tracking events, the Terminator tool can be used to truncate this data. In the TrackingData_x_x table example, this data should be moved from the BizTalkMsgBoxDb database by the Tracking Host. If you don't need or use this data, the Terminator tool can also be used.

The BizTalk MsgBox Viewer tool is very handy for this task. Run it on a weekly basis and compare the output with the previous week.

BizTalk MsgBoxViewer
http://blogs.technet.com/jpierauc/pages/msgboxviewer.aspx

PAL
http://pal.codeplex.com/

Terminator
http://www.microsoft.com/download/en/details.aspx?amp;displaylang=en&id=2846

Other Action Items

1.	Determine what's normal/expected in your environment. Some examples: HostA normally consumes <5% CPU and Process Memory Usage typically stays around 300 MB. It spikes to 450 MB when processing a batch of messages but goes back down to 300 MB when the instances have completed. HostB normally processes 2000 messages per second. Performance Monitor is really good for this task. Collect PerfMon data during peak times and during non-peak times. The goal is to build a baseline so you know what's normal. Performance Counters http://msdn.microsoft.com/en-us/library/aa578394(BTS.10).aspx System performance can be affected widely by throttling. Pay special attention to the throttling Performance Monitor counters. Analyze the cause of any throttling and determine whether a configuration change is needed to improve the performance: How BizTalk Server Implements Host Throttling http://msdn.microsoft.com/en-us/library/aa559893(BTS.10).aspx
2.	Know what is running in each host. For example: HostA runs an orchestration that processes maps. It's the only item running in this host. HostB processes all send ports. HostC is dedicated to all send ports using the SQL Adapter. Consider creating a chart of the artifacts running in each host. This will also help determine if too many items are running in a host or if a host is being underutilized. The BizTalk Server Documenter Tool can help generate a nice help file describing the system: http://www.codeplex.com/BizTalkDocumenter.
3.	Backup the master secret. Know where it is and know the password. Make sure ALL BizTalk Administrators know this. How to Back Up the Master Secret http://msdn.microsoft.com/en-us/library/aa559192(BTS.10).aspx
4.	Get a screen shot of the MSDTC settings. A service pack may change these so know what you've configured on all the BizTalk servers, the SSO server(s) and the SQL server(s). How to Enable MSDTC on the BizTalk Server http://msdn.microsoft.com/en-us/library/dd328181(CS.90).aspx
5.	Consider using SCOM Management Pack for monitoring important operation events and getting real-time alerts and notification. Microsoft BizTalk Server Management Pack for System Center Operations Manager 2007 http://www.microsoft.com/downloads/details.aspx?FamilyId=389FCB89-F4CF-46D7-BC6E-57830D234F91&displaylang=en&displaylang=en
6.	Insist on performing UAT and performance testing for any sizable deployment so there will be no surprises after deployment. Testing Tasks for BizTalk Application Deployment http://msdn.microsoft.com/en-us/library/aa562072(BTS.10).aspx BizTalk 2009 – End to end performance testing http://channel9.msdn.com/posts/johanlindfors/BizTalk-2009--End-to-end-performance-testing/ http://channel9.msdn.com/posts/johanlindfors/BizTalk-2009-End-to-end-performance-testing-22/
7.	Create a good framework to maintain the stability of your environment. The creation of a good framework will make it easier for hired consultants to know your environment including making it easier when performing health checks. Blog post for tips regarding a framework http://biztalkadmin.com/biztalk-framework/
8.	Create a disaster recovery plan, this is vital to have in hand when and if a serious issue happens to your environment. Technet WIKI article regarding Disaster recovery http://social.technet.microsoft.com/wiki/contents/articles/5363.aspx
9.	Periodically make a backup of all bindings for a BizTalk environment by exporting them from the BizTalk Administration console. Always do this before manually applying any binding changes to an application.