Technical White Paper

Published: April 7, 2006 | Updated: May 8, 2006

Executive Summary

As an organization that has business partnerships with several hundred other organizations, Microsoft relies on Microsoft® BizTalk® Server as its Enterprise Application Integration business solution. The Microsoft BizTalk Server environment has grown over many years with new BizTalk Server implementations created to meet particular business requirements. With over 150 application feeds, the Microsoft BizTalk Server environment®considered as a medium-sized BizTalk Server environment®has become a key component in the day-to-day operations of the company. The Microsoft BizTalk Server implementation acts as the hub between internal and external business transactions at the company, from the production and manufacture of the Microsoft Xbox® video game system through the movement of more than US$20 billion in treasury funds each month.

Within the Microsoft Information Technology (Microsoft IT) department, the Enterprise Application Services (EAS)-Electronic Business Integration Services (e*BIS) group provides solutions to support the various document translation services that are used in business-to-business messaging at Microsoft. Because of new administration and management features that are available in Microsoft BizTalk Server 2006, its support for 64-bit computing, and its strong support for flat file locations, the group determined that it could consolidate its four disparate BizTalk Server implementations into a single stable environment running BizTalk Server 2006.

The e*BIS group is performing this upgrade in two parts. After thoroughly testing BizTalk Server 2006 in its laboratory environment, the group moved its Microsoft BizTalk Server 2004 implementation to a 64-bit BizTalk Server 2006 environment. Next, the group began the movement of its Microsoft BizTalk Server 2002 application feeds to its BizTalk Server 2006 environment. By May 2006, the group expects to have all but seven of its application feeds running on BizTalk Server 2006. The purpose of this implementation is to significantly reduce the server footprint in its BizTalk Server environment, while also reducing support costs by retiring legacy applications required by the BizTalk Server 2002 and BizTalk Server 2004 implementations. Additionally, the group seeks to reduce support costs by simplifying administration and operational tasks in the BizTalk Server environment and by implementing lower-cost 64-bit servers that have a performance that is greater than similarly configured 32-bit servers.

This white paper shares the experiences of the e*BIS group in the deployment of BizTalk Server 2006. Because of the significant amount of experience that the group has gained throughout this deployment, this information should provide meaningful guidance to organizations that want to upgrade their messaging environments to BizTalk Server 2006.

This white paper is intended for enterprise business decision makers, technical decision makers, IT architects, database developers, and deployment managers. Although this white paper provides recommendations based on Microsoft IT early-adopter experiences, it is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances. Therefore, each organization should adapt this information to meet its specific requirements.

Note: For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names used in this white paper do not represent real resource names used within Microsoft and are for illustration purposes only.

Introduction

When considering Microsoft products and technologies, corporate decision makers often request information about Microsoft employees' experiences in using these products and technologies within Microsoft. Microsoft IT not only provides IT services for Microsoft, but it also acts as the first customer for each new release of server and business productivity software. Because Microsoft IT requirements are among the most technically challenging in the world, the methods that Microsoft IT uses to deploy these technologies and the experience that Microsoft IT gains from these deployments often provide meaningful deployment and operational guidelines for other organizations that want to deploy Microsoft products.

Additionally, because Microsoft IT works with these Microsoft products from the prerelease editions to the Release to Manufacturing (RTM) editions, Microsoft IT provides the rest of Microsoft with valuable feedback about product features and functionalities. This feedback not only improves the software products throughout their development, but it also helps Microsoft customers and partners successfully deploy these products and technologies.

As the largest software company in the world, with yearly revenues exceeding $39 billion, Microsoft considers the availability and the reliability of its BizTalk Server implementation as a critical part of the day-to-day operations of the company.

Overview of BizTalk Server at Microsoft

Within Microsoft IT, the e*BIS group provides solutions to support the various document translation services that are used in business-to-business messaging at Microsoft. The e*BIS group's BizTalk Server environment acts as a hub between internal and external communications at Microsoft. The group has four BizTalk Server implementations in production. Each of these BizTalk Server implementations was created to meet a particular business need. As the e*BIS group's BizTalk Server environment has grown and developed over several years, the group has found itself maintaining a large number of disparate BizTalk Server systems, with a corresponding increase in training and support costs.

