Share via

Microsoft BizTalk Accelerator for HIPAA

  • Article

 

Microsoft Corporation

August 2002

Applies to:
    Microsoft® BizTalk® 2002

Summary: How to plan, deploy, and maintain a robust, highly functional, and cost-effective business solution for the electronic transfer of information in accordance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA). (81 pages)

Contents

Introduction
Installation Scope
Deployment Reference Model
Enterprise Deployment Details
Batch Claims Processing Scenario
Secure Online Data Submission Scenario
Known Issues
URL Resources
Appendix 1: Cluster Service Installation Process
Appendix 2: SCSI Drive Installations
Appendix 3: Security Configuration

Introduction

The Deployment Guide for Microsoft® BizTalk® Accelerator for HIPAA is one in a series of guides; others in the series are Architecture, Operations, and Services. Together these guides offer prescriptive architecture guidance to help you plan, deploy, and maintain a robust, highly functional, and cost-effective business solution for the electronic transfer of information in accordance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

Audience

This guide should be read by systems architects, project managers, HIPAA experts, development leads, software developers, and anyone else concerned with planning for and implementing a HIPAA-specific data exchange solution for a health care organization. We assume that you are familiar with business transactions in the United States health care system.

About This Guide

This guide provides specific installation procedures for deploying Accelerator for HIPAA in an enterprise environment to process HIPAA-specific transactions.

Before deploying Accelerator for HIPAA, the entire deployment team should review the list of known issues at the end of this guide. Upon successful deployment, operations personnel should become familiar with the product documentation for Accelerator for HIPAA, Microsoft SQL Server, and BizTalk Server.

This guide is not intended as a substitute for the BizTalk Accelerator for HIPAA documentation or for the Microsoft BizTalk Server 2000 documentation. You should familiarize yourself with these documents before attempting to use BizTalk Accelerator for HIPAA, and use them as a reference for descriptions and discussions of product features.

BizTalk Accelerator for HIPAA addresses only the transaction set standards detailed in the Administrative Simplification section of HIPAA, and this is what we discuss here. The implementation of the HIPAA Security and Privacy requirements will vary widely between organizations, and the permutations are beyond the scope of this document.

As you read this document, note that many of the terms used here are defined in the glossary of the BizTalk Accelerator for HIPAA documentation.

Prerequisites

You should be prepared as follows before considering your solution:

  • Understand the HIPAA implementation guides that are published by Washington Publishing Company (WPC).

  • Use the BizTalk Server and BizTalk Accelerator for HIPAA online Help files for troubleshooting.

  • Understand the basics of Microsoft BizTalk Server:

    BizTalk Orchestration Designer, a visual environment for business process modelling

    BizTalk Editor, which defines business document schemas

    BizTalk Mapper, an Extensible Stylesheet Language Transformation (XSLT) component

    BizTalk Messaging Manager, used to specify and manage business relationships

    BizTalk Server Administration, used to manage queues, transports, and services

    BizTalk Document Tracking, used to track message and schedule activity

  • Have experience in configuring and implementing BizTalk Server in a development environment.

  • Understand the basics of BizTalk Accelerator for HIPAA:

    BizTalk Accelerator for HIPAA parser, a component that translates HIPAA (X12) files into Extensible Markup Language (XML) files

    HIPAA-specific document specifications, BizTalk Server-specific XML schemas that are created by using BizTalk Editor

Installation Scope

While there are many different ways in which to deploy BizTalk Accelerator for HIPAA, this document focuses primarily on deploying it in an enterprise environment. Using this enterprise deployment example as a model, you can modify the appropriate portions of the deployment to suit your particular environment. In addition to the enterprise deployment, this guide also includes information for development, core-medium, and medium deployments in the areas of hardware and software requirements, server and network architecture, and functionality verification.

Concepts and Features

The following table describes the key concepts that will be used in this document.

Concept Description
Deployment architecture Refers to the logical design of a specific deployment. For example, a deployment might consist of a perimeter network (also known as demilitarized zone, or DMZ) and a private intranet zone.
Network architecture Refers to the physical design of a specific deployment. For example, the perimeter network of a specific deployment might consist of one domain controller and three Web servers.
Network Load Balancing Refers to the load balancing feature in Microsoft Windows® 2000 Advanced Server that distributes incoming client requests across multiple Web servers.
Cluster service Refers to the clustering feature in Windows 2000 Advanced Server that provides fault tolerance and high availability.
BizTalk Server cluster Refers to the BizTalk Servers used for XML transformation of catalogs and purchase orders.
SQL Server cluster Refers to the SQL Servers used to store information such as catalogs, purchase orders, and trading partner profiles.
Internet Security and Acceleration (ISA) server Refers to the servers used for securing and caching data.
Domain name servers Refers to the servers used in resolving domain names to IP addresses.

Planning Checklist

Before deploying the solution, you must determine which type of deployment to implement. To identify a suitable deployment architecture, consider the following factors:

  • Expected HIPAA transactions
  • Average number of line items in a transaction
  • Average size of a transaction
  • Number and types of business systems required to integrate the solution to be practical in a production environment

The results of gathering this information should help you identify a suitable deployment architecture. After you determine the deployment architecture, make sure you have the following elements:

  • Required hardware for the deployment
  • Required software and associated licenses
  • High-speed Internet access and fully qualified domain names (FQDN) for the solution site
  • Security policy
  • Hubs
  • External shared disk (for enterprise deployment)
  • Appropriate drives and SCSI cables (for enterprise deployment)

Installing and Deploying the Solution

When deploying Microsoft BizTalk Accelerator for HIPAA, you have a number of options depending on the deployment factors identified in the previous section. Microsoft's developer tools and Windows Server System servers have the advantage of being highly scalable, allowing businesses to start off small and then scale to larger enterprise-level designs with small, incremental investments. This section describes the most typical deployments: provider's office, development, and enterprise.

Physician's office, dentist's office, and development setup

Health care transactions performed by a physician's or dentist's office include eligibility request/response and claim submission. The physician's office, dentist's office, and development setup involves a two-server architecture that serves as a development and testing environment. This deployment architecture has the simplest configuration, yet is robust enough for a solution to be developed and tested on. The development deployment is not supported in production environments.

The following illustration shows the architecture of the development deployment.

Figure 1.

In this deployment architecture, all of the software is installed on the single server, including all of the components for Accelerator for HIPAA. The single server is protected behind a firewall, which can be a hardware firewall or ISA Server. On this firewall, port 80 must be opened for HTTP and port 443 must be opened for HTTPS. After the solution is developed and tested on the development deployment architecture, it can be migrated to one of the other supported deployment architectures.

Small, medium, and large enterprise

Larger providers, payers, and employers in the United States use Enterprise deployment. In the enterprise space, two scenarios will be considered. The first is a batch claims processing scenario and the second is an online data submission scenario. For these scenarios, an enterprise deployment will be described in detail. For more information about the BizTalk Server and Accelerator for HIPAA configuration, review the Architecture Guide. Because the batch claims processing scenario is a subset of the online data submission scenario, the deployment for the batch claims processing scenario will be described first. The second scenario will add additional servers and configuration to this deployment.

Within the enterprise, this guide recommends the scaling up of servers to meet the needs of the small, medium, and large enterprises. This is accomplished by modifying the number of processors on the BizTalk Server and SQL Server clusters. The following table shows the various configurations for the servers that are part of the server clusters.

Enterprise size Number of processors per server
Small 1
Medium 2
Large 4

Besides the number of processors in each server that is running the Cluster service, the configuration remains the same. This gives a simple approach to be able to handle additional demands as transactions increase.

Batch claims processing scenario

The batch claims processing scenario involves five servers. This consists of two 2-server clusters with BizTalk Server and SQL Server, and one server acting as a domain controller. This deployment architecture supports the largest enterprises and addresses additional availability, reliability, scalability, and fault-tolerance concerns.

This architecture consists of servers in a secured intranet behind a firewall, which allows access to the intranet only through specific ports and discards all other requests.

The instances of BizTalk Server and SQL Server in the intranet use the Cluster service to provide fault tolerance. Both BizTalk Server and SQL Server clusters are connected to separate shared disks by using SCSI cables.

Distributing the management and processing of messages across multiple machines can alleviate bottlenecks. A benefit of this architecture is that multiple BizTalk Servers can be used to manage the load. If traffic gets too high, you can add another BizTalk Server.

Deployment Reference Model

This section provides general information about minimum hardware requirements, recommended hardware configuration, and solution components. The reference model presented here is for the medium enterprise scenario. You can adjust your hardware requirements by adding or subtracting processors in the configuration, and use the same installation and deployment steps described in this document.

Before implementing the solution, you should identify the hardware requirements for your particular deployment architecture. All hardware used in the deployment should comply with the Microsoft Hardware Compatibility List (HCL).

Minimum Hardware Requirements

Each server in a deployment should meet the following minimum hardware requirements:

  • 700 MHz or faster Pentium-compatible CPU
  • 512 megabytes (MB) of RAM (256 MB of RAM is adequate for a development environment)
  • 18.0 gigabytes (GB) or better of hard disk space
  • CD-ROM drive
  • 100 megabits or better network adapter card
  • VGA or Super VGA monitor
  • Microsoft Mouse or compatible pointing device

In your production environment, the volume of traffic on your Web site might dictate more stringent hardware requirements for Web servers.

The following table lists the recommended hardware configuration for the physician's office, dentist's office, and development setup.

Server Processor RAM Hard disk space Network adapters
Single Single 700 MHz (or better) 512 MB (or better) 2x18 GB* 1
ISA Server Single 700 MHz (or better) 512 MB (or better) 18 GB 2

*Configure the hard disks as a single 18-GB RAID 1 pair for fault tolerance.

The following table lists the recommended hardware configuration for the enterprise batch deployment.

Server Processor RAM Hard disk space Network adapters
2 BizTalk Servers Dual 933 MHz (or better) 1 GB (or better) 18 GB (or better) 2
Intranet ISA Server Single 500 MHz (or better) 512 MB (or better) 9 GB (or better) 3
2 SQL Servers Dual 933 MHz (or better) 1 GB (or better) 18 GB (or better) 2
2 DC/DNS servers Single 500 MHz (or better) 512 MB (or better) 9 GB (or better) 1
2 shared storage units         14x9 GB* (or better)  

*For the SQL Server storage unit, configure four of the 9 GB SCSI hard disks as a single 27-GB RAID 5 logical drive for the databases, configure two separate sets of four 9 GB as RAID 0 + 1 for the transaction logs (one for InterchangeDTA/InterchangeBTM and one for InterchangeSQ/XLANG), and configure the last two drives as RAID 1 for the cluster/quorum resource. For the BizTalk Server storage unit, configure four of the 9 GB SCSI hard disks as a single 27-GB RAID 5 logical drive for the BizTalk Server repository and XLANG schedules, configure two separate sets of four 9 GB as RAID 0 + 1 (for the virtual MSMQ and NTFS message storage respectively), and configure the last two drives as RAID 1 for the cluster/quorum resource.

Solution Components

This section lists the required software products that each server uses for each deployment architecture.

Physician's office, dentist's office, and development setup

For the development deployment, the single server uses the following software products:

  • Microsoft Windows 2000 Advanced Server with SP2
  • Internet Information Services (IIS) 5.0
  • Windows 2000 SP3 Hotfix for IIS (Q294831)
  • Windows 2000 15 August 2001 Cumulative Patch for IIS (Q301625, MS01-044)
  • Microsoft Message Queuing (MSMQ)
  • Microsoft XML (MSXML) 3.0 with SP2
  • SQL Server 2000 Standard Edition with SP1
  • BizTalk Server 2000 Developer Edition with SP1a
  • Microsoft BizTalk Accelerator for HIPAA

The firewall server uses the following software products:

  • Windows 2000 Advanced Server with SP2
  • ISA Server 2000 Standard Edition

Enterprise Deployment Details

This section provides detailed instructions for the enterprise deployment. This deployment involves the following primary stages:

  • Configure the base platform.
  • Establish communication.
  • Set up the domains.
  • Install solution components.

These four stages will be done for the batch claims processing scenario.

In the first stage of the scenario, you will install the base platform on each server. To establish communication in the second stage, you will configure one domain controller for the network. In the fourth stage of installing solution components, you will install and configure all of the proper software on each server.

Before starting the deployment, you should be familiar with the concerns listed in the Known Issues at the end of this guide. The following table can serve as useful references when performing the deployment.

Deployment worksheet

The following table lists the IP addresses assigned to the various network adapters on each server.

Server Network adapter IP address Virtual IP (VIP) Cluster IP Default gateway DNS entry
Intranet DC/DNS Server 1 10.30.0.200         10.30.0.100 10.30.0.200
BizTalk Server 1 1 10.30.0.1 10.30.40.10 10.30.0.10 10.30.0.100 10.30.0.200
    2 10.40.0.1             10.30.0.200
BizTalk Server 2 1 10.30.0.2 10.30.40.10 10.30.0.10 10.30.0.100 10.30.0.200
    2 10.40.0.2             10.30.0.200
SQL Server 1 1 10.30.20.1 10.30.30.10 10.30.20.10 10.30.0.100 10.30.0.200
    2 10.40.20.1             10.30.0.200
SQL Server 2 1 10.30.20.2 10.30.30.10 10.30.20.10 10.30.0.100 10.30.0.200
    2 10.40.20.2             10.30.0.200

Batch Claims Processing Scenario

Configuring the Base Platform

Use the following procedure to configure the base platform:

  1. Install Windows 2000 Advanced Server + SP2 on all servers.

    When installing Windows 2000 Advanced Server be sure not to install Microsoft Message Queuing (MSMQ) because this feature will be installed later in the deployment process, after other resources have been configured. To prevent Message Queuing from being installed, clear the Message Queuing Services check box in the Windows Components Wizard.

  2. Install Internet Information Services (IIS) 5.0 on the BizTalk Servers and Web servers. IIS requires the following hotfixes:

    • Windows 2000 Pre-SP3 Hotfix for IIS (Q294831)
    • Windows 2000 15 August 2001 Cumulative Patch for IIS (Q301625, MS01-044))

  3. Install MSXML 3.0 + SP2 on the BizTalk Servers and Web servers.

    MSXML version 3.0 is automatically installed when you install BizTalk Server. If your server does not have BizTalk Server installed, you must manually install MSXML 3.0. When installing MSXML 3.0, ensure that it is installed in side-by-side mode so that it does not overwrite version 2.6, which is required for Business Desk. Install MSXML 3.0 SP2 by running msxml3sp2Setup.exe.

After configuring the base platform, it might be useful to create a backup image of each server. This backup image allows you to recover the server without re-installing all of the solution components in the event of failure.

Establishing Communication

Before installing and configuring the solution components on each server, you will need to establish communication by connecting the appropriate network cables and configuring the IP addresses on all servers. Then you will need to join each server to the appropriate domain. This section provides detailed instructions for completing these tasks.

When establishing network connectivity on each server, refer to the network diagram and deployment worksheet in the Enterprise Deployment Details section.

Connecting the intranet DC/DNS server

Use the following procedure to establish network connectivity on the intranet DC/DNS server:

  1. Connect a network cable from the server to Hub 3.

  2. On the desktop, right-click My Network Places and then click Properties.

  3. In the Network and Dial-up Connections dialog box, right-click Local Area Connection and then click Properties.

  4. In the Local Area Connection Properties dialog box for the selected network adapter, select Internet Protocol (TCP/IP) and then click Properties.

  5. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address and enter the following values:

    Field Enter
    IP address 10.30.0.200
    Subnet mask 255.255.0.0
    Default gateway 10.30.0.100

  6. Select Use the following DNS server addresses and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click OK.

  7. In the Local Area Connection Properties dialog box, click OK.

Connecting the SQL Server cluster

Each of the two servers in the SQL Server cluster will have two network adapters: one adapter connects to the intranet, the other connects to the other SQL Server by a crossover cable. This second connection enables cluster communication between the two SQL Servers. In addition, each server is connected to a shared storage unit by a SCSI cable.

The following illustration shows the network configuration for the SQL Server cluster.

Figure 2.

SQL Server requires its own cluster name and IP address. For the enterprise deployment, use LSSQLCLUSTER as the SQL Server cluster name and 10.30.30.10 as the SQL Server cluster IP address.

