Microsoft Corporation
Published September 2010
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
® 2010 Microsoft Corporation. All rights reserved.
Microsoft, BizTalk, Excel, InfoPath, Internet Explorer, SharePoint, SQL Server, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.
Installation for High Availability
Installation for Separate Runtime and Administration
Installing and configuring Distributed Transaction Coordinator
Considerations for using DTC in a BizTalk Server environment
Considerations for Using SQL Server
Considerations when SQL Server Is Installed on a Remote Computer
Supported SQL Server Topologies
How to maintain and troubleshoot BizTalk Server databases
Business Activity Monitoring (BAM
Installing BAM
Configuring BAM
Installing and Configuring SQL Server for BAM
BAM Portal
Configuring Multiple BizTalk Groups to Reference a Single BAM Database
BAM Client
Enabling BAM Add-in from Excel
Windows Groups and Service Accounts
Windows Groups Used In BizTalk Server
User and Service Accounts Used In BizTalk Server
Databases Used by BizTalk Server
Installing BizTalk Server in a Multiple Server environment
Considerations for clustering BizTalk Server in a Multiple Server environment
Using SCOM to Monitor BizTalk Server
See Also
There are many things to consider when planning a multi-computer installation of Microsoft® BizTalk® Server. Often the network infrastructure already exists and BizTalk Server must coexist with other network applications. This guide describes some of the considerations that apply to the various parts of a BizTalk Server and Business Activity Monitoring (BAM) installation in a multi-computer, distributed deployment. This information will help you plan the installation and configuration of BizTalk Server 2010 and Business Activity Monitoring (BAM) and the applications and components on which it depends.
Documentation Feedback and Updates
Microsoft values your feedback. To send feedback and comments about this guide to the documentation team, click here.
To ensure that you are reading the most up-to-date information, you can download the latest version of this document from BizTalk Server 2010 Installation and Upgrade Guides (http://go.microsoft.com/fwlink/?LinkID=191321). The single server installation guides are also available at this location. The single server installation guides contain important procedures and additional background information that is not duplicated in this document. For example, the following categories of information are discussed in detail in the single server installation guides:
BizTalk Server provides a high availability solution using network load balancing (NLB) clustering and failover clustering. A high availability solution helps to minimize the downtime in case of a hardware or software failure. NLB and failover clusters complement each other in complex architectures. NLB clustering is used for load balancing requests between front-end Web servers. Failover clustering provides high availability for the BizTalk Server in-process hosts, the Enterprise Single Sign-On Master Secret Server and BizTalk Server databases.
For more information about using BizTalk Server with Windows Server clusters, see Improving Fault Tolerance in BizTalk Server by Using a Windows Server 2008 failover cluster or Windows Server 2003 server cluster.
BizTalk Server supports a variety of installation scenarios in the production environment. For example, you can install, configure, and deploy a runtime-only installation on one computer and an administration tools-only installation on a second computer.
During an Administration tools-only installation, the following components are installed: BizTalk Administration console, BM.exe, and BTSDeploy.exe. The following considerations apply to an Administration Tools-only installation of BizTalk Server:
To install only Administration tools for BizTalk Server, select only Administration Tools during Setup. After the installation is complete, open the custom configuration manager and join an existing Enterprise Single Sign-On (SSO) system and BizTalk group.
Before installing and configuring BizTalk Server 2010 in a multicomputer environment, you must enable network DTC access and network COM+ access on all computers running Windows Server 2008 R2/SP2 or later where you will install BizTalk Server or any remote SQL Server instances that BizTalk Server will connect to. To install and configure network DTC access and network COM+ access, see BizTalk Server 2010 Installation and Upgrade Guides (http://go.microsoft.com/fwlink/?LinkID=191321).
This section describes considerations for using SQL Server in a multicomputer installation of BizTalk Server.
The following conditions apply regarding remote computers.
The following are the supported configurations for using SQL Server 2008 R2/2008 SP1 with BizTalk Server 2010:
For information about how to maintain and troubleshoot BizTalk Server databases, see Microsoft Knowledge Base article How to maintain and troubleshoot BizTalk Server databases (http://support.microsoft.com/kb/952555).
BizTalk Server 2010 provides several tools for information workers, among them BAM. A basic understanding of the component architecture for BAM will help you plan your BizTalk Server installation to effectively utilize the server resources available to you.
Business Activity Monitoring (BAM) is a collection of tools that allow you to manage aggregations, alerts, and profiles to monitor relevant business metrics (known as Key Performance Indicators or KPIs). BAM is a module in BizTalk that gives you end-to-end visibility into your business processes, which provides accurate information about the status and results of various operations processes and transactions so that you can address problem areas and resolve issues within your business. For more information about BAM life cycle, see the Business Activity Monitoring (BAM) poster (http://go.microsoft.com/fwlink/?LinkId=120003).
BAM consists of three layers:
Each of these layers and its relation to the installation process is described in the following table.
It is easier to understand BAM, the installation and configuration process, and dependencies by splitting into three BizTalk Server environments described in the following table.
The following table describes the available BAM components to be installed.
To configure BAM components, open BizTalk Server Configuration and choose Custom Configuration. Custom configuration allows you to configure the server using advanced configuration options. With custom configuration, you can selectively configure or unconfigure each feature. For information on customizing your configuration, see Custom Configuration (http://go.microsoft.com/fwlink/?LinkID=195336) in the BizTalk Server 2010 Help.
For BizTalk Server 2010 and BAM, you must install SQL Server 2008 R2/2008 SP1. To install SQL Server, see BizTalk Server 2010 Installation and Upgrade Guides (http://go.microsoft.com/fwlink/?LinkID=191321).
In addition to Database Services that are required by the BizTalk Server core functions, BAM also requires the following:
Configure SQL Server Integration Services (SSIS). If your SQL Server is installed on a computer other than the one where BizTalk Server is installed, then you must configure SSIS. In this task, you configure the SSIS to use the msdb database on a remote SQL Server.
By default, the Integration Services service is configured to manage packages that are stored in the msdb database in a local, default instance of Database Engine. To manage packages that are stored in a named instance or a remote instance of the Database Engine, or in multiple instances of the Database Engine, you have to modify the configuration file. For example, you can create additional root folders of the type, SqlServerFolder, to manage packages in the msdb database of multiple instances of the Database Engine.You can also modify the configuration file to allow packages to continue running if the service stops, to display additional root folders in Object Explorer, or to specify a different folder or additional folders in the file system to be managed by Integration Services service.
The registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTS\ServiceConfigFile specifies the location and name for the configuration file that Integration Services service uses. The default value of the registry key is C:\Program Files\Microsoft SQL Server\100\DTS\Binn\ MsDtsSrvr.ini.xml. You can update the value of the registry key to use a different name and location for the configuration file.
To configure the Integration Services
You can configure BAM Primary Import, BAM Archive, BAM Star Schema, BAM Analysis, and BAM Notification Services Application databases on different computers. The following are the software requirements when SQL Server is installed on a computer other than the one where BizTalk Server is installed:
Remote SQL Server 2008 R2/2008 SP1
Note
The service account used for the OLAP service should have db_datareader permissions on the BAM Star Schema database.
You can install SQL Server Notification Services in a multicomputer environment where the Provider, Generator, and Distributor roles of Notification Services are on different computers. The following describes the dependencies in that scenario:
To update the Application definition file (.adf file)
If you are upgrading your existing BAM scale-out alerts topology to BizTalk Server 2010 then do the following steps on each server:
Type the following command to unregister the instance: nscontrol unregister -name BamAlerts.
Unregistering an instance removes the registry entries, removes the NS$instance_name service (if present), and deletes the performance counters for the service.
Upgrade your servers that have Notification Services instances to a higher edition of SQL Server 2005 Notification Services.
Click or navigate to the Feature Pack for Microsoft SQL Server 2005 - December 2008 (http://go.microsoft.com/fwlink/?LinkId=154501).
At the command prompt, type: nscontrol register -name BamAlerts -server <NS DB Server> -service -serviceusername "<NSServiceUserName>" -servicepassword "<NSServicePassword>"
This enables Notification Services to log on to the correct database (this information is maintained in the registry of the service computer by nscontrol).
Important
Remember to use the new Notification Services database server in the -server option when re-registering the service. In addition, you should use the same user name for the new Notification Services service as the old one.
The Portal Components are a set of services used by business people to communicate, collaborate, and reach decisions enabling them to interact, configure, and monitor business processes and workflows. To use this feature, you must also install Internet Information Services (IIS) 7.5/7.0.
To share the BAM databases across multiple BizTalk groups
The same Primary Import Tables (PIT) can be used but with different BAM Archive, BAM Analysis, and Star Schema databases. However, this will affect all groups pointing to the same PIT.
All the fields on this screen are read-only because there is a one-to-one relationship between the BAM Primary Import database and the BAM portal. Multiple BizTalk groups share the same BAM portal when configured against the same BAM databases.
The following are the software requirements when using the BAM client:
To enable BAM add-in from excel, see Add the BAM Add-In to Microsoft Office Excel (http://go.microsoft.com/fwlink/?LinkID=147349).
You must manually create all of the domain groups and accounts before you configure BizTalk Server in a multicomputer installation. The following information will be useful in creating these groups and accounts.
The following table lists the Windows groups and their membership used by BizTalk Server. It also identifies the SQL Server Roles or Database Roles for the group.
db_owner SQL Server Database Role for the SSO service.
securityadmin SQL Server Role for the SQL Server where SSO is located.
BTS_ADMIN_USERS SQL Server Database Role in the following databases:BizTalkMgmtDb, BizTalkMsgBoxDb, BizTalkRuleEngineDb, BizTalkDTADb, BAMPrimaryImport. db_owner SQL Server Database Role for the following databases:BAMStarSchema, BAMPrimaryImport, BAMArchive, BAMAlertsApplication, BAMAlertsNSMain. NSAdmin SQL Server Database Role in the following databases:
BAMAlertsApplication and BAMAlertsNSMain.
SQL Server Database Role in the following databases:
BizTalkDTADb and BizTalkMgmtDb.
OLAP Administrators on the computer hosting the BAMAnalysis OLAP database.
BTS_HOST_USERS SQL Server Database Role in the following databases:BizTalkMgmtDb, BizTalkMsgBoxDb, BizTalkRuleEngineDb, BizTalkDTADb, BAMPrimaryImport.
BAM_EVENT_WRITER SQL Server Database Role in the BAMPrimaryImport database.
The following table lists the Windows user or service accounts and group affiliations used by BizTalk Server. It also identifies the SQL Server Roles or Database Roles for the accounts.
Service account used to run BizTalk Base EDI service, which processes EDI documentations.
The Base EDI adapter was deprecated in BizTalk Server 2006 R2. The Base EDI adapter can be used in upgrade scenarios, but for new installations of BizTalk Server, use the native EDI and AS2 functionality.
NSRunService SQL Server Database Role in the following databases:BAMAlertsApplication and BAMAlertsNSMain.
BAM_ManagementNSReader SQL Server role for the BAMPrimaryImport database.
NSSubscriberAdmin SQL Server Database Role in the following databases:BAMAlertsApplication, BAMAlertsNSMain. BAM_ManagementWS
SQL Server role for the BAMPrimaryImport database.
For more information about Windows groups and service accounts used in BizTalk Server 2010, see "Windows Groups and User Accounts in BizTalk Server" in BizTalk Server 2010 Help.
The following is the list of SQL Server databases used in BizTalk Server 2010.
The Auto update statistics option, the Auto create statistics option, and the Parallelism setting are purposely turned off in the SQL Server 2005 or SQL Server 2008 database instance that hosts the BizTalk Server 2010 BizTalkMsgBoxDB database. Do not enable these settings.
List of Windows SharePoint Services Databases
The following is the list of SQL Server databases used by Windows SharePoint Services.
The BizTalk Server groups described in the table User and Service Accounts Used In BizTalk Server must be created manually when installing BizTalk Server into a multiple server environment.
Many of the Enterprise level features of BizTalk Server such as clustering, adding multiple servers to a group, and native 64-bit processing are only available with the Enterprise edition of BizTalk Server.
Install SQL Server Failover Clustering - To provide high availability/fault tolerance for the BizTalk Server databases it is highly recommended that the BizTalk Server databases are installed on a SQL Server failover cluster. For information on installing SQL Server 2008 on a failover cluster see Getting Started with SQL Server 2008 Failover Clustering (http://go.microsoft.com/fwlink/?LinkID=156820). For information on installing SQL Server 2005 on a failover cluster see Failover Clustering (http://go.microsoft.com/fwlink/?LinkID=133036).
Once SQL Server has been configured for high availability/fault tolerance then the clustered instance of SQL Server can be referenced just as any other instance of SQL Server for purposes of BizTalk Server configuration.
The BizTalk Server 2010 Management Pack for Operations Manager provides comprehensive discovery and monitoring of BizTalk Server components and applications that are running in multiple machines. For more information about the BizTalk Server Management Pack and how to use it, see the BizTalk Server 2010 Management Pack Guide (http://go.microsoft.com/fwlink/?LinkID=187909).