The e*BIS group's BizTalk Server environment consists of over 150 separate BizTalk Server feeds that are handled by these four BizTalk Server implementations. Three similarly configured environments running BizTalk Server 2002 handle about 135 of these feeds. Each BizTalk Server 2002 environment consists of one processing server together with two back-end database servers that are configured in an active/passive server cluster. Figure 1 shows the BizTalk Server 2002 architecture.

Figure 1. BizTalk Server 2002 architecture

Although most of the e*BIS group business streams currently run on BizTalk Server 2002, 17 business feeds ran on the group's BizTalk Server 2004 implementation. Of these business feeds, the group relied on BizTalk Server 2004 for the following Xbox-related business streams:

• Repair/Refurbish: This stream consists of repair and refurbish transactions for the Xbox system.

• Manufacturing: This stream consists of serial tracking and shipment processing.

• Supply Chain Manufacturing: This stream consists of RosettaNet Partner Interface Processes (PIPs) for supply chain management of the Microsoft Xbox 360® system.

Microsoft does not own the facilities where components for the Xbox system are manufactured or where the Xbox system platform is assembled. Instead, Microsoft engages with nine different external suppliers and manufacturers that provide the parts and services that are critical to the manufacture of the Xbox system. Microsoft relies on BizTalk Server as the communications hub for transactions sent to and from these different business partners. Microsoft has made a significant investment in the highly competitive and fast-moving game device industry and has used the timely and reliable transaction processing of BizTalk Server 2004 to efficiently track component purchases and returns, while keeping inventories to a minimum.

The e*BIS group's BizTalk Server 2004 environment consisted of two processing servers together with two servers running Microsoft SQL Server® 2000 in an active/passive cluster configuration. Figure 2 shows the BizTalk Server 2004 architecture.

Figure 2. BizTalk Server 2004 architecture

The e*BIS group's BizTalk Server 2004 implementation acted as the hub for all transactions that the Microsoft Entertainment and Devices (E&D) division relied on for all of its Xbox 360 business processes. Therefore, not only did Microsoft E&D rely on BizTalk Server 2004, but nine different business partners also relied on the e*BIS group's BizTalk Server 2004 environment to help manage the production and manufacture of the Xbox 360 system platform.

In addition to the server applications that the e*BIS group uses in its BizTalk Server environments, many custom tools were also created by the group over a period of many years to help manage transaction tracking, reporting, and the copying of files to and from flat file locations.

Situation

The e*BIS group has the following overall goals for its BizTalk Server implementation. The group considers these goals as key to the success and stability of an Enterprise Application Integration business solution such as BizTalk Server 2006:

• Easy integration with legacy transport mechanisms

• Simple tracking of data during every stage of processing and translation

• Easy deployment of BizTalk Server configurations between development, quality assurance, and production environments

• Simple and easy method of scaling the BizTalk Server environment

• High availability of the BizTalk Server environment

• Quick and easy method of viewing the operational health of the BizTalk Server environment

Although the e*BIS group was generally pleased with the performance and reliability of BizTalk Server 2002 and BizTalk Server 2004, the group experienced the following problems in its BizTalk Server environment:

• The group had to train and maintain support personnel for two different systems (BizTalk Server 2002 and BizTalk Server 2004).

• The warranty period was about to expire for some of the servers that were running BizTalk Server 2002. The impending expiration threatened to leave the group with an unsupported server environment.

With the development of Microsoft BizTalk Server 2006, the e*BIS group saw that it could take advantage of several new features of BizTalk Server 2006. These features might help the group reach its Enterprise Application Integration business goals. Some of these features are:

• Administration enhancements such as the Administration Console, Per Host Throttling, and the ability to package applications as MSI packages

• Improved support for flat file locations

• Support for 64-bit computing