In addition to the SQL Server cluster name and IP address, the Cluster service will also require its own cluster name and IP address when you install Cluster service later in the deployment process. For the enterprise deployment, SQLCLUSTER will be used as the cluster name and 10.30.20.10 will be used as the cluster IP address for Cluster service.

Note Before configuring the network adapters, make sure that the shared storage unit is not powered on. Because the Cluster service has not yet been installed, the shared storage unit might be corrupted if it is connected to both servers while the power is on.

Connecting and renaming the network adapters

You should rename the network adapters from Local Area Connection and Local Area Connection 2 to more informative names, such as Intranet and Cluster. Use the following procedure on both SQL Servers to connect and rename the network adapters:

  1. Connect a network cable from the first network adapter to Hub 3.
  2. Connect a crossover cable from the second network adapter to the second network adapter of the other SQL Server.
  3. Connect a SCSI cable to the shared storage unit.
  4. On the desktop, right-click My Network Places and then click Properties.
  5. In the Network and Dial-up Connections dialog box, right-click Local Area Connection and then click Rename. This network adapter should correspond with the network adapter you connected to Hub 3 in step 1.
  6. Type Intranet and then press ENTER.
  7. In the Network and Dial-up Connections dialog box, right-click Local Area Connection 2 and then click Rename. This network adapter should correspond with the network adapter you connected to the other SQL Server in step 3.
  8. Type Cluster and then press ENTER.

Configuring network adapters on the primary SQL Server

Use the following procedure to configure the Intranet network adapter on the primary SQL Server:

  1. On the desktop, right-click My Network Places and then click Properties.

  2. In the Network and Dial-up Connections dialog box, right-click Intranet and then click Properties.

  3. In the Intranet Properties dialog box, select Internet Protocol (TCP/IP) and then click Properties.

  4. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address and enter the following values:

    Field Enter
    IP address 10.30.20.1
    Subnet mask 255.255.0.0
    Default gateway 10.30.0.100

  5. Select Use the following DNS server addresses and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click OK.

  6. In the Intranet Properties dialog box, click OK.

Use the following procedure to configure the Cluster network adapter on the primary SQL Server:

  1. On the desktop, right-click My Network Places, and then click Properties.

  2. In the Network and Dial-up Connections dialog box, right-click Cluster (the second network adapter), and then click Properties.

  3. In the Cluster Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.

  4. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address, and enter the following values:

    Field Enter
    IP address 10.40.20.1
    Subnet mask 255.255.0.0
    Default gateway Leave blank

  5. Select Use the following DNS server addresses, and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click Advanced.

  6. In the Advanced TCP/IP Settings dialog box, click the WINS tab, select Disable NetBIOS over TCP/IP, and then click OK.

  7. In the Advanced TCP/IP Settings dialog box, click OK.

  8. In the Cluster Properties dialog box, click Configure.

  9. In the network adapter's Properties dialog box, click the Advanced tab.

  10. Set the speed of the Cluster network adapter to the actual speed of the network, rather than the default automated speed selection. Select your network speed from the drop-down list. Do not use an auto-select setting for speed. To set the network adapter speed, click the appropriate option such as Media Type or Speed, and click OK.

  11. In the Cluster Properties dialog box, click OK.

Configuring network adapters on the secondary SQL Server

Use the following procedure to configure the Intranet network adapter on the secondary SQL Server:

  1. On the desktop, right-click My Network Places, and then click Properties.

  2. In the Network and Dial-up Connections dialog box, right-click Intranet (the first network adapter), and then click Properties.

  3. In the Intranet Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.

  4. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address, and enter the following values:

    Field Enter
    IP address 10.30.20.2
    Subnet mask 255.255.0.0
    Default gateway 10.30.0.100

  5. Select Use the following DNS server addresses, and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click OK.

  6. In the Intranet Properties dialog box, click OK.

Use the following procedure to configure the Cluster network adapter on the secondary SQL Server:

  1. On the desktop, right-click My Network Places, and then click Properties.

  2. In the Network and Dial-up Connections dialog box, right-click Cluster (the second network adapter), and then click Properties.

  3. In the Cluster Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.

  4. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address, and enter the following values:

    Field Enter
    IP address 10.40.20.2
    Subnet mask 255.255.0.0
    Default gateway Leave blank

  5. Select Use the following DNS server addresses, and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click Advanced.

  6. In the Advanced TCP/IP Settings dialog box, click the WINS tab, select Disable NetBIOS over TCP/IP, and then click OK.

  7. In the Advanced TCP/IP Settings dialog box, click OK.

  8. In the Cluster Properties dialog box, click Configure.

  9. In the network adapter's Properties dialog box, click the Advanced tab.

  10. Set the speed of the Cluster network adapter to the actual speed of the network, rather than the default automated speed selection. Select your network speed from the drop-down list. Do not use an auto-select setting for speed. To set the network adapter speed, click the appropriate option such as Media Type or Speed, and click OK.

  11. In the Cluster Properties dialog box, click OK.

Connecting the BizTalk Server cluster

Each of the two servers in the BizTalk Server cluster will have two network adapters: one adapter connects to the intranet, and the other connects to the other BizTalk Server by a crossover cable. This second connection enables cluster communication between the two BizTalk Servers. In addition, each server is connected to a shared storage unit by a SCSI cable.

The following illustration shows the network configuration for the BizTalk Server cluster.

Figure 3.

BizTalk Server requires its own cluster name and IP address. For the enterprise deployment, use LSBTCLUSTER as the cluster name and 10.30.40.10 as the cluster IP address.

In addition to the BizTalk Server cluster name and IP address, the Cluster service will also require its own cluster name and IP address when you install Cluster service later in the deployment process. For the enterprise deployment, BTCLUSTER will be used as the cluster name and 10.30.0.10 will be used as the cluster IP address for Cluster service.

Note   Before configuring the network adapters, make sure that the shared storage unit is not powered on. Because the Cluster service has not yet been installed, the shared storage unit might be corrupted if it is connected to both servers while the power is on.

Connecting and renaming the network adapters

You should rename the network adapters from Local Area Connection and Local Area Connection 2 to more informative names, such as Intranet and Cluster. Use the following procedure on both BizTalk Servers to connect and rename the network adapters:

  1. Connect a network cable from the first network adapter to Hub 3.
  2. Connect a crossover cable from the second network adapter to the second network adapter of the other BizTalk Server.
  3. Connect a SCSI cable to the shared storage unit.
  4. On the desktop, right-click My Network Places, and then click Properties.
  5. In the Network and Dial-up Connections dialog box, right-click Local Area Connection, and then click Rename. This network adapter should correspond with the network adapter you connected to Hub 3 in step 1.
  6. Type Intranet, and then press ENTER.
  7. In the Network and Dial-up Connections dialog box, right-click Local Area Connection 2, and then click Rename. This network adapter should correspond with the network adapter you connected to the other BizTalk Server in step 3.
  8. Type Cluster, and then press ENTER.

Configuring network adapters on the primary BizTalk Server

Use the following procedure to configure the Intranet network adapter on the primary BizTalk Server:

  1. On the desktop, right-click My Network Places, and then click Properties.

  2. In the Network and Dial-up Connections window, right-click Intranet (the first network adapter), and then click Properties.

  3. In the Intranet Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.

  4. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address, and enter the following values:

    Field Enter
    IP address 10.30.0.1
    Subnet mask 255.255.0.0
    Default gateway 10.30.0.100

  5. Select Use the following DNS server addresses, and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click OK.

  6. In the Intranet Properties dialog box, click OK.

Use the following procedure to configure the Cluster network adapter on the primary BizTalk Server:

  1. On the desktop, right-click My Network Places, and then click Properties.

  2. In the Network and Dial-up Connections window, right-click Cluster (the second network adapter), and then click Properties.

  3. In the Cluster Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.

  4. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address, and enter the following values:

    Field Enter
    IP address 10.40.0.1
    Subnet mask 255.255.0.0
    Default gateway Leave blank

  5. Select Use the following DNS server addresses, and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click Advanced.

  6. In the Advanced TCP/IP Settings dialog box, click the WINS tab, select Disable NetBIOS over TCP/IP, and then click OK.

  7. In the Advanced TCP/IP Settings dialog box, click OK.

  8. In the Cluster Properties dialog box, click Configure.

  9. In the network adapter's Properties dialog box, click the Advanced tab.

  10. Set the speed of the Cluster network adapter to the actual speed of the network, rather than the default automated speed selection. Select your network speed from the drop-down list. Do not use an auto-select setting for speed. To set the network adapter speed, click the appropriate option such as Media Type or Speed, and click OK.

  11. In the Cluster Properties dialog box, click OK.

Configuring network adapters on the secondary BizTalk Server

Use the following procedure to configure the Intranet network adapter on the secondary BizTalk Server:

  1. On the desktop, right-click My Network Places, and then click Properties.

  2. In the Network and Dial-up Connections window, right-click Intranet (the first network adapter), and then click Properties.

  3. In the Intranet Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.

  4. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address, and enter the following values:

    Field Enter
    IP address 10.30.0.2
    Subnet mask 255.255.0.0
    Default gateway 10.30.0.100

  5. Select Use the following DNS server addresses, and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click OK.

  6. In the Intranet Properties dialog box, click OK.

Use the following procedure to configure the Cluster network adapter on the secondary BizTalk Server:

  1. On the desktop, right-click My Network Places, and then click Properties.

  2. In the Network and Dial-up Connections window, right-click Cluster (the second network adapter), and then click Properties.

  3. In the Cluster Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.

  4. In the Internet Protocol (TCP/IP) Properties dialog box, select Use the following IP address, and enter the following values:

    Field Enter
    IP address 10.40.0.2
    Subnet mask 255.255.0.0
    Default gateway Leave blank

  5. Select Use the following DNS server addresses, and enter the following value:

    Field Enter
    Preferred DNS Server 10.30.0.200

    After entering this information, click Advanced.

  6. In the Advanced TCP/IP Settings dialog box, click the WINS tab, select Disable NetBIOS over TCP/IP, and then click OK.

  7. In the Advanced TCP/IP Settings dialog box, click OK.

  8. In the Cluster Properties dialog box, click Configure.

  9. In the network adapter's Properties dialog box, click the Advanced tab.

  10. Set the speed of the Cluster network adapter to the actual speed of the network, rather than the default automated speed selection. Select your network speed from the drop-down list. Do not use an auto-select setting for speed. To set the network adapter speed, click the appropriate option such as Media Type or Speed, and click OK.

  11. In the Cluster Properties dialog box, click OK.

Setting Up the Domains

After you have configured the base platform and configured all network settings, you can begin setting up two zones: a perimeter network (also called demilitarized zone or DMZ) and an intranet zone. To set up these two zones, you will create two separate, non-trusted domains by configuring a domain controller (DC) and a DNS server for each zone.

This section provides instructions for setting up the two domains. The following steps will lead you through the process of setting up these domains:

  • Configure an intranet DC/DNS server.
  • Verify DNS installation on the intranet DC/DNS server.
  • Create the necessary accounts.
  • Configure a DMZ DC/DNS server.
  • Verify DNS installation on the DMZ DC/DNS server.
  • Create a new host on the DMZ DC/DNS server.

Configuring an intranet DC/DNS server

First, you need to configure the DC/DNS server to support the internal network BizTalk Server processing behind the internal business firewall. You are ready to configure a DC/DNS server for the intranet. Use the following procedure to launch the Active Directory® Installation Wizard and configure your Windows 2000 Advanced Server as an intranet DC/DNS server:

  1. Click Start, and then click Run.
  2. In the Run dialog box, type dcpromo, and then click OK.
  3. On the Welcome to the Active Directory Installation Wizard screen, click Next.
  4. On the Domain Controller Type screen, select Domain controller for a new domain, and then click Next.
  5. On the Create Tree or Child Domain screen, select Create a new domain tree, and then click Next.
  6. On the Create or Join Forest screen, select Create a new forest of domain trees, and then click Next.
  7. On the New Domain Name screen, type the full DNS name for the new domain, and then click Next. For example, the full DNS name for your domain might be Contosointranet.com.
  8. On the NetBIOS Domain Name screen, click Next to use the default Domain NetBIOS name of CONTOSOINTRANET.
  9. On the Database and Log Locations screen, click Next to store the Active Directory database and log in the default location. To specify different locations, click Browse and select the appropriate directory.
  10. On the Shared System Volume screen, click Next to use the default location for the Sysvol folder.
  11. In the Active Directory Installation Wizard dialog box, click OK.
  12. On the Configure DNS screen, select Yes, install and configure DNS on this computer (recommended), and then click Next.
  13. On the Permissions screen, select Permissions compatible only with Windows 2000 servers, and then click Next.
  14. On the Directory Services Restore Mode Administrator Password screen, enter and confirm a password, and then click Next.
  15. On the Summary screen, review the information to ensure it is accurate, and then click Next. This step will start the installation process. Note that you might be required to insert the Windows 2000 CD. Do not skip the DNS installation step of this process; allow the wizard to install DNS.
  16. On the Completing the Active Directory Installation Wizard screen, click Finish.
  17. Restart the server.

Creating new hosts on the intranet DC/DNS server

You will need to create a new zone so that any servers in the Contosointranet.com domain can reference the Web servers in the Contoso.com domain.

Use the following procedure to create the new zone:

  1. Click Start, point to Programs, point to Administrative Tools, and then click DNS.
  2. In the DNS window, right-click Forward Lookup Zone, point to New, and then click Zone.
  3. In the New Zone dialog box, click Next.
  4. In the Zone Type dialog box, accept the default selection of Standard primary, and then click Next.
  5. In the Zone Name dialog box, type contoso.com, and then click Next.
  6. In the Completing the New Zone Wizard dialog box, click Finish.

After you have created the new contoso.com zone, you must add three new hosts: one for each of the three DMZ Web servers.

Use the following procedure to add the three new hosts:

  1. In the DNS window, expand Forward Lookup Zone. Right-click www.contoso.com, point to New, and then click Host.
  2. In the New Host dialog box, under Name, enter the name of Web server 1. Under IP address, enter 10.20.0.1, and then click Add Host.
  3. In the DNS dialog box informing you that the host record was successfully created, click OK.

Now add another host for the second DMZ Web server.

  1. In the New Host dialog box, under Name, enter the name of Web server 2. Under IP address, enter 10.20.0.2, and then click Add Host.
  2. In the DNS dialog box informing you that the host record was successfully created, click OK.

Now add another host for the third DMZ Web server.

  1. In the New Host dialog box, under Name, enter the name of Web server 3. Under IP address, enter 10.20.0.3, and then click Add Host.
  2. In the DNS dialog box informing you that the host record was successfully created, click OK.

Creating the necessary accounts

After you have configured the intranet DC/DNS server, create the BTA4H account as a member of the Domain Admins group. This account will be used to install BizTalk Server and SQL Server. The BizTalk services will run under this account, so this account must be a direct member of the BizTalk Administrators Group. Use the following procedure on the intranet DC/DNS server to create the BTA4H account:

  1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

  2. In the Active Directory Users and Computers snap-in, expand Contosointranet.com, right-click Users, point to New, and then click User.

  3. In the New Object - User dialog box, enter the following information:

    Field Enter
    First name BTA4H
    Last name Tester
    User logon name BTA4H@Contosointranet.com

    After entering this information, click Next.

    Note Because the account name is case-sensitive, enter BTA4H in all capital letters.

  4. For Password, enter a password for the BTA4H account, and confirm this password in Confirm password. Select the check boxes for User cannot change password and Password never expires, and then click Next.

  5. Click Finish.

  6. In the right pane, right-click Domain Admins, and click Properties.

  7. In the Domain Admins Properties dialog box, click the Members tab, and then click Add.

  8. In the Select Users, Contacts, or Computers dialog box, select BTA4H, click Add, and then click OK.

  9. In the Domain Admins Properties dialog box, click Apply, and then click OK.

  10. Close the Active Directory Users and Computers snap-in.

Joining the domains

Now that you have connected each server to the appropriate network and configured the DC/DNS servers for each domain, you are ready to complete the domains by joining each server to the appropriate domains.

Joining the SQL Servers to the intranet domain

