Install BizTalk Server 2010 and BAM in a Multi-Computer Environment

Install BizTalk Server 2010 and BAM in a Multi-Computer Environment

  

Microsoft Corporation

Published September 2010




Copyright


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.


Installing BizTalk Server 2010 and BAM in a Multi-Computer Environment

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:

  • Detailed installation procedures
  • Descriptions of BizTalk Server features and dependencies
  • Details of BizTalk Server basic configuration settings
  • Software and hardware requirements
  • CAB file redistributable component list

Installation for High Availability

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.

Installation for Separate Runtime and Administration

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:

  • SQL Server Agent must be running on all computers that are hosting BizTalk Server MessageBox databases. This is required if you want to track message bodies in the BizTalk Server Messaging engine.
  • When you run the BizTalk Server Configuration Wizard, you must create an Analysis Services database.
  • Using the BizTalk Tracking database with SQL Server 2008 R2/2008 SP1 Analysis Services is not supported.
  • Using named instances of SQL Server 2008 R2/2008 SP1 Analysis Services is not supported.

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.

Installing and configuring Distributed Transaction Coordinator

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).

Considerations for using DTC in a BizTalk Server environment

  • All BizTalk servers and SQL Servers in a group must have the same remote procedure call (RPC) authentication level applied. The DTC proxy may not correctly authenticate DTC when the computers are running on different operating systems, are joined to workgroups, or are in different domains that do not trust each other. For more information, see MSDTC Fails to Mutually Authenticate (http://go.microsoft.com/fwlink/?LinkId=54805) in the DTC Administrator's Guide.
  • You must open the required ports for DTC and RPC if you have a firewall. For more information, see Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall (http://go.microsoft.com/fwlink/?LinkId=61914).
  • To ensure that the DTC settings are correct, use the DTC testing tools DTC Ping, available for download at How To Troubleshoot MS DTC Firewall Issues (http://go.microsoft.com/fwlink/?LinkId=61915).
  • For general information about troubleshooting problems with MSDTC, see Troubleshooting Problems with MSDTC (http://go.microsoft.com/fwlink/?LinkID=101609).

Considerations for Using SQL Server

This section describes considerations for using SQL Server in a multicomputer installation of BizTalk Server.

Considerations when SQL Server Is Installed on a Remote Computer

The following conditions apply regarding remote computers.

  • SQL Server Client Tools must be installed on the local computer when SQL Server is remote. The SQL Server Client Tools install the client libraries required to communicate with the remote instance of SQL Server. The version of the SQL Server Client tools on the local computer must be the same version that is installed on the remote SQL Server.
  • SQL Server OLAP client must be installed on the local computer if you plan to use Analysis Services remotely.
  • The remote SQL Server must be running during BizTalk Server configuration.
  • The TCP and UDP ports you specified during the SQL Server setup process must be open during BizTalk Server configuration.
  • Named instances of SQL Server 2008 Analysis Services are not supported.

Supported SQL Server Topologies

The following are the supported configurations for using SQL Server 2008 R2/2008 SP1 with BizTalk Server 2010:

Location of SQL Server in relation to BizTalk Server 2010 Supported
Local SQL Server 2008 R2/2008 SP1 only Yes
Remote SQL Server 2008 R2/2008 SP1 only Yes

How to maintain and troubleshoot BizTalk Server databases

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).

Business Activity Monitoring (BAM)

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:

  • Presentation and tools
  • Web services or processing
  • Database or platform services

Each of these layers and its relation to the installation process is described in the following table. 

Layer What it does Examples Where installed
Presentation and Tools Provides front-end services to business users and developers. Displays data, allows business users and developers to define and manage templates and profiles, among other functions. Office Excel, BAM Portal. Excel, management tools, and custom user interfaces are installed on the business user's or developer's workstation. The BAM portal and custom web applications built on the BAM infrastructure are installed on a server.
Web Services and Processing Link the presentation and database layers; implementation of business rules and processes; data aggregation and analysis. Windows SharePoint Services (WSS), Trading Partner Management Web Service, BAM Management Web Service, and the BizTalk Server engine. On a server configured with IIS, SQL Notification service, and possibly custom web services depending on the application. The BizTalk host services may also be installed on this server, or on a separate server in multiple computer configurations having three or more computers.
Database and Platform Services Data storage and retrieval; security and authentication; networking; operating system functions SQL Server, Windows Server, Enterprise Single Sign-On (SSO),and fail-over and NLB clustering On a server running Windows Server, SQL Server. For performance reasons this server typically does not run the BizTalk host services.

Installing BAM

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.

Run-time Environment Design-time Environment Usage-time Environment
A basic BizTalk Server 2010 runtime environment may include the following servers:
  • BizTalk Server 2010
  • SQL Server 2008 R2/2008 SP1
  • BizTalk BAM Server
  • Web Server
There are three roles involved during the BAM development and deployment process. These are as follows:
  • Business analyst
  • Business administrator
  • Application developer
After a BAM solution is implemented and deployed, business end-users can view the reports generated by various reporting tools. These tools include:
  • Bam Portal
  • SQL Server Reporting Services
  • Microsoft PerformancePoint Monitoring Server
  • Custom BAM reporting applications

The following table describes the available BAM components to be installed.

Category BAM Component Purpose
Portal Components Business Activity Monitoring Selecting the Business Activity Monitoring component installs the necessary software that gives business users a real-time view of their heterogeneous business processes, enabling them to make important business decisions.
Additional Software BAM Alert Provider for SQL Notification Services Selecting the BAM Alert Provider for SQL Notification Services component installs the necessary software that enables Microsoft BizTalk Server 2010 to provide Business Activity Monitoring (BAM) alerts
  BAM Client Selecting the BAM Client component installs the necessary client-side software that allows business users to work with the Business Activity Monitoring feature of Microsoft BizTalk Server 2010.
  BAM-Eventing Select the BAM-Eventing Support component to install necessary software for the BAM-Eventing Interceptors for Windows Workflow Foundation and Windows Communication Foundation. Selecting this component also installs the BAM Event API that is used to send events to the BAM database from custom applications. BAM-Eventing Support is part of the Business Activity Monitoring feature in Microsoft BizTalk Server 2010.

Configuring BAM

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.

Installing and Configuring SQL Server for BAM

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:

  • SQL Server Analysis Services (SSAS)
  • SQL Server Integration Services (SSIS)
  • SQL Server Notification Services (SSNS).

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

  1. Open a Command Prompt
  2. Change directory to %ProgramFiles%\Microsoft SQL Server\100\DTS\Binn
  3. Run the following command: notepad MsDtsSrvr.ini.xml
  4. In Notepad, update the text inside the "<ServerName>" tag to the host name of the SQL Server
  5. In Notepad, save the changes.
  6. From the Command Prompt, execute the following command: net stop MsDtsServer
  7. From the Command Prompt, execute the following command: net start MsDtsServer

Configuring BAM Primary Import, BAM Archive, BAM Star Schema, BAM Analysis, and BAM Notification Services Application databases

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

BAM Feature Feature configuration BizTalk Server SQL Server
BAM Tools BAM Primary Import Tables and BAM Archive database ADOMD .NET 10SQL Server 2008 R2/2008 SP1 Integration Services SQL Server 2008 R2/2008 SP1
BAM Tools Enable Analysis Services for BAM aggregations SQL Server 2008 R2/2008 SP1 Integration Services SQL Server 2008 R2/2008 SP1 Analysis Services
BAM Notification Services Application Database Enable Notification Services for BAM alerts SQL Server 2005 Notification Services Engine Components N/A

  Note

The service account used for the OLAP service should have db_datareader permissions on the BAM Star Schema database.

Notification Services Roles

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:

  • AggregationEventProvider.dll should be installed on the computer hosting the Provider role. This .dll file is installed when you install the BAM Alerts Aggregate Event Provider during the installation of BizTalk Server 2010. The BAM Alerts Aggregate Event Provider is present if the BizTalk Runtime, Administration Tools, or Developer Tools and SDK are installed.
  • EmailNotification.xslt and FileNotification.xslt are required on the computer hosting the Distributor role. You can copy them from the following path on an existing computer running BizTalk Server 2010: <System Drive>:\Program Files\Microsoft BizTalk Server 2010\Tracking
  • You must update the Notification Services Application definition file (.adf file) with the exact location of the .xslt files on the computer hosting the Distributor role.

 To update the Application definition file (.adf file)

  1. On the computer where BizTalk Server 2010 is installed, open the Notification Services command prompt.
  2. Browse to <System Drive>:\Program Files\Microsoft BizTalk Server 2010\Tracking.
  3. Execute ProcessBamNsFiles.vbs to create the initial .adf file.
  4. Modify the .adf file with the path to the .xslt file.
  5. Execute ProcessBamNsFiles.vbs again to update the .adf file.
  6. Restart the BAMAlerts NT service.
BAM Scale-Out Alerts Topology

If you are upgrading your existing BAM scale-out alerts topology to BizTalk Server 2010 then do the following steps on each server:

  1. Stop the Notification Service and then unregister an instance of Notification Service:
    1. Click Start, click Programs, click Microsoft SQL Server 2005, click Configuration Tools and then click Notification Services Command Prompt.
    2. At the command prompt, type: net stop NS$<instance_name>. For example net stop NS$BamAlerts.
    3. 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.

  2. 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).

  3. To migrate your BAM databases based on the version of SQL Server you are upgrading from, run the migration database command bm.exe program located in the BizTalk Server Tracking folder. For example if SQL Server 2005 is upgraded to SQL Server 2008 R2\2008 SP1, run the following at the command prompt with administrative credentials: bm.exe migrate-sql -From:sql2005 -To:sql2008 -NSUser:<username>.
  4. Reregister the Notification Service on all the servers except on the one where the migration (bm.exe) program is being run.
    1. Click Start, click Programs, click Microsoft SQL Server 2005, click Configuration Tools, and then click Notification Services Command Prompt.Click Start, click Programs, click Microsoft SQL Server 2005, click Configuration Tools, and then click Notification Services Command Prompt.
    2. 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.

  5. Validate the BAM alerts: Open the Notification Services Command Prompt and type: nscontrol.exe status -name BAMAlerts -server <NS DB Server>.

BAM Portal

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.

Configuring Multiple BizTalk Groups to Reference a Single BAM Database

 To share the BAM databases across multiple BizTalk groups

  1. Configure the first BizTalk group with the BAM features. This includes BAM tools, the BAM Analysis database, BAM alerts, and the BAM portal.
  2. When configuring the subsequent BizTalk groups, do the following in the BizTalk Server Configuration Wizard:
    1. Select BAM Tools and then select the Enable Business Activity Monitoring tools and Enable Analysis Services for BAM aggregations check boxes.
    2. Change the Server Name and Database Name of the BAM data stores to match the same names used when configuring the first BizTalk group.
    3. Select BAM Alerts and then select the Enable SQL Notification Services for BAM alerts check box.
    4. Change the service account for BAM Alerts to have a blank user name and password.
    5. Change the BAM Alerts SMTP Server, BAM Alerts File Location, SQL Server for Alerts Database, and Prefix for Alerts Database Names to match the same names used when configuring the first BizTalk group.

       Note

      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.

  3. Select BAM Portal, and then select the Enable BAM Portal check box.

     Note

    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.

  4. Click Apply Configuration.

BAM Client

The following are the software requirements when using the BAM client:

  • For the Web client, you need Internet Explorer 8.0 or later and Office Web Components 11 version 4.0 or later.
  • If you are running the Web client and using SQL Server 2008 R2/2008 SP1 Analysis Services, you must install Microsoft SQL Server 2008 R2/2008 SP1 Analysis Services 10.0 OLE DB Provider.
  • For the Excel client, you need Microsoft Excel® 2010/2007 and the BAM Excel Add-in provided with BizTalk Server 2010.

Enabling BAM Add-in from Excel

To enable BAM add-in from excel, see Add the BAM Add-In to Microsoft Office Excel (http://go.microsoft.com/fwlink/?LinkID=147349).

Windows Groups and Service Accounts

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.

  • In a multicomputer environment, BizTalk Server supports only domain groups and domain service accounts.
  • BizTalk Server 2010 supports only <NetBIOSDomainName>\<User> name formats for Windows groups and service accounts.
  • BizTalk Server supports only Active Directory domain groups and user accounts in multicomputer configurations. Domain groups include Domain Local groups, Global groups, and Universal groups, which are supported in both single computer and multicomputer environments.
  • In general, Domain Local Groups are not recommended because their use requires that all of the servers, including SQL Servers, in the BizTalk Server infrastructure must belong to the same domain. This consideration does not apply to small networks where all of the servers and user accounts reside in a single domain. For more information about Active Directory groups, see "Group Scope" in the Windows Server 2008 product Help at http://go.microsoft.com/fwlink/?linkid=93663.
  • Built-in accounts such as NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\SERVICE, NT AUTHORITY\SYSTEM, and Everyone are not supported when you install and configure BizTalk Server 2010 in a multicomputer environment.
  • The user running the BizTalk Server configuration must belong to the following user groups: the Administrators group on the local computer, the System Administrators group on the SQL Server computer, the domain group used for the BizTalk Server Administrators group, and the domain group used for the SSO Administrators group.
  • Whenever possible, you should use the default account names created during setup. The BizTalk Server setup program automatically configures installed components to use the default accounts. Using the default names simplifies setup and configuration, but it is not always possible. For example, there may be multiple BizTalk Server groups within an Active Domain forest. In this situation the account names must be modified to avoid conflicts. Or, your organization might use naming standards for service and user accounts, and you need to change the default accounts to conform to the standard.

Windows Groups Used In BizTalk Server

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.

Group Group Description Membership SQL Server Roles or Database Roles
SSO Administrators Administrator of the Enterprise Single Sign-On (SSO) service. For more information about SSO accounts, see How to Specify SSO Administrator and Affiliate Administrators Accounts (http://go.microsoft.com/fwlink/?LinkID=89383). Contains service accounts for Enterprise Single Sign-On service. Contains users/groups that need to be able to configure and administer BizTalk Server and SSO service.Contains accounts used to run BizTalk Configuration Manager when configuring SSO master secret server.

db_owner SQL Server Database Role for the SSO service.

securityadmin SQL Server Role for the SQL Server where SSO is located.

SSO Affiliate Administrators Administrators of certain SSO affiliate applications. Can create/delete SSO affiliate applications, administer user mappings, and set credentials for affiliate application users. Contains no service accounts. Contains account used for BizTalk Server Administrators None
BizTalk Server Administrators Has the fewest privileges necessary to perform administrative tasks. Can deploy solutions, manage applications, and resolve message processing issues. To perform administrative tasks for adapters, receive and send handlers, and receive locations, the BizTalk Server Administrators must be added to the Single Sign-On Affiliate Administrators. For more information, see Managing BizTalk Server Security (http://go.microsoft.com/fwlink/?linkid=110476). Contains users/groups that need to be able to configure and administer BizTalk Server.

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.

BizTalk Server Operators Has a low privilege role with access only to monitoring and troubleshooting actions. Contains user/groups that will monitor solutions. Contains no service accounts. BTS_OPERATORS SQL Server Database Role in the following databases: BizTalkDTADb, BizTalkEDIDb, BizTalkMgmtDb, BizTalkMsgBoxDb, BizTalkRuleEngineDb.
BizTalk Application Users The default name of the first In-Process BizTalk Host Group created by Configuration Manager. Use one BizTalk Host Group for each In-Process host in your environment. Includes accounts with access to In-Process BizTalk Hosts (hosts processes in BizTalk Server, BTSNTSvc.exe). Contains service accounts for the BizTalk In-Process host instance in the host that the BizTalk Host Group is designated for.

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.

BizTalk Isolated Host Users The default name of the first Isolated BizTalk Host Group created by Configuration Manager. Isolated BizTalk hosts not running on BizTalk Server, such as HTTP and SOAP. Use one BizTalk Isolated Host Group for each Isolated Host in your environment. Contains service accounts for the BizTalk Isolated host instance in the host that the Isolated BizTalk Host Group is designated for. BTS_HOST_USERS SQL Server Database Role in the following databases: BizTalkMgmtDb, BizTalkMsgBoxDb, BizTalkRuleEngineDb, BizTalkDTADb, BAMPrimaryImport.
EDI Subsystem Users Has access to the EDI database. Contains service accounts for BizTalk Base EDI service. EDI_ADMIN_USERS SQL Server Database Role in the BizTalkEDIDb database.
BAM Portal Users Has access to BAM Portal Web site. Everyone group is used for this role by default.Contains no service accounts. None
BizTalk SharePoint Adapter Enabled Hosts Has access to Windows SharePoint Services Adapter Web Service. Contains service accounts for the BizTalk host instance to be able to call the SharePoint Adapter. None

User and Service Accounts Used In BizTalk Server

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.

User User Description Group Affiliation SQL Server Roles or Database Roles
Enterprise Single Sign-On Service Service account used to run Enterprise Single Sign-On Service, which accesses the SSO database. SSO Administrators None
BizTalk Host Instance Account Service account used to run BizTalk In-Process host instance (BTNTSVC). BizTalk Application Users None
BizTalk Isolated Host Instance Account Service account used to run BizTalk Isolated host instance (HTTP/SOAP). BizTalk Isolated Host UsersIIS_WPG None
Rule Engine Update Service Service account used to run Rule Engine Update Service, which receives notifications to deployment/undeployment policies from the Rule engine database. None RE_HOST_USERS SQL Server Database Role in the BizTalkRuleEngineDb.
BizTalk Base EDI service

Service account used to run BizTalk Base EDI service, which processes EDI documentations.

 Important

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.

EDI Subsystem UsersIn-Process BizTalk Host Groups hosting the Base EDI adapter. None
BAM Notification Services User Service account used to run BAM Notification Services, which accesses the BAM databases. SQLServer2005NotificationServices
User$<ComputerName>

NSRunService SQL Server Database Role in the following databases:BAMAlertsApplication and BAMAlertsNSMain.

BAM_ManagementNSReader SQL Server role for the BAMPrimaryImport database.

BAM Management Web Service User User account for BAM Management Web service (BAMManagementService) to access various BAM resources. BAM Portal calls BAMManagementService with the user credentials logged on the BAM Portal to manage alerts, get BAM definition XML and BAM views. IIS_WPG

NSSubscriberAdmin SQL Server Database Role in the following databases:BAMAlertsApplication, BAMAlertsNSMain. BAM_ManagementWS

SQL Server role for the BAMPrimaryImport database.

BAM Application Pool Account Application pool account for BAMAppPool, which hosts the BAM Portal Web site. IIS_WPG None

 Important

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.

Databases Used by BizTalk Server

The following is the list of SQL Server databases used in BizTalk Server 2010.

Data store name Default database name Volume Growth Description
SSO Database SSODB Low Low This Enterprise Single Sign-On credential database securely stores the user name and password.
BizTalk Management Database BizTalkMgmtDb Low Low This database is the central meta-information store for all instances of BizTalk Server.
BizTalk MessageBox Database BizTalkMsgBoxDb High Medium This database is used by the BizTalk Server engine for routing, queuing, instance management, and a variety of other tasks.

 Note

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.

BizTalk Tracking Database BizTalkDTADb High High This database stores business and health monitoring data tracked by the BizTalk Server tracking engine.
Rule Engine Database BizTalkRuleEngineDb Low Low This database is a repository for policies, which are sets of related rules and vocabularies. Vocabularies are collections of user-friendly, domain-specific names for data references in rules.
BizTalk Base EDI Database BizTalkEDIDb Low Low This database stores state for the electronic data interchange (EDI) adapter. 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.
BAM Primary Import Database BAMPrimaryImport Medium Medium This is the database where BAM collects raw tracking data.
BAM Archive Database BAMArchive Medium Medium This database archives old business activity data. Create a BAM Archive database to minimize the accumulation of business activity data in the BAM Primary Import database.
BAM Star Schema Database BAMStarSchema Medium Medium This database contains the staging table, and the measure and dimension tables.
BAM Notification Services Application database BAMAlertsApplication Medium Medium This database contains alert information for BAM notifications. For example, when you create an alert using the BAM portal, entries are inserted in this database specifying the conditions and events to which the alert pertains, as well as other supporting data items for the alert.
BAM Notification Services Instance database BAMAlertsNSMain Medium Medium This database contains instance information specifying how the notification services connect to the system that BAM is monitoring.

List of Windows SharePoint Services Databases

The following is the list of SQL Server databases used by Windows SharePoint Services.

Data store name Default database name Volume Growth Description
Windows SharePoint Services configuration database User-defined Low Low This database contains all of the global settings for the server.
Windows SharePoint Services content database User-defined Medium Medium This database contains all of the site content, such as list items and documents.

Installing BizTalk Server in a Multiple Server environment

  1. Install Active Directory Domain Services - The first step required to install BizTalk Server into a multiple server environment is to install Active Directory domain services for the various BizTalk Server groups and accounts required by the environment. If an Active Directory domain is not already available for this purpose then follow the guidance in the AD DS Installation and Removal Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=160742) to create the prerequisite Active Directory domain services required to install BizTalk Server into a multiple server environment.

     Important

    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.

  2. Install Multiple Instances of SQL Server as needed - If your load requirements dictate that you will need to install multiple MessageBox databases or that you will need to spread the BizTalk Server I/O load over multiple SQL Server instances then install additional SQL Server instances as required. For more information about performance testing your BizTalk Server environment see the BizTalk Server Performance Optimizations Guide (http://go.microsoft.com/fwlink/?LinkID=150492), and for more information about optimizing BizTalk Server database performance see the BizTalk Server Database Optimization whitepaper (http://go.microsoft.com/fwlink/?LinkID=153594).
  3. Install Multiple BizTalk Server computers into your BizTalk Server Group as needed - If your load requirements dictate that you will need to install multiple BizTalk Server computers into your BizTalk Server group then you can do so with the Enterprise Edition of BizTalk Server and thereby scale out your processing requirements across multiple BizTalk Server computers. For a table that lists each of the BizTalk Server Editions and their capabilities see the BizTalk Server Editions page (http://go.microsoft.com/fwlink/?LinkID=185239).

     Important

    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.

Considerations for clustering BizTalk Server in a Multiple Server environment

  • Clustering MSDTC - Because the Microsoft Distributed Transaction Coordinator (MSDTC) is a central component of any BizTalk Server environment, it is recommended that the MSDTC should be clustered if other components of the BizTalk Server environment are also clustered. For more information about how to cluster the MSDTC see How to Cluster MSDTC (http://go.microsoft.com/fwlink/?LinkId=189514).
  • 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.

  • Configure the Enterprise Single Sign-On Master Secret Server as a cluster resource - Because a failure of the Enterprise Single Sign-On Master Secret Server can cause a system-wide failure of the BizTalk Server environment, it is recommended that the Enterprise Single Sign-On Master Secret Server is configured for high availability/fault tolerance by configuring the Master Secret Server as a cluster resource. Because the Master Secret Server is not a particularly resource intensive component of a BizTalk Server environment, it is generally recommended that the Master Secret Server can be clustered on the same cluster nodes as the SQL Server instance(s). For more information about configuring the Enterprise Single Sign-On Master Secret Server as a cluster resource see How to Cluster the Master Secret Server (http://go.microsoft.com/fwlink/?LinkId=189511).
  • Configuring a BizTalk host as a cluster resource - Because running multiple instances of a BizTalk Server host will provide high availability/fault tolerance, configuration of a BizTalk host as a cluster resource is generally not recommended except for particular circumstances. Under certain conditions, configuration of a BizTalk host as a cluster resource is a recommended practice, such as for accommodating high availability/fault tolerance or for providing ordered delivery for certain BizTalk Server adapters. For more information about when it is appropriate to configure a BizTalk host as a cluster resource see Considerations for Running Adapter Handlers within a Clustered Host (http://go.microsoft.com/fwlink/?LinkID=151284). For more information about how to configure a BizTalk host as a cluster resource see How to Configure a BizTalk Host as a Cluster Resource (http://go.microsoft.com/fwlink/?LinkId=189512).
  • Clustering Message Queuing - For information about how to cluster Message Queuing, see How to Cluster Message Queuing (http://go.microsoft.com/fwlink/?LinkId=189516).
  • Clustering the File System - For information about how to cluster the File System, see How to Cluster the File System (http://go.microsoft.com/fwlink/?LinkId=189517).

Using SCOM to Monitor BizTalk Server

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).

See Also

Read suggested related topics:

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.
Sort by: Published Date | Most Recent | Most Useful
Comments
  • Excellent guide for installing BizTalk in multi-server environment. Definitely need to be studied before deploying BizTalk.

  • The entry point for any BAM implementation. Thanks!