The e*BIS group supports many legacy applications within its BizTalk Server 2002 environments. Because virtually all of these legacy applications require flat file receive locations, and because of issues that the group experienced when it tested these flat file receive locations with BizTalk Server 2004, the group did not move all of its BizTalk Server 2002 feeds to BizTalk Server 2004. Because of the improved support for flat file receive locations in BizTalk Server 2006, the group determined that it could move all of its BizTalk Server 2002 feeds and BizTalk Server 2004 feeds to a single BizTalk Server 2006 environment. Additionally, because of the similarities between BizTalk Server 2004 and BizTalk Server 2006, the group would not have to provide a formalized training program to support BizTalk Server 2006.

Also, the e*BIS group recognized that it could achieve both performance improvements and server consolidation by moving to 64-bit servers running BizTalk Server 2006. Therefore, the group developed the following plan to move all of its application feeds to a single standardized environment running BizTalk Server 2006:

1. An initial migration of its BizTalk Server 2004 implementation to BizTalk Server 2006

2. An incremental migration of its BizTalk Server 2002 application feeds to the BizTalk Server 2006 environment

Figure 3 shows the e*BIS group's BizTalk Server 2006 architecture.

Figure 3. BizTalk Server 2006 architecture

By March 2006, the e*BIS group had successfully migrated the following business feeds to BizTalk Server 2006:

• 11 of 17 BizTalk Server 2004 application feeds

• 7 of about 135 BizTalk Server 2002 application feeds

By May 2006, the e*BIS group expects to have all but seven of the remaining BizTalk Server 2002 feeds migrated to the BizTalk Server 2006 environment. Due to their high level of customization, the group determined that it must perform a more detailed analysis of the seven remaining BizTalk Server 2002 application feeds. The group has started working on a process to encapsulate the custom processes within a BizTalk orchestration in order to seamlessly integrate these feeds into BizTalk Server 2006.

"BizTalk Server 2006 enables us to seamless migrate our enterprise to a single sophisticated and adaptable business platform."

Dennis Byrd

Solution: BizTalk Server 2006

While considering the business justification to upgrade its BizTalk Server environment to BizTalk Server 2006, the e*BIS group looked at the features available in BizTalk Server 2006, such as improved message throughput and support for 64-bit computing. But the most compelling reason for the group to upgrade from BizTalk Server 2002 and BizTalk Server 2004 to BizTalk Server 2006 is the latter's improved administration and maintenance features, which would reduce administration and maintenance support costs in the group's BizTalk Server environment.

Administration and Maintenance

The e*BIS group determined the following administration and maintenance enhancements in BizTalk Server 2006 to be key to its goal of the reduction of support costs in its BizTalk Server environment.

Administration Console

After the e*BIS group installs and configures a BizTalk Server environment, members of the operations team perform the day-to-day administration tasks related to the ongoing maintenance of that environment. If a messaging error occurs, the operations team must locate and troubleshoot it to determine whether a problem exists in the message itself or in BizTalk Server. However, the operations team found it difficult to troubleshoot messaging errors by using the Health and Activity Tracking (HAT) tool in BizTalk Server 2004.

For example, a document might contain a field that is too long, causing BizTalk Server to reject the document. In these situations, the operations team found that it was difficult to troubleshoot the problem. Using the HAT tool, members of the operations team experienced the following problems:

• Difficulty in locating the affected document

• Difficulty in confirming whether they had, in fact, located the correct document

• Difficulty in determining what to look for after they had located the correct document

After upgrading to BizTalk Server 2006, the operations team found it much easier to locate and troubleshoot failed transactions. The BizTalk Server 2006 Administration Console gives operators an easy-to-use tool to view the overall health of the BizTalk Server environment and to quickly locate failed documents. Operators now connect to the Group Hub page to view errors. Figure 4 shows the Group Hub page in the e*BIS group's BizTalk Server 2006 Administration Console.

Figure 4. BizTalk Server 2006 Group Hub page

On the Group Hub page of the BizTalk Server 2006 Administration Console, suspended documents are categorized as Resumable or Non-resumable. Suspended documents are categorized as Resumable for reasons such as a network failure. Suspended documents are categorized as Non-resumable if they cannot be resubmitted to BizTalk Server 2006 for reasons such as an incorrect map or an invalid document.