Use the following procedure on each SQL Server to join the intranet domain:

  1. On the desktop, right-click My Computer, and then click Properties.
  2. In the System Properties dialog box, click the Network Identification tab, and then click Properties.
  3. In the Identification Changes dialog box, under Member of, select Domain, type Contosointranet.com, and then click OK.
  4. In the Domain Username and Password dialog box, type administrator, enter the corresponding password, and then click OK.
  5. In the Network Identification dialog box that welcomes you to the Contosointranet.com domain, click OK.
  6. In the Network Identification dialog box that advises you to reboot the computer, click OK.
  7. In the System Properties dialog box, click OK.
  8. In the System Settings Change dialog box, click Yes to restart the server.

Joining the BizTalk Servers to the intranet domain

Use the following procedure on each BizTalk Server to join the intranet domain:

  1. On the desktop, right-click My Computer, and then click Properties.
  2. In the System Properties dialog box, click the Network Identification tab, and then click Properties.
  3. In the Identification Changes dialog box, under Member of, select Domain, type Contosointranet.com, and then click OK.
  4. In the Domain Username and Password dialog box, type administrator, enter the corresponding password, and then click OK.
  5. In the Network Identification dialog box that welcomes you to the Contosointranet.com domain, click OK.
  6. In the Network Identification dialog box that advises you to reboot the computer, click OK.
  7. In the System Properties dialog box, click OK.
  8. In the System Settings Change dialog box, click Yes to restart the server.

Clustering the Appropriate Servers

After you have completed the domains and all servers can communicate properly, you are ready to configure clustering for the appropriate servers. This clustering process includes Windows Clustering on the BizTalk Server and SQL Server clusters.

Installing Cluster service on the SQL Server cluster

This section provides instructions for installing the Cluster service on the SQL Server cluster. Specifically, this section describes how to:

  • Configure the external storage device.
  • Install Cluster service.
  • Create a Microsoft Distributed Transaction Coordinator (MS DTC) cluster resource.
  • Install MS DTC.

Configuring the external storage device

You must configure your external storage device prior to installing Cluster service. Read the instructions on your SCSI controller for setting up the external storage device, which acts as the shared storage unit (SSU) for the two-node SQL Server cluster.

Connect the SSU to the SQL Servers by using SCSI cables. Power off both servers and the SSU while connecting the cables. Follow the powering-on sequence as explained in the Cluster service installation instructions in Appendix 1. Do not power on both servers and the SSU at the same time until Cluster service has been fully installed.

To configure the cluster array, follow the directions that accompany the hardware you have selected (consult the array configuration guide from your hardware vendor). Following these instructions, you will need to configure the drives as follows:

For the SQL Server storage unit, configure the 14x9GB (or better) disks allocated to this RAID cabinet as follows:

  • Minimum of four disks as a single RAID 5 logical drive for the databases
  • Minimum of four disks as a single RAID 0 + 1 logical drive for the transaction logs for InterchangeDTA/InterchangeBTM
  • Minimum of four disks as a single RAID 0 + 1 logical drive for the transaction logs for InterchangeSQ/XLANG
  • Two drives as RAID 1 for the cluster/quorum resource

For the BizTalk Server storage unit, configure the 14x9GB (or better) disks allocated to this RAID cabinet as follows:

  • Minimum of four disks as a single RAID 5 logical drive for the BizTalk Server repository and XLANG schedules
  • Minimum of four disks as a single RAID 0 + 1 logical drive for virtual MSMQ storage
  • Minimum of four disks as a single RAID 0 + 1 logical drive for NTFS message storage
  • Two drives as RAID 1 for the cluster/quorum resource

Installing Cluster service

You must install Cluster service before installing SQL Server 2000 Enterprise Edition. Keep in mind the following points as you install Cluster service:

  • Configure the SSU with four drives: E, F, G, and Q, with the E, F, and G drives acting as the shared drive and the Q drive acting as the quorum drive.
  • During the cluster installation, the other node must be booted but stopped at the Boot menu so that there is power to the network adapter but it does not have write access to the shared disks.

To install Cluster service, follow the instructions in Appendix 1 of this document. After you have verified the installation as shown in the instructions, use Cluster Administrator to rename Disk Group 1 in your cluster to SQL Cluster Group.

Installing Cluster service on the BizTalk Server cluster

This section provides detailed instructions for installing the Cluster service on the BizTalk Server cluster. Specifically, this section describes how to:

  • Configure the external storage device.
  • Install Cluster service.
  • Create cluster resources for BizTalk Cluster Group.
  • Create an MS DTC cluster resource.
  • Install MS DTC.

Configuring the external storage device

You must configure your external storage device. Read the instructions on your SCSI controller for setting up the external storage device, which acts as the shared storage unit (SSU) for the two-node BizTalk Server cluster. You must configure the SSU to have only one container.

Connect the SSU to the BizTalk Servers by using SCSI cables. Power off both servers and the SSU while connecting the cables. Follow the powering-on sequence as explained in the Cluster service installation instructions in Appendix 1. Do not power on both servers and the SSU at the same time until Cluster service has been fully installed.

Installing Cluster service

You must install Cluster service before installing BizTalk Server 2000 Enterprise Edition. Keep in mind the following points as you install Cluster service:

  • Configure the SSU with four drives: E, F, G, and Q, with the E, F, and G drives acting as the shared drive and the Q drive acting as the quorum drive.
  • During the cluster installation, the other node must be booted but stopped at the Boot menu so that there is power to the network adapter but it does not have write access to the shared disks.

To install Cluster service, follow the instructions in Appendix 1. After you have verified the installation as shown in the instructions, use Cluster Administrator to rename Disk Group 1 in your cluster to BizTalk Cluster Group.

Creating Cluster resources for the BizTalk Cluster Group

Use the following procedure on the primary BizTalk Server to create the two new resources (network name and IP address) in the BizTalk Cluster Group that contains disk D. The primary server is considered the active server (the server owning the cluster resources). The secondary server is considered the inactive server (the server that does not own the cluster resources).

  1. Right-click BizTalk Cluster Group, point to New, and then click Resource.

  2. In the New Resource screen, enter the following information:

    Field Enter
    Name Virtual IP Address
    Description Virtual IP Address
    Resource type IP Address
    Group BizTalk Cluster Group

    After entering this information, click Next.

  3. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  4. In the Dependencies screen, under Available resources, select Disk D, click Add, and then click Next.

  5. In the TCP/IP Address Parameters screen, enter the following information:

    Field Enter
    Address 10.30.40.10
    Subnet mask 255.255.0.0
    Network Intranet

    Select the Enable NetBIOS for this address check box, and then click Finish. The virtual IP address is now assigned to the BizTalk Cluster Group. Note that this IP address is different from the IP address used when installing Cluster service.

  6. In the Cluster Administrator dialog box informing you that the cluster resource "Virtual IP Address" was created successfully, click OK.

  7. In Cluster Administrator, right-click BizTalk Cluster Group, point to New, and then click Resource.

  8. In the New Resource screen, enter the following information:

    Field Enter
    Name Virtual Network Name
    Description Virtual Network Name
    Resource type Network Name
    Group BizTalk Cluster Group

    After entering this information, click Next.

  9. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  10. In the Dependencies screen, under Available resources, select Disk D, and then click Add. Select Virtual IP Address, click Add, and then click Next.

  11. In the Network Name Parameters screen, type LSBTCLUSTER, and then click Finish. This name is different from the BTCLUSTER name used when installing Cluster service. All servers from both domains will now use LSBTCLUSTER when referencing the BizTalk Server cluster.

  12. In the Cluster Administrator dialog box informing you that the cluster resource "Virtual Network Name" was created successfully, click OK.

Creating an MS DTC Cluster resource

Before installing MS DTC, add it as a cluster resource to the BizTalk Cluster Group. Use the following procedure to accomplish this task:

  1. Copy the DTCLog folder from the \winnt\system32 folder to physical disk D.

  2. In Cluster Administrator, click BizTalk Cluster Group.

  3. On the File menu, point to New, and then click Resource.

  4. In the New Resource screen, enter the following information:

    Field Enter
    Name MSDTC
    Description MSDTC
    Resource type Distributed Transaction Coordinator
    Group BizTalk Cluster Group

    After entering this information, click Next.

  5. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  6. In the Dependencies screen, under Available resources, select Disk D, and then click Add. Repeat this step for Virtual Network Name and Virtual IP address, and then click Finish.

  7. In the Cluster Administrator dialog box informing you that the cluster resource "MSDTC" was created successfully, click OK.

  8. Verify that the MS DTC resource is online.

  9. Test the failover of the MS DTC resource between the two SQL Servers.

If you encounter problems configuring MS DTC, refer to "Microsoft Distributed Transaction Coordinator (MS DTC) Recovery Techniques" in the Windows 2000 Cluster service documentation.

Installing MS DTC on the BizTalk Server Cluster

Microsoft Distributed Transaction Coordinator (MS DTC) must be installed on each BizTalk Server. Use the following procedure to install MS DTC:

  1. Click Start, point to Programs, point to Accessories, and then click Command Prompt.

  2. In the Command Prompt window, type comclust.exe. Setup will start automatically.

  3. You should see the following messages in your command window when running comclust.exe:

       <drive:>\Documents and Settings\BTA4H>comclust.exe

       Setting up MS DTC.

       Setup has successfully populated configuration information to allow MS DTC to run on this cluster node.

    **   Please run setup on all other nodes in the cluster before continuing.**

       Setting up Component Load Balancing.

       Setting up: COM+ -- CLB

       WARNING: This machine is not a Component Load Balancing server.

       The CLB resource will not be added to the COM+ cluster group.

    You can safely ignore the warning message.

  4. Verify that the MS DTC resource is online.

  5. Test the failover of the MS DTC resource between the two BizTalk Servers.

You are only required to create the cluster resources on the primary BizTalk Server. However, you must run comclust.exe on both BizTalk Servers. Before running comclust.exe on the secondary BizTalk Server, you should fail over the cluster resources to the secondary BizTalk Server.

If you encounter problems configuring MS DTC, refer to "Microsoft Distributed Transaction Coordinator (MS DTC) Recovery Techniques" in the Windows 2000 Cluster service documentation.

Installing Solution Components

This section provides detailed instructions about installing the BizTalk Accelerator for HIPAA solution components. This installation consists of the following stages:

  • Set up the intranet servers.
  • Install Accelerator for HIPAA.

Setting up the intranet servers

To set up the intranet, you will need to install the appropriate software and configure the following servers:

  • SQL Server cluster
  • BizTalk Server cluster

Installing and configuring the SQL Server Cluster

This section provides detailed instructions about installing and configuring Microsoft SQL Server 2000. Specifically, this section describes how to:

  • Install SQL Server 2000 Enterprise Edition.
  • Disable Named Pipes.
  • Install SQL Server 2000 SP1.
  • Create an MS DTC cluster resource.
  • Install MS DTC on the SQL Server cluster.

Before installing SQL Server, log on as the BTA4H user.

Do not use Terminal Services to install SQL Server 2000 in a clustered environment. Errors will occur during setup.

Installing SQL Server 2000 Enterprise Edition

Use the following procedure on the primary SQL Server to install SQL Server 2000 Enterprise Edition. After installation is complete, Cluster service will automatically configure the secondary SQL Server using the primary SQL Server's installation configuration. The primary server is considered the active server (the server owning the cluster resources). The secondary server is considered the inactive server (the server that does not own the cluster resources).

  1. Verify that both SQL Servers are powered on.

    Note   It is not required to install Analysis Services for Accelerator for HIPAA.

  2. Insert the SQL Server 2000 Enterprise Edition CD into the CD-ROM drive of the primary SQL Server.

  3. Run setup.exe from the SQL Server 2000 CD.

  4. Select SQL Server 2000 Components.

  5. Select Install Database Server. This step starts the Microsoft SQL Server Installation Wizard.

  6. In the Welcome to the Microsoft SQL Server Installation Wizard screen, click Next.

  7. In the Computer Name screen, select Virtual Server, enter LSSQLCLUSTER as the virtual SQL Server cluster name, and then click Next.

  8. In the User Information screen, enter a Name, Company, and then click Next.

  9. In the Software License Agreement screen, read the End-User License Agreement (EULA), and click Yes to proceed with installation.

  10. In the Failover Clustering screen, select INTRANET from the drop-down list for Network to Use, enter 10.30.30.10, click Add, and then click Next.

  11. In the Cluster Disk Selection screen, select the D drive for where data files will be placed. Use the default of Disk Group 1, and then click Next.

  12. In the Cluster Management screen, ensure that both servers are in the configured nodes text box, and then click Next.

  13. In the Remote Information screen, enter the following information:

    Field Enter
    Username BTA4H
    Password Password
    Domain Contosointranet

    After entering this information, click Next.

  14. In the Instance Name screen, leave the default values and click Next.

  15. If the Installation Definition screen appears, select Server and Client Tools, and then click Next.

  16. In the Setup Type screen, select Typical. Accept the default installation locations, and then click Next.

  17. In the Services Accounts screen, select Use the same account for each service. Under Service Settings, select Use a Domain User account, and enter the following information:

    Field Enter
    Username BTA4H
    Password Password
    Domain Contosointranet

    After entering this information, click Next.

  18. In the Authentication Mode screen, select Mixed Mode, enter and confirm a password for user sa, and then click Next.

  19. In the Start Copying Files screen, click Next.

  20. In the Choose Licensing Mode screen, under Licensing Mode, select the appropriate number of licenses, and then click Continue. This step will start the installation process.

  21. In the Setup Complete screen, click Finish.

Disabling Named Pipes

After installation, disable Named Pipes and use TCP/IP only as described in the following procedure. If your setup requires Named Pipes, ensure that TCP/IP has a higher precedence than Named Pipes.

  1. Click Start, and then click Run.
  2. In the Run dialog box, type cliconfg and press OK.
  3. In the SQL Server Client Network Utility dialog box, click the General tab. Under Enabled protocols by order, click Named Pipes, click Disable, and then click OK. This step will move Named Pipes to the Disabled protocols list.
  4. Make sure that Enable Shared Memory Protocol is selected. This should be the default setting.

Installing SQL Server 2000 SP1

Use the following procedure on the primary SQL Server to install SQL Server 2000 Service Pack 1 (SP1):

  1. Verify that both SQL Servers are powered on.
  2. Insert the SQL Server 2000 SP1 CD in the CD-ROM drive of the primary SQL Server (the node that currently owns the cluster resources).
  3. Run setup.bat. This step starts the SQL Server 2000 SP1 Setup Wizard.
  4. In the Welcome screen, click Next.
  5. In the Computer Name screen, type LSSQLCLUSTER as the name of the Virtual Server, select Virtual Server, and then click Next.
  6. In the Software License Agreement screen, read the End-User License Agreement (EULA), and then click Yes to proceed with installation.
  7. In the Instance Name screen, click Next.
  8. In the Connect to Server screen, select Windows authentication, and then click Next.
  9. In the Start Copying Files screen, click Next. This step starts the installation process.
  10. In the screen that advises you to back up your master and msdb databases, click OK.
  11. In the Setup Complete screen, click Finish.
  12. Restart the server. After the primary SQL Server has restarted, restart the secondary SQL Server.

Creating an MS DTC Cluster Resource

Use the following procedure on the primary server to create the MS DTC cluster resource so that the SQL Server cluster will be able to coordinate with the BizTalk Server cluster. The primary server is considered the active server (the server owning the cluster resources).

  1. Copy the DTCLog folder from the \winnt\system32 folder to physical disk G.

  2. In the Cluster Administrator's Group, right-click Disk Group 1, point to New, and then click Resource.

  3. In the New Resource screen, enter the following information:

    Field Enter
    Name MSDTC
    Description MSDTC
    Resource Type Distributed Transaction Coordinator
    Group Disk Group 1

    After entering this information, click Next.

  4. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  5. In the Dependencies screen, under Available resources, select SQL Network Name, and then click Add. Repeat this step for SQL IP Address, Disk G:, and then click Next.

  6. Click Finish.

  7. In the Cluster Administrator screen, click OK.

  8. Verify that the MS DTC resource is online.

  9. Test the failover of the MS DTC resource between the two SQL Servers.

If you encounter problems configuring MS DTC, refer to "Microsoft Distributed Transaction Coordinator (MS DTC) Recovery Techniques" in the Windows 2000 Cluster service documentation.

Installing MS DTC on the SQL Server Cluster

