Introduction

As described on the Microsoft BizTalk Server Overview page, “BizTalk Server is Microsoft’s Integration and connectivity server solution.”  BizTalk Server provides a wide range of features designed to more easily connect disparate systems both inside and across organizations.  Because BizTalk Server is able to accommodate a vast array of integration and connectivity scenarios, and because the resultant solution(s) are very often deemed “mission critical”, it is of the utmost importance that sufficient time and resources are devoted to planning the installation and deployment of your BizTalk Server solution. This document provides IT Professionals and Developers with advanced information for installing and deploying BizTalk Server including the following information:

1. Recommendations for initial planning of the BizTalk Server solution including determining which edition of BizTalk Server should be installed.
2. Guidance for implementing high availability and/or disaster recovery.
3. General sizing guidelines and considerations for determining the number of BizTalk Server computers and SQL Server instances that should be deployed in a BizTalk Server environment.
4. Best practices for configuring the SQL Server instance(s) that will house the BizTalk Server databases.
5. Considerations for deploying BizTalk Server into a Hyper-V environment.

Who Should Read This Guide

The following users should read this guide:

• IT Professionals are provided with recommendations for installing, sizing, deploying, maintaining, and scaling of a BizTalk Server environment and how to choose the edition of BizTalk Server and SQL Server that is best suited for their BizTalk Server solution.
• Developers are provided with recommendations for developing, testing, and deploying a BizTalk Server solution into production.

This guide assumes that the reader is familiar with and understands the core concepts of BizTalk Server (version 2004 or later).

Document Structure

This document contains the following high level sections:

• Initial Planning / determining which edition of BizTalk Server is appropriate for meeting your goals
• Create a timeline for development, testing and deployment of the solution
• Deploying and configuring the SQL Server databases used for your BizTalk Server solution
• Developing your BizTalk Server solution
• Testing your BizTalk Server solution
• Deploying your BizTalk Server solution
• Considerations for deploying BizTalk Server into a Hyper-V environment
• Maintaining your BizTalk Server solution
• Scaling your BizTalk Server solution

Initial Planning / determining which edition of BizTalk Server is appropriate for meeting your goals

The following tasks should be completed to determine with edition of BizTalk Server is appropriate for meeting your business requirements. This section is divided into the following sub-sections:

• Determine the business goals for the BizTalk Server solution – Establish how you can use BizTalk Server to accommodate your business requirements.
• Create an architecture diagram – Provide a graphical summary of message flows through the solution including all components and features required to meet the business goals of the solution.
• Determine high availability and disaster recovery requirements – Clearly define the high availability and disaster recovery requirements of the BizTalk Server solution.
• Create a summary hardware diagram – A summary hardware diagram describes the physical hardware that will be required for the BizTalk Server solution.
• Determine which edition of BizTalk Server is appropriate for meeting your goals – BizTalk Server Enterprise edition provides the enterprise level functionality required for fault tolerance and scaling.
• Establish sizing guidelines – Determine the hardware requirements necessary to meet the message throughput goals, high availability and disaster recovery requirements of the BizTalk Server solution.

Determine the business goals of the BizTalk Server solution

Have all stakeholders agree upon and document a broad mission statement and detailed goals for the BizTalk solution.  Business goals for a BizTalk Server solution can range from something as simple as automating invoice processing between one or more trading partners to something as complex as developing an entire online banking system. For example, the following mission statement and business goals might summarize an online banking solution that is built with BizTalk Server:

Mission Statement

Provide clients with a secure web based banking system that allows clients to access their accounts and perform banking transactions such as transferring money between accounts, paying bills, and accessing detailed account histories.

Business Requirements