In the BizTalk 2006 environment, it is now much easier for members of the operations team to locate an affected document and view the particular error that occurred. The e*BIS group estimates that it now takes less than half the time to troubleshoot the cause of a failed document than it previously did. Another benefit that the group realized with the BizTalk Server 2006 Administration Console is that the operations team can use it to view an overall snapshot of the health of the BizTalk Server 2006 environment. The operations team can now easily see whether there are any suspended messages, or any other problems, in the BizTalk Server environment. This functionality is greatly improved over the functionality that the group had in the BizTalk Server 2002 or BizTalk Server 2004 environment. The Group Hub page in BizTalk Server 2006 not only gives the operations team an overview of suspended messages, but it also groups these messages by Uniform Resource Identifier (URI) or by trading partner.

Per Host Throttling

The e*BIS group is keenly aware that its BizTalk Server environment is a critical juncture for many of the business processes of Microsoft and of Microsoft business partners. Therefore, the group requires a significant business justification to schedule downtime for maintenance in its BizTalk Server environment. Also, because of the fast pace of modern business processes, and because business-to-business processing feeds run on a 24-hours-per-day, seven-days-per-week schedule, no suitable time to perform scheduled maintenance exists in its BizTalk Server environment.

In its BizTalk Server 2004 implementation, the e*BIS group sometimes experienced a processing problem after taking one processing server offline for maintenance. In this scenario, the remaining processing server did not keep up with the messaging load. The group experienced both of the following limitations with BizTalk Server 2004:

• As a 32-bit system, BizTalk Server 2004 can address only a certain amount of memory. This limits the number of messages that BizTalk Server 2004 can process.

• The BizTalk Server 2004 host did not throttle back to limit the number of incoming messages to process.

Because of these limitations, if the remaining processing server was under a heavy load, it experienced out-of-memory errors and the BizTalk Server host process would quit. In effect, the remaining processing server choked on the messaging traffic and did not recover.

The e*BIS group considered the new Per Host Throttling feature in BizTalk Server 2006 as the resolution to this problem. BizTalk Server 2006 includes a feature that reduces the number of messages that it sends or consumes. An administrator can set a threshold at the host level in BizTalk Server 2006. BizTalk Server 2006 includes an algorithm to detect when the number of messages that it sends or consumes exceeds this threshold. When the threshold is exceeded, BizTalk Server 2006 throttles back to reduce the number of messages that it sends or consumes.

The e*BIS group determined that the Per Host Throttling feature in BizTalk Server 2006 would enable the remaining processing servers in a group to handle the message flow while one or more processing servers underwent scheduled maintenance. The implementation of BizTalk Server 2006 Per Host Throttling gives the group a 99.999 percent availability in its BizTalk Server 2006 environment, even during periods of scheduled maintenance.

To make sure that the BizTalk Server 2006 environment met the criteria of zero downtime during scheduled maintenance, the e*BIS group tested BizTalk Server 2006 to verify whether it could handle the messaging traffic while one of the other processing servers was offline. Also, the group tested BizTalk Server 2006 to make sure that it could recover from a large message backlog. To test BizTalk Server 2006 in this environment, the group configured the following:

• A simulated production environment: The group moved all the assemblies and maps from the BizTalk Server 2004 production environment to a test environment running BizTalk Server 2006 to match the production environment. For more information about this process, see the "64-Bit Computing" section later in this white paper.

• Positive and negative smoke tests: The group performed exhaustive document testing to make sure that BizTalk Server 2006 returned the correct and expected results for valid documents (positive smoke tests), as well as the correct and expected failure results for known invalid documents (negative smoke tests).

• Load tests: The e*BIS group's production environment must handle a messaging load of 40 messages per second. The group used the LoadGen load generation tool to generate up to three times this messaging load in order to make sure that BizTalk Server 2006 could handle far more than the expected messaging load.