Microsoft Distributed Transaction Coordinator (MS DTC) must be installed on each SQL Server. Use the following procedure to install MS DTC:

  1. Click Start, and then click Run.

  2. In the Run dialog box, type comclust.exe. Setup will start automatically.

  3. You should see the following messages in your command window when running comclust.exe:

       <drive:>\Documents and Settings\BTA4H>comclust.exe

       Setting up MS DTC.

       Setup has successfully populated configuration information to allow MS DTC to run on this cluster node.

    **   Please run setup on all other nodes in the cluster before continuing.**

       Setting up Component Load Balancing.

       Setting up: COM+ -- CLB

       WARNING: This machine is not a Component Load Balancing server.

       The CLB resource will not be added to the COM+ cluster group.

    You can safely ignore the warning message.

  4. Verify that the MS DTC resource is online.

  5. Test the failover of the MS DTC resource between the two SQL Servers.

You are only required to create the cluster resource on the primary SQL Server. However, you must run comclust.exe on both SQL Servers. Before running comclust.exe on the secondary SQL Server, you should fail over the cluster resources to the secondary SQL Server.

If you encounter problems configuring MS DTC, refer to "Microsoft Distributed Transaction Coordinator (MS DTC) Recovery Techniques" in the Windows 2000 Cluster service documentation.

Installing and configuring the BizTalk Server Cluster

This section provides detailed instructions for configuring the Microsoft BizTalk Server cluster. Before completing the following tasks, make sure you are logged on using the BTA4H user account. This section describes how to:

  • Install Microsoft Message Queuing.
  • Add a virtual Message Queuing resource to the BizTalk Server cluster group.
  • Add a management console for each virtual Message Queuing instance.
  • Verify Message Queuing installation.
  • Test Message Queuing failover.
  • Install SQL Server 2000 client utilities.
  • Disable Named Pipes.
  • Install SQL Server 2000 SP1.
  • Install BizTalk Server 2000 Enterprise Edition on the primary BizTalk Server.
  • Install BizTalk Server 2000 SP1a on the primary BizTalk Server.
  • Verify SP1a installation on the primary BizTalk Server.
  • Install BizTalk Server 2000 Enterprise Edition on the secondary BizTalk Server.
  • Install BizTalk Server 2000 SP1a on the secondary BizTalk Server.
  • Verify SP1a installation on the secondary BizTalk Server.

Installing Microsoft Message Queuing

Install Message Queuing as its own service, not as a dependent client. Use the following procedure on both BizTalk Servers to install Message Queuing with the Windows 2000 Configure Your Server utility. During this installation process, you will be prompted to insert the Windows 2000 Advanced Server CD into the CD-ROM drive.

  1. Click Start, point to Programs, point to Administrative Tools, and then click Configure Your Server.
  2. In the Windows 2000 Configure Your Server dialog box, in the left column, expand Advanced, and then select Message Queuing.
  3. In the right pane, click Start the Message Queuing Installation Wizard.
  4. In the Welcome to the Message Queuing Installation Wizard screen, click Next.
  5. In the Message Queuing Type screen, select Message Queuing server, make sure that the Enable routing and Manually select access mode to Active Directory boxes are not selected, and then click Next.
  6. In the Message Queuing Server screen, select Message Queuing will not access a directory service, and then click Next.
  7. In the Completing the Message Queuing Installation Wizard screen, click Finish.

Adding a virtual Message Queuing resource to the BizTalk Cluster Group

Use the following procedure on the primary BizTalk Server to add a virtual Message Queuing resource to the BizTalk Server cluster group. The primary server is considered the active server (the server owning the cluster resources). The secondary server is considered the inactive server (the server that does not own the cluster resources).

  1. In Cluster Administrator, right-click BizTalk Cluster Group, point to New, and then click Resource.

  2. In the New Resource screen, enter the following information:

    Field Enter
    Name Virtual MSMQ
    Description Virtual MSMQ
    Resource type Message Queuing
    Group BizTalk Cluster Group

    After entering this information, click Next.

  3. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  4. In the Dependencies screen, under Available resources, select Disk E, and then click Add. Select Virtual Network Name, click Add, and then click Finish.

  5. In the Cluster Administrator dialog box informing you that the cluster resource "MSMQ" was created successfully, click OK.

  6. Bring the resource online.

  7. Test the failover of the MSMQ resource between the two BizTalk Servers.

After configuring the virtual Message Queuing instance and bringing it online, there will be two services running: a local instance and a virtual instance. The physical files for the virtual Message Queuing instance will automatically be created on the shared disk resource in a Message Queuing folder. You do not need to change the startup settings for the virtual Message Queuing instance. However, if the local instance of Message Queuing is required, change the startup settings to Automatic.

Adding a management console for each virtual Message Queuing instance

Normally, you can manage Message Queuing from the Computer Management window. However, managing a virtual instance of Message Queuing requires you to run the management console in the context of the virtual server rather than the local server. Use the following procedure to create the management console for the Message Queuing service. You only need to create this on the primary BizTalk Server.

  1. In the Cluster Administrator window, right-click BizTalk Cluster Group, point to New, and then click Resource.

  2. In the New Resource screen, enter the following information:

    Field Enter
    Name Manage Virtual MSMQ
    Description Manage Virtual MSMQ
    Resource type Generic Application
    Group BizTalk Cluster Group

    After entering this information, click Next.

  3. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  4. In the Dependencies screen, add Virtual Network Name and the name of the virtual Message Queuing instance that was previously created, and then click Next.

  5. In the Generic Application Parameters screen, type <drive:>\winnt\system32\mmc.exe /s compmgmt.msc for Command line.

  6. For Current directory, type <drive:>\winnt\system32. Select the check boxes for Allow application to interact with desktop and Use Network Name for computer name, and then click Next.

  7. In the Registry Replication screen, click Finish.

  8. After creating the resource, double-click Manage Virtual MSMQ.

  9. In the Manage Virtual MSMQ Properties dialog box, click the Advanced tab.

  10. Under Restart, clear the check box for Affect the group. Select Do not restart, and then click OK.

When this cluster resource is brought online, it will automatically open a command prompt window and start Computer Management in the context of the virtual server. To display the virtual queues, expand the Message Queuing instance.

Verifying Message Queuing Installation

After completing the Message Queuing Installation Wizard, you must verify that Message Queuing was installed properly and that all required subdirectories exist. Use the following procedure to verify Message Queuing installation:

  1. Open the Computer Management console in the context of the virtual server, expand Services and Applications, expand Message Queuing, and then click Private Queues.
  2. In the details pane, verify that the following four private queues exist:
    • admin_queue$
    • mqis_queue$
    • notify_queue$
    • order_queue$

Testing Message Queuing Failover

Use the following procedure to test Message Queuing failover:

  1. In the Cluster Administrator window, click the Message Queuing resource, and then select Initiate Failure.
  2. Based on the number of retry attempts (this value is set to 3 by default) configured for that resource, the owner of the cluster resource group should switch after the threshold is exceeded. During a failure, all the resources in the group will go offline and move to the other server. On the other server, each resource in the group will come online in the order specified by the dependencies.
  3. You can switch the owner of the cluster resource group back by right-clicking the virtual Message Queuing instance, and then selecting Move Group. This step results in a manual failover without any retry attempts.

Installing SQL Server 2000 client utilities

Because a separate SQL Server cluster exists, only the SQL Server 2000 client utilities need to be installed. Install these utilities locally and not as clustered resources. Use the following procedure on both BizTalk Servers to install the SQL Server 2000 client utilities:

  1. Insert the SQL Server 2000 CD into the CD-ROM drive.

  2. Select SQL Server 2000 Components.

  3. Select Install Database Server. This step starts the SQL Server Installation Wizard.

  4. In the Welcome to the Microsoft SQL Server Installation Wizard screen, click Next.

  5. In the Computer Name screen, select Local Computer, and then click Next.

  6. In the Installation Selection screen, select Create a new instance of SQL Server**, or install Client Tools** and then click Next.

  7. In the User Information screen, enter your Name and Company, and then click Next.

  8. In the Software License Agreement screen, read the End-User License Agreement (EULA), and then click Yes to proceed with installation.

  9. In the Installation Definition screen, select Client Tools Only, and then click Next.

  10. In the Select Components screen, click Next.

  11. If the Remote Information screen appears, enter the following information:

    Field Enter
    Username BTA4H
    Password Password
    Domain Contosointranet

    After entering this information, click Next.

  12. In the Start Copying Files screen, click Next. This step starts the installation process.

  13. In the Setup Complete screen, click Finish. If Setup prompts you to restart the server, click Yes.

Disabling Named Pipes

After installation, disable Named Pipes and use TCP/IP only as described in the following procedure. If your setup requires Named Pipes, ensure that TCP/IP has a higher precedence than Named Pipes.

  1. Click Start, and then click Run.
  2. In the Run dialog box, type cliconfg and press OK.
  3. In the SQL Server Client Network Utility dialog box, click the General tab. Under Enabled protocols by order, click Named Pipes, click Disable, and then click OK. This step will move Named Pipes to the Disabled protocols list.

Installing SQL Server 2000 SP1

After installing SQL Server 2000 client utilities, install SQL Server 2000 Service Pack 1 (SP1). Use the following procedure on both BizTalk Servers to install SQL Server 2000 SP1:

  1. Run the setup.bat file.
  2. In the Welcome screen, click Next.
  3. In the Computer Name screen, select Local Computer, and then click Next. The name of your local server should appear in the text box.
  4. In the Software License Agreement screen, read the End-User License Agreement (EULA), and then click Yes to proceed with installation.
  5. In the Start Copying Files screen, click Next. This step starts the installation process.
  6. In the Setup Complete screen, click Finish.

Installing BizTalk Server 2000 Enterprise Edition on the primary BizTalk Server

Before installing BizTalk Server 2000 Enterprise Edition, make sure that the BizTalk Cluster Group cluster resource contains the following resources:

  • Virtual IP address
  • Virtual network name
  • Shared disk E
  • MS DTC
  • Virtual MSMQ
  • Manage virtual MSMQ

Use the following procedure on the primary BizTalk Server to install BizTalk Server 2000 Enterprise Edition. The primary server is considered the active server (the server owning the cluster resources). The secondary server is considered the inactive server (the server that does not own the cluster resources).

  1. Insert the BizTalk Server 2000 Enterprise Edition CD into the CD-ROM drive.
  2. Run Microsoft Biztalk Server.msi. This starts the Microsoft BizTalk Server 2000 Setup Wizard.
  3. In the Welcome to the Microsoft BizTalk Server 2000 Setup Wizard screen, click Next.
  4. In the License Agreement screen, read the End-User License Agreement, select I accept this agreement to proceed with installation, and then click Next.
  5. In the Customer Information screen, enter a User name, Organization, and Product key. Select Anyone who uses this computer (all users), and then click Next.
  6. In the Destination Folder screen, use the default installation location, and click Next. You do not need to install BizTalk Server 2000 on the shared storage drive.
  7. In the Setup Type screen, select Complete, and then click Next.
  8. In the Configure BizTalk Server Administrative Access screen, accept the default values, and click Next.
  9. In the Microsoft BizTalk Server Service Log On Properties screen, select This account, enter Contosointranet\BTA4H for User name, and then enter the corresponding password.
  10. Make sure that the check box next to Start service after setup completes is cleared, and then click Next.
  11. In the Ready To Install the Program screen, make sure all components will be installed, and then click Install. If a dialog box informs you that BizTalk Orchestration Designer will not be installed because it requires Microsoft Visio 2000 Standard Edition SR-1, click OK. This software can be installed on development and testing platforms, but is not required on production servers or for this deployment.
  12. In the Welcome to the Microsoft BizTalk Server 2000 Messaging Database Setup Wizard screen, click Next.
  13. In the Configure a BizTalk Messaging Management Database screen, select Create a new BizTalk Messaging Management database, enter LSSQLCLUSTER for Server name, enter sa for User name, and enter the corresponding password. Enter InterchangeBTM for Database, and then click Next.
  14. In the Configure a BizTalk Server Group screen, select Create a new BizTalk Server group, enter BizTalk Server Group for the Group name, and then click Next.
  15. In the Configure a Tracking Database screen, select Create a new Tracking database, and enter LSSQLCLUSTER for Server name. Enter sa for User name, and enter the corresponding password. Enter InterchangeDTA for Database, and then click Next.
  16. In the Configure a Shared Queue Database screen, select Create a new Shared Queue database, and enter LSSQLCLUSTER for Server name. Enter sa for User name, and enter the corresponding password. Enter InterchangeSQ for Database, and then click Next.
  17. In the Verify BizTalk Server Group screen, verify the information, and then click Next.
  18. In the Completing the Microsoft BizTalk Server 2000 Messaging Database Setup Wizard screen, click Finish.
  19. In the Welcome to the Microsoft BizTalk Server 2000 Orchestration Persistence Database Server Wizard screen, click Next.
  20. In the Configure a default Orchestration Persistence Database screen, select Create a new default Orchestration Persistence database. Enter LSSQLCLUSTER for Server name, enter XLANG for Database, and then click Finish.
  21. In the Completing the Microsoft BizTalk Server 2000 Setup Wizard screen, click Finish.

Installing BizTalk Server 2000 SP1a on the primary BizTalk Server

Use the following procedure on the primary BizTalk Server to install BizTalk Server 2000 Service Pack 1a (SP1a):

  1. Ensure that the BizTalk Server 2000 Enterprise Edition CD is in the CD-ROM drive.
  2. Run the BTS2000_SP1a_EN.EXE file from the local drive. You cannot install BizTalk Server 2000 SP1a if you run this file from a CD.
  3. In the Resuming the Microsoft BizTalk Server 2000 Setup Wizard screen, click Next. This step starts the installation process.
  4. In the Completing the Microsoft BizTalk Server 2000 Setup Wizard screen, click Finish.
  5. In the Microsoft BizTalk Server 2000 Installer Information dialog box that advises you to restart the server, click Yes.
  6. Restart the server.
  7. Install the stored procedure on the Shared Queue database:

    1. On the Start menu, point to Programs, point to Microsoft SQL Server, and click Query Analyzer.

    2. In the SQL Server list, click the name of the SQL Server that hosts the Shared Queue database, enter the appropriate login information, and click OK.

    3. If you have Microsoft SQL Server 7.0 installed, in the DB list, click the name of the Shared Queue database and continue to step 5.

      For example: InterchangeSQ

      —Or—

      If you have Microsoft SQL Server 2000 installed, on the Query menu, click Change Database.

    4. Click the name of the Shared Queue database and click OK.

      For example: InterchangeSQ

    5. On the File menu, click Open.

    6. In the Open Query File dialog box, in the Look in list, browse to \Program Files\Microsoft BizTalk Server\Setup.

    7. Click CleanQueuesPatch.sql and click Open.

    8. On the Query menu, click Execute.

  8. Install the stored procedure on the BizTalk Messaging Management database:

    1. On the Start menu, point to Programs, point to Microsoft SQL Server, and then click Query Analyzer.

    2. In the SQL Server list, click the name of the SQL Server instance that hosts the BizTalk Messaging Management database, enter the appropriate login information, and click OK.

    3. If you have Microsoft SQL Server 7.0 installed, in the DB list, click the name of the BizTalk Messaging Management database (for example, InterchangeBTM) and continue to step 5.

      —Or—

      If you have Microsoft SQL Server 2000 installed, on the Query menu, click Change Database and continue to step 4.

    4. Click the name of the BizTalk Messaging Management database (for example, InterchangeBTM) and click OK.

    5. On the File menu, click Open.

    6. In the Open Query File dialog box, in the Look in list, browse to \Program Files\Microsoft BizTalk Server\Setup.

    7. Click ControlNumbers.sql and click Open.

    8. On the Query menu, click Execute.

By default after the restart, the secondary BizTalk Server becomes the primary BizTalk Server (or owner of the BizTalk Server cluster resources).

Verifying SP1a installation on the primary BizTalk Server

To verify that BizTalk Server 2000 SP1a has been installed, view the file properties for any of the DLLs (except setupex.dll) in the BizTalk Server 2000 installation directory.

  1. In Windows Explorer, browse to the BizTalk Server 2000 installation directory, and select and right-click any DLL file (except setupex.dll).
  2. Click Properties.
  3. On the Version tab, confirm that the version number is 1764 and click OK.