• Clients must be able to access their accounts 24 X 7.
• Client account balances must be accurately represented within no more than 12 hours since the last account activity.
• All client transactions conducted over the internet must be encrypted.
• The BizTalk solution must be designed to handle peak loads, for example client activity will likely be higher in the early morning, during the middle of the day (around lunch time), and at the end of the day (after work hours). Client activity will likely be very low in the late evenings and early morning but the system must scale to handle peak loads, not average loads.
• The BizTalk solution must easily accommodate scale up and scale out as needed to handle additional peak loads over time.
• The BizTalk solution must provide both fault tolerance and disaster recovery.
• The BizTalk solution must be sufficiently secure to prevent unauthorized access to sensitive client information both externally and internally.

  A mission statement and business requirements are invaluable for ensuring that the development, testing, and deployment of the BizTalk Server solution stay on task.

  Create an architecture diagram

  An architecture diagram should provide a graphical summary of message flows through the BizTalk Server solution including all components and features required to meet the solution goals. The architecture diagram will be critical for evaluating which edition of BizTalk Server is appropriate for meeting your goals. The architecture diagram can include (but is not limited to) the following:

  • Adapter requirements – Document all of the adapters that will be used for the BizTalk solution.
  • Accelerator requirements – Document any accelerators required by the BizTalk solution.
  • Tracking requirements – Determine business needs for document tracking.
  • Third Party software requirements – A third party software subject matter expert (SME) should be available to create a software system integration document.
  • Orchestration processing requirements – A BizTalk developer should be available to provide input regarding orchestration design and development.
  • Other BizTalk Server custom code – A BizTalk developer should be available to provide input regarding design and development or other BizTalk Server code, such as custom pipeline components, custom functoids or custom BizTalk Server adapters.
  • Other BizTalk Server feature requirements – A BizTalk Server SME should be available to make recommendations for any other BizTalk Server features that will be used, such as Mapping, Business Activity Monitoring (BAM) or Business Rules Engine (BRE).
  • Disaster Recovery and High Availability requirements – Disaster recovery should be implemented for all production BizTalk Server solutions using BizTalk Server log shipping. High availability should be implemented for any mission critical BizTalk Server solutions. See Document processing availability requirements for more information about implementing disaster recovery and high availability for BizTalk Server.

  After determining the message flow and software components used by the solution, a diagram of the solution architecture should be created as a reference point.

  

  Figure 1 – Example high level architecture diagram
   

  Create a summary hardware diagram

  A hardware diagram should provide a graphical summary of all hardware resources required for your BizTalk Server solution and should take into account the hardware necessary for achieving fault tolerance, high availability, scale up / scale out, security boundaries, virtualization, and other factors that may be relevant to the solution. A high level hardware diagram illustrates the physical infrastructure that will be required for the solution. To help determine the hardware that will be required by the solution consider the following:

  Document processing throughput requirements - What are the document processing requirements of the BizTalk Server solution today and what will the processing requirements be in the future? If you anticipate adding additional trading partners, or that your BizTalk Server application will be used to service additional clients (in a traditional client-server request-response architecture), then the Maximum Sustainable Throughput (MST) of the solution should be determined so that sufficient hardware resources are available to meet peak load requirements.  This is of particular significance if a Service Level Agreement for the BizTalk Server solution is in place. For more information about Maximum Sustainable Throughput of a BizTalk Server solution see Engine Performance Characteristics (http://go.microsoft.com/fwlink/?LinkID=155771) in the BizTalk Server documentation.

  Document tracking processing throughput requirements - The level of document tracking required by the solution can have a significant impact on the throughput of the solution. For example, some applications may require full message body tracking, others may require only message property tracking, and yet others may require no tracking. For information about Planning for Tracking see Planning for Tracking (http://go.microsoft.com/fwlink/?LinkId=186352) in the BizTalk Server 2009 Operations guide. Once the level of document tracking required by the solution is determined, the Maximum Sustainable Throughput with Tracking should also be determined. For more information about Maximum Sustainable Throughput with Tracking see Tracking Performance Characteristics (http://go.microsoft.com/fwlink/?LinkId=186346) in the BizTalk Server documentation.

  Document processing availability requirements - What are the availability requirements of the BizTalk Server solution? Does the solution require disaster recovery and / or high availability? Disaster recovery for the BizTalk Server databases can be accomplished using BizTalk log shipping.  High availability can be provided for the BizTalk Server databases, the Enterprise Single Sign-On Master Secret Server and BizTalk Server hosts with Windows Server failover clustering. High availability can also be provided for BizTalk Server Hosts by simply adding additional BizTalk Servers to a BizTalk Server group and then configuring instances of BizTalk Server hosts to run on multiple BizTalk Servers.

  Note: BizTalk host cluster support is available to provide high availability for particular BizTalk adapters for which running multiple instances of the adapter simultaneously is not feasible. Host cluster support is also available to provide high availability for running a single instance of an adapter for purposes of ordered delivery. For more information about why you would want to run certain BizTalk Server adapters in a clustered host see Considerations for Running Adapter Handlers within a Clustered Host (http://go.microsoft.com/fwlink/?LinkID=151284). For more information about BizTalk Server availability requirements see Determine High Availability and Fault Tolerance requirements below.

  Determine if virtualization is a viable platform for the BizTalk Server solution - Deployment onto a Windows Server Hyper-V virtualized environment offers many advantages but does exact a performance penalty. Running BizTalk Server on virtual machines in a Windows Server Hyper-V environment is fully supported for production and may be worth consideration for your BizTalk Server solution. For information about deploying your BizTalk Server solution into a Hyper-V environment see Considerations for deploying BizTalk Server into a Hyper-V environment.

  After determining the throughput requirements, availability requirements, and whether or not virtualization will be used for the solution, a diagram of the physical infrastructure should be created as a reference point.

    

  Figure 2 – Example high level hardware diagram

  Determine which edition of BizTalk Server is appropriate for meeting your goals

  Once the high level architecture and hardware diagrams are created then it is a fairly straightforward task to determine which edition of BizTalk Server is appropriate for your BizTalk Server environment. The table below summarizes the primary scenarios for each of the available BizTalk Server editions:

  Enterprise	Standard	Developer	Branch
  Designed for customers with enterprise level requirements for high volume, reliability, and availability. Enterprise Edition supports the following functionality: Native 64-bit execution of BizTalk Server host instances. Support for multiple BizTalk Servers in a BizTalk Server group. Support for BizTalk Server host clustering. Support for back end scale out through the creation of multiple MessageBox databases. Support for BizTalk Server database disaster recovery using BizTalk Server Log Shipping. For more information about BizTalk Server Log Shipping see Checklist: Increasing Availability with Disaster Recovery (http://go.microsoft.com/fwlink/?LinkId=187279). Unlimited processors. Unlimited virtual processors if all physical processors licensed.	Designed for businesses with moderate volume and deployment scale requirements. Note: BizTalk Standard Edition is not supported for native 64-bit execution. Standard Edition supports BizTalk Server database disaster recovery using BizTalk Server Log Shipping but does not support other enterprise-level features available with BizTalk Server Enterprise Edition such as: Support for multiple BizTalk Servers in a BizTalk Server group. Support for BizTalk Server host clustering. Support for back end scale out through the creation of multiple MessageBox databases. Unlimited processors (Maximum of 2 processors supported.) Unlimited virtual processors if all physical processors licensed. (Each processor visible to the virtual operating system must have a license.)	For development and testing purposes. BizTalk Server 2009 Evaluation Edition (EVAL) is free for evaluation purposes. BizTalk Server Developer Edition supports all of the functionality of Enterprise Edition for purposes of development and testing.	Specialty version of BizTalk Server designed for hub and spoke deployment scenarios including RFID.

  For more information about the capabilities of the various editions of BizTalk Server see Microsoft BizTalk Server Editions (http://go.microsoft.com/fwlink/?LinkID=185239) and the Microsoft BizTalk Server Pricing and Licensing FAQ (http://go.microsoft.com/fwlink/?LinkId=187281).

  Determine high availability and disaster recovery requirements

  High availability is implemented in a BizTalk Server environment by providing redundancy for key functional components. The key functional components of a BizTalk Server environment for which redundancy can be implemented include:

  • BizTalk Server Hosts – High availability for BizTalk Server hosts can be done either through clustering or through adding servers to a BizTalk Server group.
  • BizTalk Server SQL Server databases – Clustering the BizTalk Server databases through the use of Windows failover clustering provides fault tolerance for these databases. Disaster recovery for the BizTalk Server databases can be accomplished through the use of BizTalk Server log shipping.
  • Enterprise Single Sign-On Service – If the Enterprise Single Sign-On Service goes down then eventually the entire BizTalk solution will be unable to process documents.  Therefore it is critical that the Enterprise Single Sign-On Service, especially the Enterprise Single Sign-On Service Master Secret Server, be configured for high availability. 

  BizTalk Server Hosts

  Redundancy for BizTalk Server hosts can be accomplished using either of the following methods:

  1. Installing multiple BizTalk Server computers in a BizTalk Server group and configuring instances of a host to run on more than one BizTalk Server in the group.
  2. Installing multiple BizTalk Server computers in a BizTalk Server group that is also a member of a Windows Server cluster and configuring instances of a host as a Windows Server cluster resource.

  Unless your architecture requires high availability for certain adapter send or receive handlers it is recommended that redundancy for BizTalk Server hosts is accomplished by configuring instances of a host to run on more than one BizTalk Server in the group as opposed to clustering the hosts.  The reasons for this approach are:

  • Clustering BizTalk Server hosts requires the installation of the Failover Clustering feature of Windows Server 2008 or Windows Server 2008 R2.
  • When a BizTalk Server host is clustered it can only run on one BizTalk Server computer in the BizTalk Server group at any given time.  When a BizTalk Server host is not clustered then it is possible to run an instance of the host on each BizTalk Server computer in the group simultaneously, which increases throughput.

  Therefore, the only times that BizTalk Server hosts should be clustered are:

  1. To provide fault tolerance for the send or receive handlers for the following adapters:
     • MSMQ
     • FTP
     • MQSeries
     • SAP
     • POP3 Receive
  2. To accommodate BizTalk Adapters that must run in a single host to provide ordered delivery. For more information about utilizing ordered delivery see the article “Implementing FIFO processing with BizTalk Server 2006” by Lee Monson in the first edition of the BizTalk HotRod publication (http://go.microsoft.com/fwlink/?LinkId=188110).

  Note: While this article focuses on BizTalk Server 2006, the same concepts apply to subsequent versions of BizTalk Server, including BizTalk Server 2006 R2, BizTalk Server 2009, and BizTalk Server 2010.

  BizTalk SQL Server databases

  Disaster Recovery and / or High Availability for the BizTalk Server databases in SQL Server can be accomplished as follows:

  1. Disaster recovery for the BizTalk Server databases in SQL Server is available with BizTalk Server log shipping.  For more information about using BizTalk log shipping see Disaster Recovery (http://go.microsoft.com/fwlink/?LinkId=186349) in the BizTalk Server 2009 Operations Guide.
  2. High availability for the BizTalk Server databases in SQL Server is available using Windows Server 2008 failover clustering. For more information about providing high availability / redundancy for the BizTalk Server databases see High Availability for Databases (http://go.microsoft.com/fwlink/?LinkId=187333) in the BizTalk Server 2009 Operations Guide.

  Enterprise Single Sign-On Service

  High availability for the Enterprise Single Sign-On Service is provided through Windows Server 2008 failover clustering. For more information about providing high availability for the Enterprise Single Sign-On Service see How to Cluster the Master Secret Server (http://go.microsoft.com/fwlink/?LinkID=184009) and the Improving Fault Tolerance in BizTalk Server by Using a Windows Server Cluster (http://go.microsoft.com/fwlink/?LinkID=144722) whitepaper.

  Establish Sizing Guidelines

  Because BizTalk Server solution requirements can vary greatly depending on the business requirements of the solution there is no simple answer for establishing sizing guidelines. The best way to determine sizing requirements is to:

  1. Develop the solution in a sandbox environment.
  2. Test the solution with as close to a real time load as is possible. For information about load testing a BizTalk Server solution see Testing your BizTalk Server solution.
  3. Determine the solution throughput, or number of documents that the solution can process within a given time interval. The factors that affect throughput of a BizTalk Server solution include:
     • Message size – Larger messages consume more overhead than smaller messages, especially if the messages are transformed with a map and are large enough so that they are buffered to the file system during the mapping operation. For more information about how message size affects BizTalk Server performance, see How BizTalk Server Processes Large Messages (http://go.microsoft.com/fwlink/?LinkId=139293).
     • Message format – Messages are received into BizTalk Server in one of two primary formats, XML files or flat files. Because flat files must be translated into the XML format to be processed by the BizTalk Messaging engine, additional overhead is incurred by the processing of flat files.
     • Adapter requirements – Different adapters frequently have varying performance capabilities. For example, adapters that require MSDTC transaction support will incur additional overhead/reduced performance as compared to an adapter that does not use MSDTC transactions. Adapters used by the BizTalk solution will vary depending on your trading partner’s requirements and/or internal business needs.
     • Orchestration processing requirements – Orchestrations provide great flexibility for encapsulating and applying business processes to messages received by BizTalk. At the same time, orchestrations consume overhead, which must be considered when estimating the throughput of a BizTalk Server solution.
     • Peak load requirements – Most document processing does not necessarily occur in a measured orderly fashion. For example, a BizTalk Server solution may sustain a large percentage of its processing load at the close of a business day. Therefore peak load requirements and the Maximum Sustainable Throughput (MST) of a BizTalk Server solution should be taken into account when establishing throughput criteria. For more information about measuring the MST of a BizTalk Server solution, see Measuring Maximum Sustainable Engine Throughput (http://go.microsoft.com/fwlink/?LinkID=154388) and Measuring Maximum Sustainable Tracking Throughput (http://go.microsoft.com/fwlink/?LinkID=153815).
     • Document tracking requirements – Document tracking imposes additional overhead on the system. Document tracking requirements should be a primary consideration when estimating the throughput goals of a BizTalk solution.
  4. Optimize performance of and scale the solution accordingly.  For information about optimizing performance of a BizTalk Server solution see Optimizing Performance (http://go.microsoft.com/fwlink/?LinkId=187866) in the Microsoft BizTalk Server 2009 Performance Optimizations Guide. For information about scaling a BizTalk Server solution see Scaling your BizTalk Server solution.

  Create a timeline for development, testing and deployment of the solution

  It is important to have a clear and concise record of milestones for installing, developing, testing and deploying the solution. Setting specific milestones will increase the likelihood that the project will be completed in a timely manner. Consider creating a Visio timeline to visually represent dates, milestones, and tasks associated with the BizTalk Server solution. Keep the timeline simple enough to be easily understood yet detailed enough to communicate milestones effectively. The actual milestones should be agreed upon by all stakeholders and reviewed regularly. A sample Visio timeline is displayed below:

  

  Figure 3 – Example Visio timeline

  Important: This example timeline will very likely not be representative of a given BizTalk Server installation and deployment. For very simple, small scale/single server scenarios a BizTalk Server solution may be installed and deployed in one or two days whereas complex, large scale/multi server scenarios with custom code may require several weeks.

  Note: For more information about how to create a timeline using Visio 2007, see the article Create project timelines in Visio 2007 (http://go.microsoft.com/fwlink/?LinkId=119395).

  Deploying and configuring the SQL Server databases used for your BizTalk Server solution

  BizTalk Server is an extremely database-intensive application that may require the creation of up to 13 databases in SQL Server. Because one of the primary design goals of BizTalk Server is to ensure that no messages are lost, BizTalk Server persists data to disk with great frequency and furthermore, does so within the context of an MSDTC transaction. Therefore, database performance is paramount to the overall performance of any BizTalk Server solution. To ensure that the SQL Server instance used to house the BizTalk Server databases provides optimal performance, consider performing the following steps:

  1. Consider housing your BizTalk Server databases on a separate, dedicated instance of SQL Server. All editions of BizTalk Server support housing the BizTalk Server databases on a separate, remote instance of SQL Server. Separating the BizTalk Server (application tier) from the SQL Server (data tier) onto separate servers provides improved performance as well as the advantages inherent to a tiered distribution deployment pattern.  For more information about tiered distribution deployment see Tiered Distribution (http://go.microsoft.com/fwlink/?LinkId=187920) in the MSDN Library.
  2. Complete steps documented in the Optimizing Database Performance (http://go.microsoft.com/fwlink/?LinkId=187922) section of the Microsoft BizTalk Server 2009 Performance Optimizations Guide.  There are several techniques available for optimizing performance of SQL Server, most notably by optimizing performance of the SQL Server disks and filegroups.  Optimizing Database Performance (http://go.microsoft.com/fwlink/?LinkId=187922) provides a comprehensive reference of techniques that should be followed to optimize the performance of the SQL Server instance used to house the BizTalk Server databases.
  3. Read through and apply the steps in the BizTalk Server Database Optimization whitepaper (http://go.microsoft.com/fwlink/?LinkID=153594) as needed.  Though this guide was written with BizTalk Server 2006 R2 and SQL Server 2005 in mind, many of the principles in the whitepaper still apply to more recent versions of BizTalk Server and SQL Server.
  4. If running BizTalk Server Enterprise Edition, consider installing multiple Messagebox databases. Because the BizTalk Messagebox database is typically the most I/O intensive of all of the BizTalk Server databases, BizTalk Server Enterprise Edition provides functionality to scale out from a single Messagebox database to multiple Messagebox databases. For more information about adding additional Messagebox databases see Scaling Out the SQL Server Tier (http://go.microsoft.com/fwlink/?LinkID=158075) and the “Providing High Availability for the BizTalk MessageBox Database” section of Scaling Out the BizTalk Server Databases (http://go.microsoft.com/fwlink/?LinkId=187948) in the Microsoft BizTalk Server 2009 Operations guide.

  Note: If you configure multiple MessageBox databases in your environment you should create a minimum of three MessageBox databases for your BizTalk Server group and you should disable message publication on the master MessageBox database. This recommendation is made because adding additional MessageBox databases incurs overhead by the master MessageBox database for routing messages between the MessageBox databases. If you only configure two MessageBox databases then most of the benefit gained by the additional MessageBox database is offset by the overhead consumed by the master MessageBox database for message routing.

  Developing your BizTalk Server solution

  BizTalk Server solutions are developed using Visual Studio 2008, which provides integration with the BizTalk project system to create all or part of a BizTalk Server application. BizTalk projects are comprised of one or more of the following BizTalk artifacts:

  • Orchestrations - An orchestration represents the workflow of a business process. Orchestrations are created with the Orchestration Designer.
  • Schemas - A schema describes the structure of an XML document. Schemas exchange information among applications within an organization or among trading partners. Schemas are designed with the BizTalk Editor.
  • Maps - A map transforms data from one format to another. Maps are created with the BizTalk Mapper, which presents source schemas and destination schemas side-by-side and enables you to define transformations between data elements of different messages.
  • Pipelines - A pipeline performs a variety of operations to prepare incoming or outgoing messages for further processing. Pipelines are created with the Pipeline Designer, which enables you to implement such operations as encryption and decryption, compression, reformatting, and validation.

  Using virtualization to host the BizTalk Server development environment

  By using virtualization to host the BizTalk Server developer environment, a preconfigured BizTalk Server development environment can be prepared on a virtual hard disk and sent to each developer. Then the developers can simply rename the virtual machine and perform the final BizTalk configuration steps to be up and running in significantly less time than if they had to install BizTalk Server prerequisites and BizTalk Server from scratch. For more information about using virtualization to host the BizTalk Server developer environment see Using virtualization to Host the BizTalk Server Developer Environment (http://go.microsoft.com/fwlink/?LinkId=187981). The “Sysprep a BizTalk Server VHD” SDK sample can be used to sysprep a BizTalk Server image as described in the BizTalk Server documentation at Sysprep a BizTalk Server VHD (BizTalk Server Sample) (http://go.microsoft.com/fwlink/?LinkId=187984).

  BizTalk developer reference material

  In addition to the BizTalk Server Development documentation (http://go.microsoft.com/fwlink/?LinkId=187992), the following references are excellent resources that should be utilized when developing a BizTalk Server solution:

  1. Developing Integration Solutions using BizTalk Server 2009 and Team Foundation Server (http://go.microsoft.com/fwlink/?LinkId=187962) - Provides developers with techniques for designing, developing, and deploying solutions within Microsoft BizTalk Server 2009 in conjunction with Team Foundation Server 2008.
  2. Developers Guide to Troubleshooting BizTalk Server 2006 (http://go.microsoft.com/fwlink/?LinkId=187963) – Provides guidance to developers in the detection and correction of programming issues within a BizTalk application. While this guide was written for BizTalk Server 2006, the techniques described are relevant for subsequent releases of BizTalk Server.
  3. Business Activity Monitoring (BAM) Training Kit (http://go.microsoft.com/fwlink/?LinkID=125943) – Provides instructor-led as well as self-study training for BAM.
  4. Business Activity Monitoring in Depth for Developers (http://go.microsoft.com/fwlink/?LinkId=187966) – Provides a deep, low-level review of how BAM works and how BAM can be extended. It reviews BAM basics, shows ways in which BAM data can be collected, discusses the BAM infrastructure, demonstrates methods for collecting BAM data, and shows how BAM can be extended to non-Microsoft technologies.

  Testing your BizTalk Server solution

  Importance of implementing automated testing

  All too often, testing of a BizTalk Server solution is thought of as unnecessary overhead or is almost treated as an afterthought, which can have disastrous consequences. Because BizTalk Server solutions are frequently deployed in mission-critical scenarios, it is of paramount importance that sufficient time is allocated for build verification testing, functional testing, and automated load testing. To ensure that testing is performed accurately, it is highly recommended that automated testing of the solution is implemented whenever possible. For specific information about implementing automated testing of a BizTalk Server solution using BizUnit 3.0, see Implementing Automated Testing (http://go.microsoft.com/fwlink/?LinkId=187990) in the Microsoft BizTalk Server 2009 Performance Optimizations Guide.

  Load Testing

  For information about load testing a BizTalk Server solution see BizTalk Server Performance Testing Methodology (http://go.microsoft.com/fwlink/?LinkId=187858) in the BizTalk Server 2009 Performance Optimizations guide. To quickly determine the performance characteristics of your BizTalk Server solution consider downloading the BizTalk Benchmark Wizard (http://go.microsoft.com/fwlink/?LinkId=186347) and running it against your BizTalk Server environment. The BizTalk Benchmark Wizard tool is an excellent tool for quickly determining if your BizTalk Server environment can handle a “production” load so that you can make the necessary adjustments to your environment before putting the system into production.

  Deploying your BizTalk Server solution

  • Follow the steps in Checklist: Deploying an Application (http://go.microsoft.com/fwlink/?LinkId=188013) in the BizTalk Server 2009 Operations Guide to deploy applications from development into production.
  • For more information about application deployment, see The Application Deployment Process (http://go.microsoft.com/fwlink/?LinkId=154716) in the BizTalk Server 2009 Help.
  • For a list of best practices for deploying a BizTalk Application see Best Practices for Deploying a BizTalk Application (http://go.microsoft.com/fwlink/?LinkId=188014).

  Considerations for deploying BizTalk Server into a Hyper-V environment

  Hardware advancements such as multi-core processors and AMD-V / Intel VT provide enhanced support for virtualization technology and Microsoft Hyper-V is designed to take full advantage of these hardware advancements. As a result, the performance gap between virtual machines and physical hardware is quickly closing and an increasing number of companies are deploying software solutions into production on virtual machines.

  Deploying your BizTalk Server solution to run on a Hyper-V virtualized environment provides the following flexibility and functionality:

  • Ability to define multiple distinct logical security boundaries on a single physical computer – Hyper-V accommodates the creation of distinct logical security boundaries or partitions within a single physical hardware resource. A partition is a single logical unit of isolation, supported by the hypervisor, in which operating systems execute. For example, you could create multiple BizTalk Server groups to run on a single Hyper-V host computer whereas you would not be able to do this when installing BizTalk Server on the host operating system of a single host computer.
  • Ease of deployment and management – Consolidation of BizTalk Server computers into fewer physical servers simplifies deployment. Furthermore, a comprehensive Hyper-V management solution is available with System Center Virtual Machine Manager. For more information about System Center Virtual Machine Manager, see Microsoft System Center Virtual Machine Manager (http://go.microsoft.com/fwlink/?LinkID=111303).
  • Fault tolerance support through Hyper-V clustering – Because Hyper-V is a cluster aware application, Windows Server 2008 provides native host clustering support for virtual machines created in a Hyper-V virtualized environment.
  • Ease of scale-out – Additional processing power, network bandwidth, and storage capacity can be accommodated for your BizTalk Server solution quickly and easily by apportioning additional available resources from the host computer to the guest virtual machine(s). This may require that the host computer is upgraded or that the guest virtual machines are moved to a more capable host computer.
  • Consolidation of hardware resources – Multiple physical servers can be easily consolidated into comparatively fewer servers by implementing virtualization with Hyper-V. Consolidation accommodates full use of deployed hardware resources.

  For detailed information about whether or not deploying your BizTalk Server solution into a Hyper-V environment is a viable option see the BizTalk Server 2009 Hyper-V Guide (http://go.microsoft.com/fwlink/?LinkID=151834). The BizTalk Server 2009 Hyper-V Guide includes lab testing results that compare the performance of a BizTalk Server application running on physical hardware to the performance of the same application running on Hyper-V virtual machines.

  Maintaining your BizTalk Server solution

  For a comprehensive listing of tasks that relate to maintaining a production BizTalk Server environment see Maintaining BizTalk Server (http://go.microsoft.com/fwlink/?LinkId=188017) in the Microsoft BizTalk Server 2009 Operations Guide or Microsoft BizTalk Server 2010 Operations Guide. Managing BizTalk can be done with the out of the box Administration Console, which focuses on BizTalk Group itself, managing applications, adapters, etcetera and for troubleshooting purposes. For monitoring System Center Operation Manager or alternative solutions mentioned in BizTalk Monitoring Tools.

  Scaling your BizTalk Server solution

  For information about scaling a BizTalk Server solution see Scaling Your Solutions (http://go.microsoft.com/fwlink/?LinkID=158078) in the BizTalk Server 2009 core documentation.

  See Also

  Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki

  Read suggested related topics:

  • How to Install and Configure BizTalk Server 2010 in a Standalone Machine
  • How to Install BizTalk Server 2010 in a Basic Multi-Computer Environment
  • Install and Configure BAM (Business Activity Monitoring) in a Multi-Computer Environment
  • BizTalk Versions