• A simulated a "system down" scenario: To make sure that BizTalk Server 2006 could handle the initial bulk messaging load that occurs when a system restarts after being offline, the e*BIS group simulated a "system down" scenario. To do this, the group turned off all the receive locations on the BizTalk Server®based server, but the group continued to deliver messages to the server by using the LoadGen tool. After allowing a sufficient number of messages to accumulate (in one test, 25,000 messages), and while generating 2.5 times the production level of additional messages to the system by using LoadGen, the group turned on all of the receive locations again.

  During the simulated "system down" scenario, BizTalk Server 2006 successfully throttled back to limit the number of messages that it processed. This kept the BizTalk Server 2006 system from exceeding its hardware limitations but kept it within stable operating parameters. The Per Host Throttling feature in BizTalk Server 2006 gives the e*BIS group a self-healing behavior in the BizTalk Server 2006 environment if one or more processing servers in a group goes offline.

MSI Packages

As part of the BizTalk Server 2006 deployment, the e*BIS group tested and deployed beta editions of BizTalk Server 2006 throughout the BizTalk Server 2006 development cycle. Although the group relied on beta editions of BizTalk Server 2006 to provide a stable and reliable business messaging platform, the group does not arbitrarily run beta software in its production environment. Rather, the group performs exhaustive testing of the beta product in a laboratory environment as well as in its quality assurance integration environment before implementing it in the production environment. The group performed stress testing by using messaging loads that greatly exceeded the expected production throughput in the BizTalk Server environment.

The e*BIS group has three environments that it uses for the development, testing, and deployment of BizTalk Server:

• A laboratory environment: The e*BIS group uses this environment to perform basic functionality and stress testing of BizTalk Server features and assemblies.

• A staging environment: The e*BIS group uses this environment as a preproduction facility to make sure that the BizTalk Server components or assemblies function exactly as they should when deployed in the production environment. Additionally, the group performs transport analysis of the components in this environment.

• A production environment: If all tests and features work as expected in the staging environment, the e*BIS group deploys the particular application in the production environment.

The e*BIS group designed its laboratory environment to closely resemble its production environment to ensure that tests on features and functionalities in the laboratory environment return results that are as close as possible to the results that the group expected in its production environment. Figure 5 shows the group's BizTalk Server laboratory environment.

Figure 5. e*BIS group's BizTalk Server laboratory environment

To test applications from the BizTalk Server 2004 environment by using BizTalk Server 2006, the e*BIS group ported each of the BizTalk Server 2004 assemblies to BizTalk Server 2006. Also, for each new functionality that the group wants to run on BizTalk Server 2006 in the future, the group first tests and configures that assembly on BizTalk Server 2006 in the laboratory environment, moves the assembly to the staging environment, and then deploys the assembly to the production environment.

The task of moving assemblies between computers running BizTalk Server in order to configure a processing server used to be a laborious task. Administrators had to export the binding file, manually move all the appropriate files to the destination computer, and then import the binding file. In some cases, administrators experienced difficulty verifying whether they had moved the correct files, or whether they had installed all the required files in the correct location (that is, the Global Assembly Cache [GAC]). This process becomes even more complex in an environment that has multiple processing servers.

BizTalk Server 2006 enables an administrator to package a complete application as an .msi file by using the Microsoft Windows® Installer. By using this feature, the e*BIS group saves a considerable amount of time moving applications between servers and in configuring new processing servers. The group uses .msi files to deploy applications in the following manner:

1. The group tests the application in the laboratory environment.

2. The group moves the application to the staging environment.

3. After the group approves the application's functionality in the staging environment, the group packages the application as an .msi file. This action combines all the required dynamic-link libraries (DLLs) and configuration information into one package.

4. An administrator runs the .msi file in the production environment. The .msi file automatically installs the appropriate files in the GAC and in the configuration database.

Compared with the manual installation method that the e*BIS group formerly used, this method of installing an application saves time and reduces errors. Also, by using .msi files, the group can more easily guarantee that standardized server configurations are followed when the group deploys new BizTalk Server 2006 processing servers.

The e*BIS group has a number of common applications that it runs on each processing server. Therefore, when the group configures a new processing server, the group must ensure that these applications are installed on that server. To install these applications, the group uses the BizTalk Server 2006 functionality that enables an administrator to reference other applications from within an MSI package. The group created a single MSI package called MSIT that contains all of the required internal tools. These internal tools are common to each of the group's applications. When the group creates an application package from the staging environment to import on a production server, it creates a reference to the MSIT package. Because the application's MSI package references the MSIT package, the administrator has to install only the particular application's MSI package. This simplifies the configuration of a new BizTalk Server 2006 processing server and ensures that all of the required internal tools are installed together with the new application feed.