Installing BizTalk Server 2000 Enterprise Edition on the secondary BizTalk Server

After the secondary BizTalk Server becomes the owner of the cluster resources, install BizTalk Server 2000 on the secondary BizTalk Server by using the following procedure:

  1. Repeat steps 1 through 12 from the previous section for installing BizTalk Server 2000 Enterprise Edition on the primary BizTalk Server.
  2. In the Configure a BizTalk Messaging Management Database screen, select Select an existing database. Under SQL Server connection parameters, enter LSSQLCLUSTER for Server name. Enter sa for User name, and enter the corresponding password. Enter InterchangeBTM for Database, and then click Next.
  3. In the Configure a BizTalk Server Group screen, select Select an existing BizTalk Server group, and then click Next. BizTalk Server Group should already be listed in the group.
  4. In the Verify BizTalk Server Group screen, click Next.
  5. In the Completing the Microsoft BizTalk Server 2000 Messaging Database Setup Wizard screen, click Finish.
  6. In the Welcome to Microsoft BizTalk Server 2000 Orchestration Persistence Database Setup Wizard screen, click Next.
  7. In the Configure a default Orchestration Persistence Database screen, select Select an existing database. Enter LSSQLCLUSTER for Server name, enter XLANG for Database, and then click Next.
  8. In the Completing the Microsoft BizTalk Server 2000 Setup Wizard screen, click Finish.

Installing BizTalk Server 2000 SP1a on the secondary BizTalk Server

Use the following procedure on the secondary BizTalk Server to install BizTalk Server 2000 Service Pack 1a (SP1a).

  1. Ensure that the BizTalk Server 2000 Enterprise Edition CD is in the CD-ROM drive.
  2. Run the BTS2000_SP1a_EN.EXE file from the local drive. You cannot install BizTalk Server 2000 SP1a if you run this file from a CD.
  3. In the Resuming the Microsoft BizTalk Server 2000 Setup Wizard screen, click Next. This step starts the installation process.
  4. In the Completing the Microsoft BizTalk Server 2000 Setup Wizard screen, click Finish.
  5. In the Microsoft BizTalk Server 2000 Installer Information dialog box that advises you to restart the server, click Yes.
  6. Restart the server.
  7. Install the stored procedure on the Shared Queue database:

    1. On the Start menu, point to Programs, point to Microsoft SQL Server, and click Query Analyzer.

    2. In the SQL Server list, click the name of the SQL Server that hosts the Shared Queue database, enter the appropriate login information, and click OK.

    3. f you have Microsoft SQL Server 7.0 installed, in the DB list, click the name of the Shared Queue database and continue to step 5.

      For example: InterchangeSQ

      —Or—

      If you have Microsoft SQL Server 2000 installed, on the Query menu, click Change Database.

    4. Click the name of the Shared Queue database and click OK.

      For example: InterchangeSQ

    5. On the File menu, click Open.

    6. In the Open Query File dialog box, in the Look in list, browse to \Program Files\Microsoft BizTalk Server\Setup.

    7. Click CleanQueuesPatch.sql and click Open.

    8. On the Query menu, click Execute.

  8. Install the stored procedure on the BizTalk Messaging Management database:

    1. On the Start menu, point to Programs, point to Microsoft SQL Server, and then click Query Analyzer.

    2. In the SQL Server list, click the name of the SQL Server instance that hosts the BizTalk Messaging Management database, enter the appropriate login information, and click OK.

    3. If you have Microsoft SQL Server 7.0 installed, in the DB list, click the name of the BizTalk Messaging Management database (for example, InterchangeBTM) and continue to step 5.

      —Or—

      If you have Microsoft SQL Server 2000 installed, on the Query menu, click Change Database and continue to step 4.

    4. Click the name of the BizTalk Messaging Management database (for example, InterchangeBTM) and click OK.

    5. On the File menu, click Open.

    6. In the Open Query File dialog box, in the Look in list, browse to \Program Files\Microsoft BizTalk Server\Setup.

    7. Click ControlNumbers.sql and click Open.

    8. On the Query menu, click Execute.

Verifying SP1a Installation on the secondary BizTalk Server

To verify that BizTalk Server 2000 SP1a has been installed, view the file properties for any of the DLLs (except setupex.dll) in the BizTalk Server 2000 installation directory.

  1. In Windows Explorer, browse to the BizTalk Server 2000 installation directory, and select and right-click any DLL file (except setupex.dll).
  2. Click Properties.
  3. On the Version tab, confirm that the version number is 1764 and click OK.

Installing BizTalk Accelerator for HIPAA

This section provides instructions for installing BizTalk Accelerator for HIPAA on the BizTalk Server cluster. Specifically, this section describes how to:

  • Install Accelerator for HIPAA on the primary BizTalk Server cluster.
  • Install Accelerator for HIPAA on the secondary BizTalk Server cluster.
  • Change the order of the parsers.

Installing Accelerator for HIPAA on the primary BizTalk Server Cluster

Use the following procedure on the primary BizTalk Server to install Microsoft BizTalk Accelerator for HIPAA. The primary server is considered the active server (the server owning the cluster resources). The secondary server is considered the inactive server (the server that does not own the cluster resources).

  1. On the Microsoft BizTalk Accelerator for HIPAA CD, run Microsoft BizTalk Accelerator for HIPAA Enterprise (Select).Msi. This step will start the Microsoft BizTalk Accelerator for HIPAA Setup Wizard.
  2. In the Welcome to the InstallShield Wizard for Microsoft BizTalk Accelerator for HIPAA screen, click Next.
  3. In the License Agreement screen, read the End-User License Agreement (EULA), select I accept the terms in the license agreement to proceed with installation, and then click Next.
  4. In the Customer Information screen, enter your User name and Organization, and, in the Install this application for: area, click either Anyone who uses this computer or Only for me, and then click Next.
  5. In the Destination Folder screen, click Change to select a folder for installation, or click Next to use the default installation folder.
  6. On the Setup Type page, click Complete for your setup preference. Click Next.
  7. In the Ready to Install the Program screen, click Install. This step will start the installation process.
  8. In the Setup Wizard Completed screen, click Finish.

Installing Accelerator for HIPAA on the secondary BizTalk Server Cluster

After installing Accelerator for HIPAA on the primary BizTalk Server, you must install it on the secondary BizTalk Server. Before installing Accelerator for HIPAA on the secondary BizTalk Server, fail over the cluster resources to the secondary BizTalk Server so that this server owns the cluster resources. Installation of Accelerator for HIPAA on the secondary BizTalk Server will fail if the cluster resources are still owned by the primary BizTalk Server. Use the following procedure to install Accelerator for HIPAA on the secondary BizTalk Server:

  1. On the Microsoft BizTalk Accelerator for HIPAA CD, run Microsoft BizTalk Accelerator for HIPAA Enterprise (Select).Msi This step will start the Microsoft BizTalk Accelerator for HIPAA Setup Wizard.
  2. In the Welcome to the InstallShield Wizard for Microsoft BizTalk Accelerator for HIPAA screen, click Next.
  3. In the License Agreement screen, read the End-User License Agreement (EULA), select I accept the terms in the license agreement to proceed with installation, and then click Next.
  4. In the Customer Information screen, enter your User name and Organization and, in the Install this application for: area, click either Anyone who uses this computer or Only for me, and then click Next.
  5. In the Destination Folder screen, click Change to select a folder for installation, or click Next to use the default installation folder.
  6. On the Setup Type page, click Complete for your setup preference. Click Next.
  7. In the Ready to Install the Program screen, click Install. This step will start the installation process.
  8. In the Setup Wizard Completed screen, click Finish.

Changing the order of the parsers

  1. Click Start, point to Programs, point to Microsoft BizTalk Server 2000, and then click BizTalk Server Administration.
  2. The BizTalk Server Administration dialog box appears.
  3. Expand Microsoft BizTalk Server 2000 and click BizTalk Server Group.
  4. On the Action menu, click Properties.
  5. The BizTalk Server Group Properties dialog box appears.
  6. Click the Parsers tab.
  7. In the Arrange the server call sequence box, click the parser that you want to move and click the up or down arrow to move the selected parser higher or lower in the server call sequence.
  8. When the parsers are arranged in the order you want, click OK.

Configuring the BizTalk Messaging Service

Use the following procedure on both BizTalk Servers to configure the BizTalk Messaging Service.

  1. Click Start, point to Programs, point to Administrative Tools, and then click Services.
  2. In the Services window, right-click BizTalk Messaging Service, and click Properties.
  3. In the BizTalk Messaging Service Properties dialog box, click the Log on tab. Make sure that the startup account is a domain account with sufficient permissions. This account must be a local administrator on each BizTalk Server. If the BizTalk Servers write to Message Queuing or to any file shares on other servers in the network, they will require sufficient domain-level permissions.
  4. Click the General tab. For Startup type, select Manual. For Service Status, click Stop, and then click OK.

Configuring the BizTalk Server Group

Use the BizTalk Server Administration application to configure the BizTalk Server Group as described in the following procedure:

  1. Click Start, point to Programs, point to Microsoft BizTalk Server 2000, and then click BizTalk Server Administration.
  2. In the BizTalk Server Administration window, expand Microsoft BizTalk Server 2000, and then expand BizTalk Server Group.
  3. Right-click each of the servers, and then click Delete.
  4. Right-click BizTalk Server Group, point to New, and then click Server.
  5. In the New Server screen, type LSBTCLUSTER for BizTalk Server name, and click OK. Under BizTalk Server Group, make sure that only LSBTCLUSTER is listed.

Adding a cluster resource for BizTalk Messaging

Before adding a cluster resource for the BizTalk Messaging Service, you should verify that the BizTalk Messaging Service is not running on either server and is set to start manually. Use the following procedure to verify the status of the BizTalk Messaging Service and change its startup type:

  1. Click Start, point to Programs, point to Administrative Tools, and then click Services.
  2. In the Services window, in the details pane, BizTalk Messaging Service should be listed as a service and its status should be blank.
  3. Right-click BizTalk Messaging Service, and then click Properties.
  4. In the BizTalk Messaging Service Properties dialog box, click the General tab. Under Startup type, select Manual from the drop-down list, and then click OK.

Use the following procedure to add a cluster resource for BizTalk Messaging on the primary BizTalk Server:

  1. In the Cluster Administrator window, right-click BizTalk Cluster Group, point to New, and then click Resource.

  2. In the New Resource screen, enter the following information:

    Field Enter
    Name BizTalk Messaging Service
    Description BizTalk Messaging Service
    Resource type Generic Service
    Group BizTalk Cluster Group

    After entering this information, click Next.

  3. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  4. In the Dependencies screen, under Available resources, select Disk E, and then click Add. Select Virtual Network Name, and then click Add. Select MSDTC, and then click Add. Select Virtual MSMQ, click Add, and then click Next.

  5. In the Generic Service Parameters screen, enter BTSSvc for Service name, and then click Next. Make sure the check box next to Use Network Name for computer name is selected.

  6. Select defaults for the remaining screens, and then click Finish.

Configuring a cluster repository

To guard against a failure of a local drive containing the BizTalk Server repository information, the files can be placed on a shared cluster disk resource. BizTalk Server and the tools provided use a feature of IIS called Web Distributed Authoring and Versioning (WebDAV) to read and write the repository data. Rather than locking IIS to a specific cluster member that could fail, the IIS instance should also be made into a virtual IIS instance that can run transparently on either BizTalk Server. Use the following procedure on the primary BizTalk Server to configure a cluster repository:

  1. Create a folder on the shared storage unit called E:\Program Files\Microsoft BizTalk Server\BizTalkServerRepository.

  2. Copy the contents from the <drive:>\Program Files\Microsoft BizTalk Server\BizTalkServerRepository folder to this folder.

  3. Right-click BizTalk Cluster Group, point to New, and then click Resource.

  4. In the New Resource screen, enter the following information.

    Field Enter
    Name IIS WebDAV
    Description IIS WebDAV
    Resource type IIS Server Instance
    Group BizTalk Cluster Group

    After entering this information, click Next.

  5. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  6. In the Dependencies screen, under Available resources, select Disk E, and then click Add. Select Virtual Network Name, and then click Add. Select Virtual IP Address, click Add, and then click Next.

  7. In the Parameters screen, select WWW. For IIS Server, select Default Web Site from the drop-down list, and then click Finish.

  8. In the Cluster Administrator dialog box informing you that the cluster resource "IIS WebDav" was created successfully, click OK.

  9. Click Start, point to Programs, point to Administrative Tools, and then click Internet Services Manager.

  10. In the Internet Information Services window, right-click Internet Information Services, and then click Connect.

  11. In the Connect to Computer dialog box, type LSBTCLUSTER, and then click OK.

  12. Expand Default Web Site, right-click BizTalkServerRepository, and then click Properties.

  13. In the BizTalkServerRepository Properties dialog box, on the Virtual Directory tab, for Local Path, type E:\Program Files\Microsoft BizTalk Server\BizTalkServerRepository, and then click OK.

  14. Open a command prompt window and change to the <drive:>\winnt\system32\InetSrv directory. Type IISSYNC Server Name, where Server Name is the computer name of the local BizTalk Server. This command synchronizes the settings on both BizTalk Servers. The following text is an example of what might be displayed:

    <drive:>\WINNT\system32\inetsrv>IISSYNC LITWARE1
Source : 130, scanned, Targets : (130,0),
Replication successful for target LITWARE1
Replication was successful

  15. Make sure that the default site shows Started in the Internet Information Services window for the virtual server name.

  16. In the Cluster Administrator window, expand BizTalk Cluster Group, right-click Manage Virtual MSMQ resource, and select Take Offline. After the resource is offline, right-click the same resource and click Properties.

  17. In the Properties dialog box, click the Dependencies tab, and add the IIS WebDav resource as an additional dependency.

  18. Make sure that the default site shows Running in the Internet Information Services window for the virtual network name, LSBTCLUSTER. To start the resource, bring it online using Cluster Administrator.

  19. Click Start, point to Programs, point to Microsoft BizTalk Server 2000, and then click BizTalk Messaging Manager.

  20. In the BizTalk Messaging Manager window, click Options from the Tools menu. Make sure that Name of the BizTalk Server to connect to is BizTalk Cluster Group.

  21. Move the resource group to the other BizTalk Server and verify once again that BizTalk Messaging Manager can successfully use the virtual IIS network name, LSBTCLUSTER.

Setting the proper security identity for the XLANG Scheduler

To avoid unnecessary security issues, the XLANG Scheduler should be configured to run under the identity of a domain account that has all the necessary permissions both for the local server and for any other servers that will be accessed through XLANG schedules. You can use the same account that was used when installing Cluster service, because this account has administrative privileges on all servers. Use the following procedure on both BizTalk Servers to set the proper security identity for running the XLANG Scheduler:

  1. Click Start, point to Programs, point to Administrative Tools, and then click Component Services.
  2. In the Component Services window, expand Component Services, expand Computers, expand My Computer, expand COM+ Applications, right-click XLANG Scheduler, and then click Properties.
  3. In the XLANG Scheduler Properties dialog box, click the Advanced tab. Clear the check box for Disable Changes, and then click OK.
  4. In the Warning dialog box that asks for confirmation, click Yes.
  5. Right-click XLANG Scheduler again, and then click Properties.
  6. In the XLANG Scheduler Properties dialog box, click the Identity tab. Select This user, and enter Contosointranet\BTA4H as the User. Enter and confirm the password.
  7. Click the Advanced tab. Select the check box for Disable Changes, and then click OK.
  8. Repeat the same steps for changing the BizTalk Server Interchange Application.

Adding a cluster resource for the XLANG Scheduler

The XLANG Scheduler can be configured to reside in the same cluster resource group as BizTalk Messaging, or in a separate group. The advantage of creating a separate cluster resource group for BizTalk Orchestration is that the XLANG Scheduler can optionally run on the other node in the cluster. This helps to optimize the use of both nodes in the cluster while providing the maximum performance for each component.