Because of the ease of use of MSI packages in BizTalk Server 2006, and because these packages help the e*BIS group ensure a standardized processing server implementation, the group uses MSI packages as an operational policy for all application feeds in BizTalk Server 2006.

Server Consolidation

One of the goals of the e*BIS group is to reduce support costs in its BizTalk Server environment. The group hopes to achieve this goal by reducing the number of disparate systems and by consolidating applications onto the fewest number of servers possible.

Although BizTalk Server 2006 includes many administration improvements and management enhancements to help reduce support costs, the e*BIS group saw the following two features as a means of implementing server consolidation to further reduce support costs in its BizTalk Server environment:

• Improvements in how BizTalk Server 2006 handles flat file processing

  The e*BIS group determined that the improved support for flat file locations in BizTalk Server 2006 would be critical for the successful movement of its BizTalk Server 2002 application feeds to the BizTalk Server 2006 environment.

• Processing improvements because of the support for 64-bit computing in BizTalk Server 2006

  Because of the performance and memory improvements on a 64-bit platform, the e*BIS group calculated that it could reduce the number of BizTalk Server processing servers in its BizTalk Server environment.

In addition, some of the computers in the BizTalk Server 2002 environment have reached the end of their warranty period. The e*BIS group considers server consolidation as a way to reduce support costs for these outdated systems.

Flat File Improvements

BizTalk Server 2006 includes improved support for flat file locations. The e*BIS group has to support disparate BizTalk Server environments because many of the flat file application feeds in those BizTalk Server environments rely on flat file receive locations. These flat file application feeds perform satisfactorily on BizTalk Server 2002. The group hesitated to move them to BizTalk Server 2004 because of performance issues that the group might experience with these particular application feeds.

Enhanced support for flat file locations in BizTalk Server 2006 enables the e*BIS group to focus its entire BizTalk Server environment on BizTalk Server 2006. This enables the group to save money on support and training costs by no longer having to train and maintain support staff for two distinct versions of BizTalk Server. Instead, the group can streamline its product support requirements and reduce its training costs by supporting only BizTalk Server 2006.

Also, the e*BIS group currently provides support for many custom tools that have been deployed in its BizTalk Server 2002 and BizTalk Server 2004 environments. A primary example of these custom tools is a program called SONIC. SONIC is a program that was created to move files to and from the BizTalk Server environment. The group's BizTalk Server implementation acts as a hub between internal and external communications at Microsoft. The SONIC tool picks up messages from share locations to which internal applications submit messages, and then the SONIC tool moves those messages to locations where BizTalk Server can process them. Also, for partner applications that write to internal Microsoft share locations, the SONIC tool picks up the messages and moves them to a BizTalk Server processing location.

The e*BIS group devotes a lot of money to supporting the custom applications in its BizTalk Server environment. For example, the SONIC tool requires a separate tracking database that the group must maintain, and the group must update the SONIC tool every time new applications or changes to business logic are introduced into the group's BizTalk Server environment. Using BizTalk Server 2006, administrators can instantiate receive locations in order to monitor application shares. BizTalk Server 2006 can move the data from those application shares into BizTalk Server 2006 for processing. This functionality, together with other improvements in the support for flat file locations, helps the group meet its goal of reducing the amount of custom code in its BizTalk Server environment. The improved support for flat file locations in BizTalk Server 2006 will enable the e*BIS group to retire the SONIC tool, as well as the other custom tools that it created to support the group's previous BizTalk Server environment. The group intends to retire the SONIC tool in July 2006.

By retiring custom tools that will no longer be required after all the application feeds have been moved to BizTalk Server 2006, the e*BIS group estimates that it will save approximately $250,000 per year in support costs.

64-Bit Computing

Like most corporations, Microsoft strives to be fiscally responsible to its stakeholders while still supplying its IT departments with the resources that they need so that the company can function with the greatest possible efficiency. With the general increase in computing power for each dollar spent, and specifically with 64-bit computers becoming more common in the mainstream business environment, these tasks have become much easier.

Before implementing BizTalk Server 2006, the e*BIS group tested it by using a subset of the data that is generated in the group's production environment. The purpose of the tests was to reveal the optimal BizTalk Server 2006 environment that the group required to run, at the very minimum, all the current production feeds from all BizTalk Server instances in a single BizTalk Server 2006 environment.

The e*BIS group initially tested BizTalk Server 2006 on computers from the BizTalk Server 2004 laboratory environment, which is a 32-bit server environment. Table 1 outlines the specifications of these computers.

Table 1. BizTalk Server 2004 Laboratory Computers

*Millions of instructions per second

It was not feasible to reproduce each of the production feeds in the e*BIS group's BizTalk Server laboratory environment for the purposes of these tests. Therefore, to make sure that BizTalk Server 2006 would perform reliably in its production environment, the group simulated the production load of its BizTalk Server environment by configuring a subset of the transactions from its application feeds. This subset covered every production scenario that the group deals with in its production environment; the production scenarios were covered at full production levels. The group referred to each of these production scenarios as packages and broke them down to the component level. The components of each package included:

• Source message format

• Source envelope

• Source transport

• Destination transport

• Destination envelope

• Destination message format

• Acknowledgment type

After categorizing each package according to its particular production scenario, in the laboratory environment, the e*BIS group configured production feeds that fell into those categories. This categorization gave the group 28 different package types. The combination of these 28 different packages gave the group an outline of the production characteristics of its entire BizTalk Server environment. Therefore, the group could use the application feeds that fit the characteristics of these individual packages to provide a representation of its BizTalk Server gateway profile and to use that profile to test BizTalk Server 2006.

By using the LoadGen tool together with the application feeds that correspond to the particular packages, the e*BIS group successfully tested BizTalk Server 2006 with two gateway profiles that required a total processing power of 39,322 MIPS.

Each of the 32-bit servers that ran BizTalk Server 2004 had a total processing power of 19,661 MIPS. Generally, the e*BIS group did not experience any performance or reliability issues with its BizTalk Server 2004 configuration. The 32-bit servers provided a robust and reliable platform upon which to run BizTalk Server 2004. One of the limitations that the group thought might affect its BizTalk Server environment is that in a 32-bit environment, a single process cannot consume more than 1.5 gigabytes (GB) of RAM. This limitation could cause problems in the future, as BizTalk Server hosts consume and process an increasing number of transactions within the same CPU cycle. This limitation does not exist in a 64-bit computing environment. Therefore, the group expected to achieve better throughput and better performance by running BizTalk Server 2006 on a 64-bit server. Because of the support for 64-bit computing that is included with BizTalk Server 2006, the group determined that it could not only consolidate all of its business feeds into a single BizTalk Server 2006 environment but also greatly reduce the overall number of servers in that environment.

Toward this end, the e*BIS group deployed 64-bit servers in its BizTalk Server 2006 production environment. Table 2 shows the specifications of the computers in the group's BizTalk Server 2006 production environment.

Table 2. BizTalk Server 2006 Production Environment

*Millions of instructions per second

Not only do the 64-bit servers have processing power that is greater than the 32-bit servers®21,570 MIPS compared with 19,661 MIPS®but the 64-bit servers were also less expensive. By moving from multiprocessor servers to single-processor dual-core servers, the e*BIS group saved several thousand dollars per server.

Note: No direct comparison exists between the new 64-bit servers that the e*BIS group purchased and the 32-bit servers. However, the group calculated that had it tried to replace its 32-bit servers with similarly configure ed multiprocessor servers, the cost would have been three times as much as the cost of the single-processor dual-core servers.

Therefore, although the e*BIS group initially increased its server footprint by replacing its BizTalk Server 2004 implementation (which uses four servers) with its BizTalk Server 2006 implementation (which uses five servers), the group expects that it can use its implementation of the 64-bit version of BizTalk Server 2006 to significantly reduce its server footprint. As the application feeds from the BizTalk Server 2002 implementations are migrated to BizTalk Server 2006, the group will retire the BizTalk Server 2002 implementations.