If the XLANG Scheduler resource is placed in a different group from the BizTalk Messaging resource, you must use an application instead of a BizTalk Messaging port to start the XLANG schedules. This is because BizTalk Messaging can only start XLANG schedules that are local (on the same virtual server). Use the following procedure on the primary BizTalk Server to add a cluster resource for the XLANG Scheduler.

  1. In the Cluster Administrator window, right-click BizTalk Cluster Group, point to New, and then click Resource.

  2. In the New Resource screen, enter the following information.

    Field Enter
    Name XLANG Scheduler
    Description XLANG Scheduler
    Resource type Generic Application
    Group BizTalk Cluster Group

    After entering this information, click Next.

  3. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  4. In the Dependencies screen, under Available resources, select Disk E, and then click Add. Select Virtual Network Name, and then click Add. Select MSDTC, and then click Add. Select Virtual MSMQ, click Add, and then click Next.

  5. In the Generic Application Parameters screen, for Command Line window, type dllhost.exe /ProcessId:{DFDE2592-40A4-42BC-A35E-FD0BF76CA4D5}.

  6. For Current Directory, type E:\.

  7. Select Allow application to interact with desktop and Use Network Name for computer name, and then click Finish.

  8. In the Cluster Administrator dialog box stating that the cluster resource "XLANG Scheduler" was created successfully, click OK.

  9. On Cluster Administrator, right-click XLANG Scheduler, and then click Properties.

  10. In the XLANG Scheduler Properties dialog box, click the Advanced tab. Clear the check box for Affect the Group, select Do not restart, and then click OK.

Adding a cluster resource for the XLANG Schedule Restart Service

The XLANG Schedule Restart Service cluster resource ensures that the XLANG Scheduler is started and stopped in a controlled manner.

When it is brought online, it immediately starts the XLANG Scheduler (because it is specified as a resource dependency) and then recycles any previously persisted XLANG schedules.

When it is brought offline, the XLANG Scheduler attempts to gracefully stop all currently running XLANG schedules, in some cases persisting their state, before shutting down.

Use the following procedure on the primary BizTalk Server to add a cluster resource for the XLANG Schedule Restart Service:

  1. In the Cluster Administrator window, right-click BizTalk Cluster Group, point to New, and then click Resource.

  2. In the New Resource screen, enter the following information:

    Field Enter
    Name XLANG Schedule Restart Service
    Description XLANG Schedule Restart Service
    Resource type Generic Service
    Group BizTalk Cluster Group

    After entering this information, click Next.

  3. In the Possible Owners screen, under Available nodes, select each node, and then click Add. Repeat this step for all nodes under Available nodes, and then click Next.

  4. In the Dependencies screen, under Available resources, select Virtual Network Name, and then click Add. Select XLANG Scheduler, and then click Next.

  5. In the Generic Service Parameters screen, type BTWSvcMgr for Service Name, select Use Network Name for computer name, and then click Next.

  6. In the Registry Replication window, click Finish.

  7. In the dialog box that confirms the "XLANG Schedule Restart Service" was created successfully, click OK.

  8. After the XLANG Schedule Restart Service has been added, right-click XLANG Schedule Restart Service, and then click Properties.

  9. In the XLANG Schedule Restart Service Properties dialog box, click the Advanced tab. Clear the check box for Affect the Group, select Do not restart, and then click OK.

  10. Test the resource by bringing it online. The XLANG Scheduler resource should also start automatically.

Starting and stopping the XLANG Schedule Restart Service

To start the XLANG Scheduler, always set the XLANG Schedule Restart Service online. Because of the resource dependency that has been set up, the XLANG Scheduler resource also comes online automatically.

To stop the XLANG Scheduler resource correctly, set the XLANG Scheduler offline. Because of the dependency that has been set up, the XLANG Schedule Restart Service resource will be set offline first, followed by the XLANG Scheduler resource.

Completing the Deployment

Before you connect your solution to the public Internet, complete the following steps to ensure the safety of the network:

  1. Apply the prescribed service packs for all software on all servers.
  2. Apply the IIS lockdown tool and any known hotfixes from https://www.microsoft.com/security. Make sure that you obtain the latest version of IISLockdown for installation on the BizTalk Servers. It must be later then version 1.0 that was posted on August 23, 2001.
  3. Close all unnecessary ports on all servers. Commenting out the unnecessary ports in the services file can do this.
  4. Disable all unnecessary services that might potentially expose security holes that can be exploited by malicious users. Consider disabling the following services:
    • Terminal Services
    • SMTP
    • Remote registry service
    • RunAs service
    • RRAS
    • NNTP
    • Messenger
    • IIS Admin service
    • Front Page extensions
    • Sample sites
    • FTP
    • Administration site
  5. Under Application Mappings in IIS, remove everything except the .asp extension.
  6. Under Advanced Settings for the network adapters connected to the public network, disable bindings for File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks.

Uninstalling BizTalk Accelerator for HIPAA

To uninstall Microsoft BizTalk Accelerator for HIPAA and all of its components, you must run the InstallShield Wizard or use the Microsoft Windows 2000 Add/Remove Programs utility on the Start menu.

Removing Accelerator for HIPAA by using the Windows 2000 Add/Remove Programs Utility

Use the following procedure to remove Accelerator for HIPAA by using the Windows 2000 Add/Remove Programs utility:

  1. Click Start, point to Settings, and then click Control Panel.
  2. In the Control Panel window, double-click Add/Remove Programs.
  3. In the Add/Remove Programs screen, click Microsoft BizTalk Accelerator for HIPAA, and then click Remove. The Add/Remove Programs dialog box appears.
  4. Click Yes when prompted to remove BizTalk Accelerator for HIPAA.

Secure Online Data Submission Scenario

Securing a BizTalk environment

Although this deployment guide does not detail the steps in establishing a preferred security model for HIPAA transaction submission, future documents from Microsoft will describe in full detail the best practices for deploying a secure online HIPAA data submission scenario. See Appendix 3, Security Configuration, for how current Microsoft products align with the security requirements from HIPAA and the Center for Medicaid and Medicare Services (CMS).

The following illustration shows how one might approach creating a secure Internet zone for online Web submission of HIPAA transactions.

Figure 4.

Include well-tested Web site code

  1. Depending on the transaction sets or specific processes involved with your Web site solution, you need to include all code modules, ASP pages, COM+ components, and so on for the site to function.
  2. It is preferable to submit your document using MSMQ because this enables a guaranteed document submission. MSMQ messages can be passed through the ISA firewall between the DMZ Web Servers and the BizTalk intranet.
  3. Do intensive logical and performance tuning in a test environment that comes as close to modeling the production environment as possible.

Known Issues

You might encounter the following issues while performing the deployment:

  • The SQL Server and BizTalk Server clusters cannot fail over to the secondary node if the public network connection on the secondary node is disconnected. It is unreliable to fail over to that node if the secondary node does not have a network connection.
  • The failover period for the SQL Server and BizTalk Server clusters is generally around 30 to 60 seconds. A failover can be caused by a disconnected network connection, disconnected SCSI connection to the shared storage unit, or loss of power to the primary server. During this time, any functionality that requires these services will not work, including Cluster Administrator functionality.
  • The BizTalk Server must be the owner of the cluster resources in order to install or uninstall Accelerator For HIPAA.
  • For high availability, the external ISA Server can be configured in an array. Because the intranet ISA Server is used for server publishing, you cannot configure this server in an array. To provide high availability on the intranet ISA Server, use a third-party switch or software solution. For information about these third-party products, visit Partners: High Availability and Load Balancing.
  • If the shared storage unit loses power, shut down both servers in the cluster and restart them one at a time. You might need to run the Configuration Utility Program during boot up and force any failed disks to come back online.
  • After failover has occurred on the SQL Server cluster, verify that your site is available by trying to access it by using Internet Explorer.
  • When installing Accelerator for HIPAA on BizTalk Server, the log-on account is case-sensitive. For the example used in this document, use BTA4H.
  • You should always reboot your servers after installing or uninstalling Accelerator for HIPAA.
  • If messages are stuck in the Retry queue, you must move them to the Suspended queue and then resubmit them.
  • If the active SQL Server loses power or if the SCSI connection is removed, you might get an error message stating that Windows was unable to save all the data for the file \Device\HarddiskVolume5\MSSQL\LOG\SQLAGENT.OUT.
  • If network connections are disabled or lost on both servers in a cluster, and the network connection is enabled or reconnected, the cluster administrator might not automatically go back online. You might have to manually force it online by using Cluster Administrator (right-click the cluster group and select Force Online).
  • If you disconnect the public network connection on the inactive cluster node and then disconnect the public network connection on the active node, Cluster Administrator will still show that all resources are online, even though there is no network connection.
  • If you reconnect the public network connection on the inactive cluster node, you would expect that the cluster resources would fail over to the inactive cluster node (because there is no public network connection on the active node). However, this is not the case. Cluster Administrator will only fail over if you force it manually. It will not automatically fail over.
  • If you disable the public network connection from My Network Places on the inactive cluster node and then disable the public network connection on the active node, Cluster Administrator will show that resources have failed or are offline.
  • When you enable both public network connections again, Cluster Administrator does not automatically go online. You have to manually set the resources online. To set the resources online, right-click the cluster group and select Bring Online.
  • If the BizTalk Server cluster fails over while transactions are taking place, some private queues that were created might not be cleaned up properly. These queues have the name port_1{GUID}, and can be deleted manually.
  • For enterprise deployments, the Web servers must have unique computer names. Even across separate domains, you might encounter problems when refreshing catalogs if the computer names are not unique.

URL Resources

The following URLs provide additional information about the corresponding subject areas:

Appendix 1: Cluster Service Installation Process

This step-by-step guide provides instructions for installing Cluster service on servers running the Windows 2000 Advanced Server and Windows 2000 Datacenter Server operating systems. The guide describes the process of installing Cluster service on cluster nodes. It is not intended to explain how to install cluster applications. Rather, it guides you through the process of installing a typical two-node cluster.

A server cluster is a group of independent servers running Cluster service and working collectively as a single system. Server clusters provide high-availability, scalability, and manageability for resources and applications by grouping multiple servers running Windows 2000 Advanced Server or Windows 2000 Datacenter Server.

The purpose of server clusters is to preserve client access to applications and resources during failures and planned outages. If one of the servers in the cluster is unavailable due to failure or maintenance, resources and applications move to another available cluster node.

For clustered systems, the term high availability is used rather than fault-tolerant, because fault-tolerant technology offers a higher level of resilience and recovery. Fault-tolerant servers typically use a high degree of hardware redundancy plus specialized software to provide near-instantaneous recovery from any single hardware or software fault. These solutions cost significantly more than a clustering solution because organizations must pay for redundant hardware that waits idly for a fault. Fault-tolerant servers are used for applications that support high-value, high-rate transactions such as check clearinghouses, automated teller machines (ATMs), or stock exchanges.

While Cluster service does not guarantee non-stop operation, it provides availability sufficient for most mission-critical applications. Cluster service can monitor applications and resources, automatically recognizing and recovering from many failure conditions. This provides greater flexibility in managing the workload within a cluster, and improves overall availability of the system.

Cluster service benefits include:

  • High availability. With Cluster service, ownership of resources such as disk drives and IP addresses is automatically transferred from a failed server to a surviving server. When a system or application in the cluster fails, the cluster software restarts the failed application on a surviving server, or disperses the work from the failed node to the remaining nodes. As a result, users experience only a momentary pause in service.
  • Failback. Cluster service automatically rebalances the workload in a cluster when a failed server comes back online.
  • Manageability. You can use the Cluster Administrator to manage a cluster as a single system and to manage applications as if they were running on a single server. You can move applications to different servers within the cluster by dragging and dropping cluster objects. You can move data to different servers in the same way. This can be used to manually balance server workloads and to unload servers for planned maintenance. You can also monitor the status of the cluster, all nodes and resources from anywhere on the network.
  • Scalability. Cluster services can grow to meet rising demands. When the overall load for a cluster-aware application exceeds the capabilities of the cluster, additional nodes can be added.

Checklists for Cluster Server Installation

These checklists assist you in preparing for installation. Step-by-step instructions begin after the checklists.

Software requirements

  • Microsoft Windows 2000 Advanced Server or Windows 2000 Datacenter Server installed on all computers in the cluster.
  • A name resolution method such as Domain Naming System (DNS), Windows Internet Naming System (WINS), HOSTS, and so on.
  • Terminal Server is recommended to allow remote cluster administration.

Hardware requirements

  • The hardware for a Cluster service node must meet the hardware requirements for Windows 2000 Advanced Server or Windows 2000 Datacenter Server. These requirements can be found at the Product Compatibility Search page.
  • Cluster hardware must be on the Cluster Service Hardware Compatibility List (HCL). The latest version of the Cluster Service HCL can be found by going to the Windows Hardware Compatibility List and then searching on Cluster.
  • Two HCL-approved computers, each with the following:
    • A boot disk with Windows 2000 Advanced Server or Windows 2000 Datacenter Server installed. The boot disk cannot be on the shared storage bus described below.
    • Boot disks and shared disks must be on separate SCSI channels (SCSI PathID); separate adapters (SCSI PortNumber) are not required. Thus, you can use a single multi-channel SCSI or Fibre Channel adapter for both boot and shared disks.
    • Two PCI network adapters on each machine in the cluster.
    • An HCL-approved external disk storage unit that connects to all computers. This will be used as the clustered disk. A redundant array of independent disks (RAID) is recommended.
    • Storage cables to attach the shared storage device to all computers. Refer to the manufacturer's instructions for configuring storage devices. If an SCSI bus is used, see Appendix 2 for additional information.
    • All hardware should be identical, slot for slot, card for card, for all nodes. This will make configuration easier and eliminate potential compatibility problems.

Network requirements

  • A unique NetBIOS cluster name.
  • Five unique, static IP addresses: two for the network adapters on the private network, two for the network adapters on the public network, and one for the cluster itself.
  • A domain user account for Cluster service (all nodes must be members of the same domain).
  • Each node should have two network adapters—one for connection to the public network and the other for the node-to-node private cluster network. If you use only one network adapter for both connections, your configuration is unsupported. A separate private network adapter is required for HCL certification.

Shared disk requirements:

  • All shared disks, including the quorum disk, must be physically attached to a shared bus.
  • Verify that disks attached to the shared bus can be seen from all nodes. This can be checked at the host adapter setup level. Refer to the manufacturer's documentation for adapter-specific instructions.
  • SCSI devices must be assigned unique SCSI identification numbers and properly terminated, as per manufacturer's instructions. See Appendix 2 for information about installing and terminating SCSI devices.
  • All shared disks must be configured as basic (not dynamic).
  • All partitions on the disks must be formatted as NTFS.

While not required, the use of fault-tolerant RAID configurations is strongly recommended for all disks. The key concept here is fault-tolerant RAID configurations—not stripe sets without parity.

Power Sequencing for Cluster Service Installation

During the installation process, some nodes will be shut down and some nodes will be rebooted. These steps are necessary to guarantee that the data on disks that are attached to the shared storage bus is not lost or corrupted. This can happen when multiple nodes try to simultaneously write to the same disk that is not yet protected by the cluster software.

Use the following table to determine which nodes and storage devices should be powered on during each step.

The steps in this guide are for a two-node cluster. However, if you are installing a cluster with more than two nodes, you can use the Node 2 column to determine the required state of other nodes.

Step Node 1 Node 2 Storage Comments
Setting up Networks On On Off Verify that all storage devices on the shared bus are powered off. Power on all nodes.
Setting up shared disks On Off On Shut down all nodes. Power on the shared storage, and then power on the first node.
Verifying disk configuration Off On On Shut down the first node, power on the second node. Repeat for nodes 3 and 4 if necessary.
Configuring the first node On Off On Shut down all nodes; power on the first node.
Configuring the second node On On On Power on the second node after the first node was successfully configured. Repeat for nodes 3 and 4 if necessary.
Post-installation On On On At this point all nodes should be on.

Setting Up Shared Disks

Warning   Make sure that Windows 2000 Advanced Server or Windows 2000 Datacenter Server and the Cluster service are installed and running on one node before starting an operating system on another node. If the operating system is started on other nodes before the Cluster service is installed, configured, and running on at least one node, the cluster disks will probably be corrupted.

To proceed, power off all nodes. Power up the shared storage devices and then power up node one.

About the quorum disk

The quorum disk is used to store cluster configuration database checkpoints and log files that help manage the cluster. We make the following quorum disk recommendations:

  • Create a small partition (a minimum of 50 MB to be used as a quorum disk; we generally recommend a quorum disk to be 500 MB).
  • Dedicate a separate disk for a quorum resource. Because the failure of the quorum disk would cause the entire cluster to fail, we strongly recommend you use a volume on a RAID disk array.

During the Cluster service installation, you must provide the drive letter for the quorum disk. In our example, we use the letter Q.

Configuring shared disks

  1. Right-click My Computer, click Manage, and then click Storage.
  2. Double-click Disk Management.
  3. Verify that all shared disks are formatted as NTFS and are designated as Basic. If you connect a new drive, the Write Signature and Upgrade Disk Wizard starts automatically. If this happens, click Next to go through the wizard. The wizard sets the disk to Dynamic. To reset the disk to Basic, right-click Disk # (where # specifies the disk you are working with) and click Revert to Basic Disk.
  4. Right-click unallocated disk space.
  5. Click Create Partition.
  6. The Create Partition Wizard begins. Click Next twice.
  7. Enter the desired partition size in MB and click Next.
  8. Accept the default drive letter assignment by clicking Next.
  9. Click Next to format and create the partition.

Assigning drive letters

After the bus, disks, and partitions have been configured, drive letters must be assigned to each partition on each clustered disk. You will have three drives: E is the database data drive, F is the transaction logs for the InterchangeDTA and InterchangeBTM databases, and G is the transaction logs for the InterchangeSQ and XLANG databases.

Note Mountpoints is a feature of the file system that allows you to mount a file system using an existing directory without assigning a drive letter. Mountpoints is not supported on clusters. Any external disk used as a cluster resource must be partitioned using NTFS partitions and must have a drive letter assigned to it.

  1. Right-click the desired partition and select Change Drive Letter and Path.

  2. Select a new drive letter.

  3. Repeat steps 1 and 2 for each shared disk.

    When you are finished, the Computer Management window should look like the following figure.

    Figure 5.

  4. Close the Computer Management window.

Verifying disk access and functionality

  1. Click Start, click Programs, click Accessories, and then click Notepad.
  2. Type some words into Notepad and use the File/Save As command to save it as a test file called test.txt. Close Notepad.
  3. Double-click the My Documents icon.
  4. Right-click test.txt and click Copy.
  5. Close the window.
  6. Double-click My Computer.
  7. Double-click a shared drive partition.
  8. Click Edit and click Paste.
  9. A copy of the file should now reside on the shared disk.
  10. Double-click test.txt to open it on the shared disk. Close the file.
  11. Highlight the file and press the DELETE key to delete it from the clustered disk.
  12. Repeat the process for all clustered disks to verify they can be accessed from the first node.

At this time, shut down the first node, power on the second node and repeat the preceding steps. Repeat again for any additional nodes. When you have verified that all nodes can read and write from all disks, turn off all nodes except the first, and continue with this installation process.

Installing Cluster Service Software

Configuring the first node

Note During installation of Cluster service on the first node, all other nodes must either be turned off, or stopped prior to Windows 2000 booting. All shared storage devices should be powered up.

In the first phase of installation, all initial cluster configuration information must be supplied so that the cluster can be created. This is accomplished by using the Cluster Service Configuration Wizard.

  1. Click Start, click Settings, and then click Control Panel.

  2. Double-click Add/Remove Programs.

  3. Double-click Add/Remove Windows Components.

  4. Select Cluster Service. Click Next.

  5. Cluster service files are located on the Windows 2000 Advanced Server or Windows 2000 Datacenter Server CD-ROM. Enter x:\i386 (where x is the drive letter of your CD-ROM). If Windows 2000 was installed from a network, enter the appropriate network path instead. (If the Windows 2000 Setup flash screen appears, close it.) Click OK.

  6. Click Next.

  7. The following window appears. Click I Understand to accept the condition that Cluster service is supported on hardware from the Hardware Compatibility List only.

    Figure 6.

  8. Because this is the first node in the cluster, you must create the cluster itself. Select The first node in the cluster, as shown in the following figure, and then click Next.

    Figure 7.

  9. Enter a name for the cluster (up to 15 characters), and click Next. (In our example, we name the cluster MyCluster.)

  10. Type the user name of the Cluster service account that was created during the pre-installation. (In our example, this user name is cluster.) Leave the password blank. Type the domain name, and click Next.

    Note You would normally provide a secure password for this user account.

    At this point the Cluster Service Configuration Wizard validates the user account and password.

  11. Click Next.

Configuring cluster disks

Note By default, all SCSI disks not residing on the same bus as the system disk will appear in the Managed Disks list. Therefore, if the node has multiple SCSI buses, some disks might be listed that are not to be used as shared storage (for example, an internal SCSI drive). Such disks should be removed from the Managed Disks list.

  1. The Add or Remove Managed Disks dialog box shown in the following figure specifies which disks on the shared SCSI bus will be used by Cluster service. Add or remove disks as necessary and then click Next.

    Figure 8.

    Note that because logical drives F and G exist on a single hard disk, they are seen by Cluster service as a single resource. The first partition of the first disk is selected as the quorum resource by default. Change this to denote the small partition that was created as the quorum disk (in our example, drive Q). Click Next.

    In production clustering scenarios you must use more than one private network for cluster communication to avoid having a single point of failure. Cluster service can use private networks for cluster status signals and cluster management. This provides more security than using a public network for these roles. You can also use a public network for cluster management, or you can use a mixed network for both private and public communications. In any case, make sure at least two networks are used for cluster communication, because using a single network for node-to-node communication represents a potential single point of failure. We recommend that multiple networks be used, with at least one network configured as a private link between nodes and other connections through a public network. If you have more than one private network, make sure that each uses a different subnet, because Cluster service recognizes only one network interface per subnet.

    This document is built on the assumption that only two networks are in use. It shows you how to configure these networks as one mixed and one private network.

    The order in which the Cluster Service Configuration Wizard presents these networks can vary. In this example, the public network is presented first.

  2. Click Next in the Configuring Cluster Networks dialog box.

  3. Make sure that the network name and IP address correspond to the network interface for the public network.

  4. Select Enable this network for cluster use.

  5. Select the option All communications (mixed network) as shown in the following figure.

    Figure 9.

  6. Click Next.

  7. The following dialog box configures the private network. Make sure that the network name and IP address correspond to the network interface used for the private network.

    Figure 10.

  8. Select Enable this network for cluster use.

  9. Select the option Internal cluster communications only (private network).

  10. Click Next.

  11. In this example, both networks are configured in such a way that both can be used for internal cluster communication. The next dialog box offers an option to modify the order in which the networks are used. Because Private Cluster Connection represents a direct connection between nodes, it is left at the top of the list. In normal operation this connection will be used for cluster communication. In case of the Private Cluster Connection failure, cluster service will automatically switch to the next network on the list—in this case Public Cluster Connection. Make sure the first connection in the list is the Private Cluster Connection and click Next.

    Important Always set the order of the connections so that the Private Cluster Connection is first in the list.

  12. Enter the unique cluster IP address (172.16.12.20) and Subnet mask (255.255.252.0), and then click Next.

    The Cluster Service Configuration Wizard shown in the following figure automatically associates the cluster IP address with one of the public or mixed networks. It uses the subnet mask to select the correct network.

    Figure 11.

  13. Click Finish to complete the cluster configuration on the first node.

    The Cluster Service Setup Wizard completes the setup process for the first node by copying the files needed to complete the installation of Cluster service. After the files are copied, the Cluster service registry entries are created, the log files on the quorum resource are created, and the Cluster service is started on the first node.

    A dialog box appears telling you that Cluster service has started successfully.

  14. Click OK.

  15. Close the Add/Remove Programs window.

Validating the Cluster installation

Use the Cluster Administrator snap-in to validate the Cluster service installation on the first node.

  • Click Start, click Programs, click Administrative Tools, and then click Cluster Administrator.

    Figure 12.

If your snap-in window is similar to the one in the preceding figure, your Cluster service was successfully installed on the first node. You are now ready to install Cluster service on the second node.

Configuring the second node

Note For this section, leave node one and all shared disks powered on. Power up the second node.

Installing Cluster service on the second node requires less time than on the first node. Setup configures the Cluster service network settings on the second node based on the configuration of the first node.

Installation of Cluster service on the second node begins exactly as for the first node. During installation of the second node, the first node must be running.

Follow the same procedures used for installing Cluster service on the first node, with the following differences:

  1. In the Create or Join a Cluster dialog box, select The second or next node in the cluster, and click Next.
  2. Enter the cluster name that was previously created (in this example, MyCluster), and click Next.
  3. Leave Connect to cluster as cleared. The Cluster Service Configuration Wizard will automatically supply the name of the user account selected during the installation of the first node. Always use the same account that you used when setting up the first cluster node.
  4. Enter the password for the account (if there is one) and click Next.
  5. At the next dialog box, click Finish to complete configuration.
  6. The Cluster service will start. Click OK.
  7. Close Add/Remove Programs.

If you are installing additional nodes, repeat these steps to install Cluster service on all other nodes.

Verifying Installation

There are several ways to verify a successful installation of Cluster service. Here is a simple one:

  • Click Start, click Programs, click Administrative Tools, and then click Cluster Administrator.

    The presence of two nodes (HQ-RES-DC01 and HQ-RES-DC02 in the following figure) shows that a cluster exists and is in operation.

    Figure 13.

Appendix 2: SCSI Drive Installations

This appendix is provided as a generic instruction set for SCSI drive installations. If the SCSI hard disk vendor's instructions conflict with the instructions here, always use the instructions supplied by the vendor.

The SCSI bus listed in the hardware requirements must be configured prior to installation of Cluster services. This includes:

  • Configuring the SCSI devices.
  • Configuring the SCSI controllers and hard disks to work properly on a shared SCSI bus.
  • Properly terminating the bus. The shared SCSI bus must have a terminator at each end of the bus. It is possible to have multiple shared SCSI buses between the nodes of a cluster.

In addition to the information on the following pages, refer to the documentation from the manufacturer of the SCSI device or the SCSI specifications, which can be ordered from the American National Standards Institute (ANSI). The ANSI Web site contains a catalog that can be searched for the SCSI specifications.

Configuring the SCSI Devices

Each device on the shared SCSI bus must have a unique SCSI ID. Because most SCSI controllers default to SCSI ID 7, part of configuring the shared SCSI bus will be to change the SCSI ID on one controller to a different SCSI ID, such as SCSI ID 6. If there will be more than one disk on the shared SCSI bus, each disk must also have a unique SCSI ID.

Some SCSI controllers reset the SCSI bus when they initialize at boot time. If this occurs, the bus reset can interrupt any data transfers between the other node and disks on the shared SCSI bus. Therefore, SCSI bus resets should be disabled if possible.

Terminating the Shared SCSI Bus

Y cables can be connected to devices if the device is at the end of the SCSI bus. A terminator can then be attached to one branch of the Y cable to terminate the SCSI bus. This method of termination requires either disabling or removing any internal terminators the device might have.

Trilink connectors can be connected to certain devices. If the device is at the end of the bus, a trilink connector can be used to terminate the bus. This method of termination requires either disabling or removing any internal terminators the device might have.

Y cables and trilink connectors are the recommended termination methods, because they provide termination even when one node is not online.

Note Any devices that are not at the end of the shared bus must have their internal termination disabled.

Appendix 3: Security Configuration

This appendix addresses the security requirements from HIPAA and the Center for Medicaid and Medicare Services (CMS) rules that are relevant to the BizTalk Accelerator for HIPAA architecture. As stipulated in the HIPAA text, the requirements can be satisfied at any level of the enterprise. This allows flexibility in choosing the most reasonable method of addressing requirements.

Technologies Deployed for HIPAA Requirements

The following table lists requirements and indicates whether each requirement is addressed by this document or deferred to be addressed independently. The table further rationalizes the decision to address the requirement and indicates a related solution.

Requirements Matrix

Feature Accelerator for HIPAA system Outside Accelerator for HIPAA Explanation Action
Access Control        
Procedure for emergency access  Yes Yes BizTalk Server does not hold final data. BizTalk Server databases and folders should have more than one entity in the Administrator role.
Context-based access  No Yes BizTalk Server does not hold final data. This should be addressed in the application or process used to view the repository.
Role-based access Yes Yes BizTalk Server does not hold final data, but auditing information should be available only to entities analyzing audit data. Map a security role in BizTalk Server databases that allows analysis of BizTalk Server-related data.
User-based access No No BizTalk Server does not hold final data. None
Encryption No No BizTalk Server does not hold final data. None
Audit Controls        
Auditing mechanisms Yes Yes Transaction auditing should be built into the Orchestration process. Auditing for security-related events should be enabled for any access to data or attempt to communicate with the systems. Windows operating system and application-level auditing will be employed. Auditing at other levels of the customer's application and enterprise must also be employed.
Authorization Control        
Role-based access Yes Yes Windows security groups should be used to map entities to their respective roles. These groups can then be easily mapped to roles in databases, component services, and applications. Administrative provisioning processes should determine groups or roles that an entity belongs to. Create groups (or use existing groups) to map entities to. Ensure that these groups relate to roles that have clear-cut rules for accessing system components and data.
User-based access No Yes Explicit user-based access can be applied at other levels in the enterprise. None
Data Authentication        
Data authentication mechanisms No Yes Authentication mechanism should be applied at other levels in the enterprise. None
Entity Authentication:        
Automatic logoff Yes Yes Automatic logoff should be implemented to all entities within the system. It should also be applied to other levels of the enterprise. Set the session time-outs to 12 minutes for Web sites in IIS. Set the Kerberos session ticket expiration to 12 minutes.
Unique user identification  Yes Yes A unique identity should be mapped to each entity that uses the system, including trading partners. Deploy Active Directory. Relate each entity to a unique user name. For trading partners, issue (or use existing) digital certificates.
Biometric identification system No No None None
Password system Yes Yes A unique password should be issued or set up for each entity. Password setup will be part of administrative provisioning processes. When creating unique user, issue password. This should be part of the provisioning processes.
Personal identification number No No None None
Telephone callback No No None None
Token system No No None None
Technical Security Mechanisms for Network Communication:        
Integrity controls Yes Yes Secure Sockets Layer (SSL) should be used on Web sites when using HTTP as the transport. If not using HTTP, then a Virtual Private Network should be used. L2TP tunnels are recommended. Implement SSL on the receiving Web site. Implement tunneling capabilities on the external ISA Server.
Message authentication  Yes Yes Addressed with the use of encryption using SSL-enabled HTTP. None
Access controls Yes Yes Addressed by the use of unique user names and passwords. None
Encryption (required over non-private networks)  Yes No Addressed by the use of unique user names and passwords. None
Alarm Yes Yes Security policies should be used to audit suspicious events such as logon failures. ISA Server should be configured to log security anomalies. All these should be collected into a central repository using Microsoft Operations Manager (MOM). This should also be done at the enterprise level. Deploy domain-level security policies. Deploy MOM to consolidate events.
Audit trail Yes Yes Security policies should be used to audit security events. ISA Server should be configured to log security events. All these should be collected into a central repository using MOM. This should also be done at the enterprise level. Databases should log access at the role level. Deploy MOM to consolidate events.
Entity authentication Yes Yes Deploy Active Directory. Optionally enable Certificate Services and map certificates to users. Certificate Server enables a private certificate authority. This can also be done with externally issued certificates. Deploy Active Directory. Manage user accounts there. Deploy Certificate Server.
Event reporting Yes Yes Audit events should be collected into a central repository using MOM. This should also be done at the enterprise level. Deploy MOM to consolidate events.

Deploying Active Directory

Set up Active Directory as indicated in Setting up the Domains.

Configuring Kerberos Session Ticket Expiration

This section briefly describes the steps required to force Kerberos user session ticket lifetimes to be no longer than one hour and service session tickets to be 15 minutes. This enforces automatic logoff.

  1. On a domain controller in the domain where the BizTalk Accelerator for HIPAA solution resides, on the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Domain Security Policy Administration. The Domain Security Policy Administration console opens.
  2. Under Windows Settings, expand Security Settings Properties.
  3. Under Account Policies, select Kerberos Policy.
  4. In the details pane, double-click Maximum Lifetime for a Service Ticket.
  5. Set the length to 15 minutes, ensure that the Define This Policy Setting check box is selected, and click OK.
  6. In the details pane, double-click Maximum Lifetime for a User Ticket.
  7. Set the length to one hour, ensure that the Define This Policy Setting check box is selected, and click OK.
  8. Exit the Domain Security Policy Administration Console.

Configuring a Web Site Session to Expire in 15 Minutes

This section briefly describes the steps necessary to configure Internet Information Services (IIS) sessions to expire in 15 minutes.

  1. On the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Internet Services Manager. The Internet Services Manager console opens.
  2. Expand the items under the name of the server that represents the local server.
  3. Select the Web site that BizTalk messaging ports will use for HTTP or HTTPS.
  4. Right-click the Web site and click Properties.
  5. On the Home Directory tab, select Configuration.
  6. On the App Options tab, ensure that Enable Session State is selected.
  7. On the App Options tab, change Session State Length to 15 minutes.
  8. Click OK to exit all property sheets.
  9. Exit the Internet Services Manager.

Configuring Certificate Services

This section briefly describes the process of setting up a certificate server.

  1. On a domain controller or auxiliary server, ensure that IIS is installed.
  2. On a domain controller or auxiliary server, on the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and select Configure Your Server.
  3. At the bottom of the menu list in the left frame, click Advanced.
  4. Under the Advanced menu heading, select Optional Components.
  5. In the details pane, click Start to start the Windows Components Wizard.
  6. Select Certificate Services from the list of available components, and then click Next.
  7. Click Next to leave the Terminal Services Configuration page.
  8. Select Root CA and then click Next.
  9. Enter information about the organization and its contact information.
  10. If a dialog box appears saying that the IIS service needs to be restarted, click OK.
  11. Proceed to complete the installation of the certificate server.

Configuring a Web Site to Use SSL

This section briefly describes the steps to configure a Web site to use Secure Sockets Layer (SSL).

  1. Ensure that the Web server is installed in a domain with Certificate Services running.
  2. On the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then open the Internet Services Manager.
  3. Expand the items under the name of the server that represents the local server.
  4. Select the Web site that BizTalk messaging ports will use.
  5. Right-click the Web site and click Properties.
  6. On the Directory Security tab, select Server Certificate.
  7. Select Create New Certificate and then click Next.
  8. Select Send the Request Immediately and then click Next.
  9. Name the certificate, select the maximum bit length, and then click Next.
  10. Enter organizational information and click Next.
  11. Enter the name that corresponds to the Internet name for the Web site. This name should relate to a DNS entry such as Customer.com. Click Next.
  12. Enter geographic information and click Next.
  13. Click Next to complete the Submission Wizard. This will submit the certificate request to the certificate authority.
  14. Click Finish to complete the wizard.
  15. On the Directory Security tab, under Secure Communications, click Edit.
  16. Select Accept Client Certificates.
  17. Optionally select Require SSL and 128 Bit Encryption.
  18. Click OK to close all property sheets.
  19. Optionally, individual certificates can be issued to each organization. These can then be mapped to users by using the Edit Secure Communications tab.

Configuring ISA for Tunneling

  • Add a new protocol rule to the external ISA server to allow the PPTP and/or L2TP tunneling protocols from any external IP address to the IP address of the RRAS server.
  • Alternatively, add a new protocol rule to the external ISA server to allow PPTP and L2TP tunneling protocols from any external IP address to the public IP address of the RRAS server. (This server will be set up in the next section, "Setting Up a Routing and Remote Access Server for VPN".)

Setting up a routing and remote access server for VPN

  1. Ensure that any entities using Virtual Private Networks (VPN) are mapped to a user name and that the user properties sheets allow VPN/dialup.
  2. Set up Windows 2000 Advanced Server with the default options with two network interface cards (NICs).
  3. Place the computer in the perimeter network (also known as the DMZ).
  4. Configure the server to have two network cards.
  5. Plug one network card into the hub or switch connecting to the firewall interface going out to the Internet.
  6. In Network Control Panel, change the name of this NIC to "Internet."
  7. Plug one network card into the hub or switch connecting to the firewall interface that leads to the DMZ network.
  8. In Network Control Panel, change the name of this NIC to "Internal."
  9. On the Start menu, point to Programs, point to Administrative Tools, and then select Routing and Remote Access (RRAS).
  10. In the RRAS console, right-click the local server name and choose Configure and Enable Routing and Remote Access.
  11. Choose to configure this server as a Virtual Private Network Server.
  12. Click Yes, all available Protocols are available. (Only TCP is needed.)
  13. Indicate the NIC that connects to the Internet. This should be called "Internet" as specified in step 6 above.
  14. Indicate the NIC that connects to the private network. This should be called "Internal."
  15. Choose to assign IP address by DHCP if a DHCP server is available or if desired, specify a range of IP addresses to assign to clients.
  16. Choose not to use a RADIUS server.
  17. Click Finish to exit the wizard.
  18. Click OK if prompted to configure the DHCP Relay Agent.
  19. In the RRAS console, go to IP Routing, right-click DHCP Relay Agent, and choose properties.
  20. Add the IP addresses of any DHCP servers needed.
  21. Click OK to finish.
  22. If desired, issue a certificate from the local certificate authority root to the user. Create packet filters to allow ports for L2TP and IPSec from any external IP to the Public NIC of the RRAS server. Layer 2 Tunneling Protocol is supported by RRAS by default. See the Windows 2000 documentation for more information about implementing L2TP with RRAS.

Configuring Auditing Policies

This section briefly describes the steps to configuring Windows auditing policies.

  1. On a domain controller in the domain where the Accelerator for HIPAA solution resides, on the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Domain Security Policy Administration. The Domain Security Policy Administration console appears.
  2. Under Windows Settings, expand the Security Settings properties.
  3. Under Local Policies, double-click Audit Policy.
  4. Select Define this Policy Setting. Under Select These Attempts, select Audit Success and Audit Failure.
  5. Repeat these steps for the following policies that are shown in the details pane:
    • Account Logon Events
    • Account Management
    • Directory Service Access
    • Logon Events
    • Object Access
    • Policy Change
  6. Select Settings for Event Log under Event Logs in the Domain Security Policy Administration console.
  7. In the details pane, double-click Retention Method for Security Log.
  8. If using Microsoft Operations Manager to consolidate events, select Overwrite Events as Needed. Because data will be consolidated with MOM, there is no need to hold the information locally.
  9. If using MOM, it might be advisable to repeat this for the system and application logs.
  10. Exit the Domain Security Policy Administration console.

Deploying Microsoft Operations Manager

Microsoft Operations Manager (MOM) can require an enterprise-class database. A best practice is to deploy MOM using a clustered implementation to enhance the availability of critical auditing data. MOM offers management packs that are ready-made rules for monitoring and consolidating events related to individual applications. It is recommended to use these where applicable. The following steps provide a summary of how to deploy MOM to consolidated security events. Microsoft Consulting Services can provide assistance with deploying MOM.

General recommendations

  • Create a new database on the existing SQL Server™ database cluster or deploy a separate cluster server to house the MOM event consolidation database.
  • Consult the Microsoft Operations Manager Web site for more information about deploying MOM.
  • It is recommended to place MOM agents on each computer in the architecture.
  • A custom monitoring resource will need to be set up to manage and consolidate security events.
  • It is recommended to place the database in a secure zone.
  • Consolidation and reporting servers should be located in secure zones.
  • The instructions here are specifically designed for configuring a MOM consolidation server and all of its centralized services inside a firewall that only allows specific ports through. MOM has specific ports that it communicates on by default, but these can be changed. The following information assumes that the MOM server in the secure zone will be separated from the client servers in the perimeter network by a firewall. The firewall is assumed to allow communication between the client server and the MOM consolidation server over the necessary ports. MOM can be deployed to take automatic actions/trigger events on client machines that are within the firewall. Because this level of interaction requires RPC communication, it cannot be achieved over a firewall unless RPC port ranges are open between client and server.

Installing MOM and preparing a new configuration group

  1. As a best practice, install redundant MOM servers that use the same database components.
  2. Install MOM by using the custom configuration option.
  3. Installation notes:
    • Only one reporting server is needed per configuration group. This can also be done on a separate workstation if desired.
    • Choose to install to a remote database and point to the MOM database for the enterprise.
    • MOM should be installed as an agent manager and data consolidator.
  4. Configure the MOM server.
    • Add a new computer group to the Rules, Computer Groups section called "BTA4H"
    • Add a rule for the client server to be included in the computer groups.
    • Add a rule to the computer group.
  5. Configure the MOM server.
    • Commit changes by right-clicking Rules and selecting Commit Configuration Change.
    • Initiate managed computer scan for the relevant agent manager.

Manual MOM agent install on client machines

  1. Run the setup program from the Manual Agent Install Directory on the MOM CD.
  2. Choose to Install a new Configuration.
  3. Choose the appropriate configuration site.
  4. Add the Configuration Site Name.
  5. Add the Consolidator Name.
  6. Add redundant consolidator names.
  7. Open Advanced Options.
  8. Select the appropriate ports for MOM communications. (Be sure that the configuration group of which the server is a member uses the same communication port rules as those selected.)
  9. Select the bottom (None) configuration option install. This is the installation for clients outside of a firewall (minimum) and does not support Managed Agents.

Preparing the network for a new managed computer

  1. Complete Manual Agent Install on client servers. (See the preceding section.)
  2. Configure a DNS entry for the client servers if they are located in another zone.
    • Create a host record with the same Hostname as the Managed Node with no DNS suffix.
    • Create a host record with the same IP address as the client server.
    • Create a host record in the same domain as the MOM server.
  3. Configure the Consolidator and Redundant Consolidators to see the newly installed agent.
    • Add the remote server names to a text file named ManualMC.txt. The names must consist of only the host name without domain suffixes. There must be no white space at the beginning of the list and no white space before or after a host name. There must be a carriage return after the last host name.
    • Place the text file on the MOM server in the directory: Program Files/Operations Manager/One Point.
    • Add a rule specifically including the computer to the properties sheet of the "BTA4H" computer group (see Installing MOM and Preparing A New Configuration Group).
    • Add a rule specifically including the computer to the Managed Computer List of the Agent Managers off the appropriate MOM Consolidator and redundant Consolidator computers. The rule should have "wildcard" as the selection criterion and * for the domain name. The rule should also specifically indicate the host name of the computer in the computername selection area.
    • Right-click the configuration node in the MOM Admin console and select Commit Changes Now.
    • Initiate a Managed Computer Scan.

Create a processing rule to consume event logs

  1. If this MOM implementation is to be used only for Security Auditing and Reporting, it is recommended that all Rule Processing Groups be removed from within the MOM Management Console under the Rules, Processing Rules Groups folder.
  2. Right-click the Processing Rules Group folder, Select New, and then click Processing Rule Group.
  3. Under the New Event Processing Rule Group, right-click Event Processing Rules, click New, and then click Event Processing Rule.
  4. In the dialog box, select Collect Specific Events and click Next.
  5. Under Provider Name, select Security, and click Next.
  6. Select the Of Type check box and select Error from the drop-down list. Click Next.
  7. Click Store All Event Parameters and then click Next.
  8. Select Always Process Data and then click Next.
  9. Enter any custom information that you would like to be added to the knowledge base when this event is fired. Click Next
  10. Enter a name for the processing rule and click Finish.
  11. Repeat to create other Event Processing Rules in which the "of type" selection indicates these events: Warning, Information, Failure Audit, and Success Audit.
  12. In the MOM Management Console, under the Computer Groups folder, right-click the BTA4H Computer Group and select Properties.
  13. On the Processing Rules tab, click Add.
  14. Select the Processing Rules Group in which the processing rules created earlier were placed.
  15. Click OK to exit. Click Apply.

Create a notification (alarm) that corresponds to a security event

  1. In the MOM Management Console, under a new or previously created Rule Group, right-click Alert Processing Rules, click New, and click Alert Processing Rule.
  2. On the first page of the wizard, select Only Match Alerts Generated By Rules in the Following Group and click Browse.
  3. Browse to and select the processing rule group created in the preceding section.
  4. Click OK to exit and then click Next to proceed to the next page of the wizard.
  5. Select Always Process Data and click Next.
  6. Click Add and select Send a notification to a Notification Group.
  7. On the Notification tab, click New.
  8. Create a name for the notification group.
  9. Select New Operator to create a New Enabled Operator. Define the e-mail address and notification times. Define the pager address and times. Define any custom notification commands and times. Click Finish to exit the New Operator Wizard.
  10. After you have exited the New Operator Wizard, you will be back to the Notification Group Properties dialog box. Select the Newly Created Operator from the right pane called Available Operators. Select any desired Operators and use the arrow buttons to move them to the left pane called Group Operators.
  11. Click Finish to complete the Notification Group Properties dialog box.
  12. You will be returned to the Notification tab. Be sure that the newly created Notification Group is selected in the drop-down list.
  13. To customize e-mail, pager, and command formats, select the corresponding tab. It is possible to add additional variables to notifications to increase the amount of information that the operator receives.
  14. Click OK to exit the notification properties sheet. Click Next to proceed to the next page of the wizard.
  15. If needed, add any additional information to identify the notifications for addition to the company knowledge base. Click Next.
  16. Name the Response Rule. Be sure that the Enabled check box is selected. Click Finish.

Configuring Auditing in SQL Server 2000

  1. Determine which tables or views relate to each type of user that you will support. Only the minimum necessary information should be accessed.

  2. Group the users with similar access requirements into roles. Create Active Directory groups that relate to these roles. Give each of the users an Active Directory user account. Place each user in the group that relates to that user's role.

  3. In SQL Server Enterprise Manager, locate the database that the groups/roles will access.

  4. Double-click the database to expand the nodes beneath it.

  5. Right-click Users and click New Database User.

  6. In the Login Name drop-down list, select <NEW>.

  7. Beside Domain, select the domain in which the groups were created.

    Note   If the groups and users are in another domain, forest, or Kerberos realm, implement trusts to be able to browse for them as desired and give permissions as desired. See the Windows documentation for more information about implementing trusts.

  8. Click the ellipsis beside Name and browse for one of the groups. Select the group and click OK.

  9. Select the default database for the user.

  10. On the Database Access tab, specify the databases that the users/role can access and the role of users/role in the each database.

  11. Click OK to exit to the database Users Dialog Box.

  12. Select All from the Audit Level Section.

  13. Select the newly created login from the Login Name drop-down list.

  14. Specify the role for this login.

  15. Click OK to exit.

  16. In the nodes under the database, select Tables.

  17. In the details pane, right-click any table with sensitive data and select Properties.

  18. On the General tab, click Permissions.

  19. Select the role/group and edit permissions. To edit Permission on Fields, select the role/group and click Columns.

  20. Repeat this process for each table and group.

  21. Alternatively, you can group map roles/groups to stored procedures that access information.

  22. Alternatively, you can use COM+ and map permissions to roles.

  23. Alternatively, you can enforce roles programmatically from within the business rules of the application.

Configuring BizTalk Messaging Ports

BizTalk messaging ports can be configured to use enhanced security services. This section briefly describes the setup of these capabilities.

  1. First, deploy a certificate to the BizTalk Messaging Store by clicking Run on the Start menu.
  2. Next type MMC. A blank management console appears.
  3. On the Console menu, click Add Remove Snap-in. Select This Computer will Always Manage Certificates for Computer Account.
  4. Select Manage the Certificate for the Local Computer, and then click Finish. Click Close. Then click OK to return to the MMC.
  5. Expand the nodes under Certificates. Search for certificates in the Personal Store and Trusted Root folders that are issued by the Relevant Root Certificate Authority. If none exists, use IIS to request one from the Certificate Authority or go to the default Web site on the Certificate Server for your enterprise and request and download one.
  6. Copy the relevant certificate(s) and paste them in the BizTalk Server folder.
  7. Exit the Management Console.
  8. Now when configuring a messaging port, it is possible to simply select S/MIME for Encryption and Signature. It is also possible to implement HTTPS (addressed earlier when enabling a Web site for SSL).

Ensuring Security

Microsoft Consulting Services has resources to assist in addressing enterprise and solution-specific security concerns. In addition, you can obtain configuration best practices and checklists to ensure that your system has all of the latest security fixes from Microsoft. To find out more, the Microsoft.com Security Web site or contact Microsoft Consulting Services.