The e*BIS group calculated that by using 64-bit servers running BizTalk Server 2006, the group can reduce the number of servers in its BizTalk Server environment from five processing servers and eight SQL Server back-end servers to three processing servers running BizTalk Server 2006 and two back-end servers (configured in an active/passive server cluster) running SQL Server 2005.

Also, the e*BIS group determined that the three 64-bit BizTalk Server 2006 processing servers give the group enough increased capacity in its BizTalk Server environment to preclude the need to consider scaling out.

Note: The e*BIS group considers it best to scale out its BizTalk Server environment by adding more processing servers to the BizTalk Server group, instead of scaling up by adding more RAM or CPUs to the individual servers. Scaling out gives the group a higher processor-to-RAM ratio, in addition to a more effective workload balance in the BizTalk Server environment.

Based on the results that the e*BIS group gathered during the stress testing of BizTalk Server 2006, the group determined that the 64-bit servers running BizTalk Server 2006 give the group approximately 40 percent to 50 percent more available processing power to work with before the group must consider adding any more processing servers.

Best Practices

Because of the critical nature of its BizTalk Server implementation, the e*BIS group spent a lot of time testing BizTalk Server 2006 with the various application feeds that Microsoft depends on to run its business. Furthermore, the group continues to test application feeds from its BizTalk Server 2002 implementation in the BizTalk Server 2006 environment. Because the group has spent so much time running BizTalk Server 2006 through the development cycle, the group has gained much useful experience with BizTalk Server 2006. This experience has led to a list of best practices that other organizations can use to help maximize the performance and manageability of BizTalk Server 2006. These best practices are as follows:

• Optimize the Per Host Throttling settings
  During the initial testing of BizTalk Server 2006, the e*BIS group left BizTalk Server 2006 Per Host Throttling settings at their default values to develop a baseline performance standard. However, because the default values for Per Host Throttling are generally conservative, the group later optimized these values to increase performance in its 64-bit production environment.

• Perform positive smoke tests on all assemblies, and do not include custom components
  The e*BIS group performed a test run on all application feeds using known valid data with known expected positive results to ensure all assemblies were deployed, configured, and functioning correctly.

• Perform negative smoke tests on all assemblies and include custom components
  The e*BIS group performed a negative test run on all application feeds to make sure that BizTalk Server 2006 generated the correct error messages when processing the failed messages of each message type.

• Perform a full gateway test
  Because the e*BIS group has many legacy feeds and customized feeds in its BizTalk Server environment, the group performed a test that included all of the different types of messaging feeds that exist in its production environment. Not only did this test ensure that no issues existed in BizTalk Server 2006, but the test also provided the group with a control dataset.

  The group then performed the same test again, but this time with custom components running in the BizTalk Server 2006 environment. As a result of these second tests, the group discovered an incompatibility between BizTalk Server 2006 and one of the group's custom tracking programs. This test enabled the group to resolve this issue before it implemented BizTalk Server 2006 in its production environment.

Conclusion

The e*BIS group's BizTalk Server environment is not only critical to the production of Microsoft's Xbox system, but it also acts as the hub between internal and external business-to-business communications at Microsoft. After significant testing, the group found that the improvements and features available in BizTalk Server 2006 warranted a complete migration from the group's existing BizTalk Server environment to a BizTalk Server environment running the beta version of BizTalk Server 2006.

Because of its greater support for flat file locations and 64-bit computing, BizTalk Server 2006 was used by the e*BIS group to create a BizTalk Server environment that has a smaller server footprint and that needs significantly fewer supporting applications. Server consolidation has saved the group tens of thousands of dollars, and the retirement of most of the supporting applications necessary to the BizTalk Server 2002 and BizTalk Server 2004 environments promises to save several hundred thousand dollars each year in support costs. However, the group also experienced an additional benefit that is not easily quantified monetarily: the ease of operation and day-to-day maintenance of the BizTalk Server 2006 environment. By using the functionality available in the BizTalk Server 2006 Administration Console, the group operations team can now troubleshoot issues in half the time than was previously necessary.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase