Pro BizTalk 2006 phần 8 docx

If not done already, configure the Backup BizTalk Server SQL Agent job following theinstructions in the earlier subsection titled “Configuring the Backup BizTalk Server SQL AgentJob.” Th

• Rule Engine (BizTalkRuleEngineDb)

• BAM Primary Import (BAMPrimaryImport)

• Trading Partner Management (TPM)

• HWS Administration (BizTalkHWSDb)

• BizTalk EDI (BizTalkEDIdb)

These databases must be backed up by the Backup BizTalk Server SQL Agent job and

cannot be backed up using the normal SQL Server backup procedures The reason is because

BizTalk uses SQL Server log marks to keep the set of databases consistent as part of DTC

trans-actions The Backup BizTalk Server job creates a log mark and then backs up the database log

for each database that is part of the Backup BizTalk Server SQL Agent job This log mark is used

when restoring the last log file for each database so that transactional consistency is

main-tained Here are the steps to configure the Backup BizTalk Server SQL Agent job:

1. In SQL Server 2000 Enterprise Manager or SQL Server 2005 Management Studio, gate to the SQL Agent jobs list

navi-2. Right-click Backup BizTalk Server (BizTalkMqmtDb) and select Properties

3. In the Job Properties dialog under Select a page, click Steps to view the job steps

4. In the Job step list, click BackupFull, and then click Edit

5. On the General page, in the Command box, replace ‘<destination path>’ with the fullpath (the path must include the single quotes) to the computer and folder where youwant to back up the BizTalk Server databases Also add a new parameter by typing acomma and then a number one (“,1”) at the end of the parameter list for the storedprocedure sp_BackupAllFull Adding this parameter enables an automatic full backupafter a backup failure Click OK when finished

■ Note The default frequency for the BackupFull job is d for daily Other values are hourly (h/H), weekly

(w/W), monthly (m/M), or yearly (y/Y) The first time the job is run during a new period, a full backup is

per-formed Also, the default name is BTS, which will be part of the backup file name Change this to reflect a

better name for the application such as OrdSys for an application named Order System

6. In the Job step list, click MarkAndBackupLog, and then click Edit

7. On the General page, in the Command box, replace ‘<destination path>’ with the fullpath (including single quotes) to the computer and folder where you want to store theBizTalk Server database logs and then click OK The <destination path> may be local or

a UNC path to another server

■ Note We recommend a UNC share to store the backup files on a different file system than where thedatabases reside for production environments For a dev or test environment, if you are not concerned withmaintaining offsite backup sets or multiple backup sets, you can consider using a local path instead of aUNC path.

Also, for the job step MarkAndBackupLog, Log Mark Name is part of the naming tion for backup files:

conven-<Server Name>_<Database Name>_Log_< Log Mark Name >_<Timestamp>

Replace "BTS' with a more appropriate name for the solution

8. In the Job step list, click Clear Backup History, and then click Edit

9. On the General page, in the Command box, change DaysToKeep=<number> to thenumber of days (default is 14) you want to keep the backup history, and then click OKtwice to close the Job Properties dialog box

■ Note The DaysToKeep setting is not related to how many sets of backup files are maintained Backup filesets must be handled manually by copying to another system for long-term archival

Change the backup schedule for MarkAndBackupLogSched if desired and then right-clickthe Backup BizTalk Server SQL Agent job and select Enable The default schedule is to perform

a log backup every 15 minutes

Once the Backup BizTalk Server job is configured and enabled, right-click and select StartJob to test Click F5 to refresh the status on the Jobs node If the result is not successful, checkthe following:

• Verify that the destination folder exists and is reachable if a UNC share

• Check that the job owner has permissions on the destination folder

• Ensure that linked servers are configured properly if BizTalk databases are present inmultiple SQL Server database instances

■ Tip For SQL Server 2005, there are additional security settings for linked servers When configuringlinked servers in SQL Server 2005 as part of the Backup BizTalk Server SQL Agent job, click the Security taband select the “Be made using the login’s current security context” option Next click Server Options, setRPC Out to True, and then click OK

Be aware that the file name includes the date/time from when the backup file was ated This date/time is GMT time, not local time If you look at the Date Modified field in

cre-Windows Explorer, you will see the local time

Also, the Backup BizTalk Server SQL Agent job does not manage disk space, meaning itwill continue to copy files into the same directory until the drive runs out of space This allows

the administrator to decide how many backup sets to keep on disk as well as how many to

archive to an offsite location, deleting the files from disk after archival

The next subsection covers how to configure the DTA Purge and Archive SQL Agent job

Configuring the DTA Purge and Archive SQL Agent Job

With companies having to comply with IRS, general accounting, and legislative requirements

for business reporting, BizTalk Server provides extensive tracking capabilities to help with

complying with these mandates This data must be kept for various periods of time to meet

reporting requirements BizTalk Server 2006 adds the DTA Purge and Archive job to help

auto-mate the backup of tracking data including the ability to perform on-the-fly validation of

tracking data backups using another instance of SQL Server to ensure that a complete record

of activity is maintained and available

In addition to providing data archival, the DTA Purge and Archive SQL Agent job forms data pruning to help keep the system running smoothly As with any database system,

per-unchecked growth in table size will eventually push the limits of the hardware In general,

there are two solutions to this problem, buy more disks or a faster disk or have a purge and

archival policy to “prune” the databases where it makes sense While all database-based

sys-tems benefit from more and faster disks, BizTalk has a process to keep the BizTalk Tracking

and Messagebox databases performing optimally by automating purging and archival tasks

through the DTA Purge and Archive SQL Agent job

The DTA Purge and Archive job purges various tracking information such as serviceinstance and message information, orchestration event information, and rule engine tracking

data The purge process is based on the age of the tracking data, which is maintained by

hav-ing a time stamp added when trackhav-ing information is inserted into the database The DTA

Purge and Archive job has a soft purge and hard purge process The soft purge processes

completed instances, while the hard purge processes incomplete instances Note that both

soft purge and hard purge process just the tracking data, not the actual running instances, so

they have no effect on actual data processing data The purge process helps to optimize

track-ing processes and HAT operations when looktrack-ing at historical data Here are the steps to

con-figure the DTA Purge and Archive SQL Agent job:

1. Depending on whether you are on SQL Server 2000 or SQL Server 2005, navigate to theManagement node and view the SQL Agent jobs

2. In the details pane, right-click DTA Purge and Archive (BizTalkDTADb), and then clickProperties

3. In the Job Properties dialog box, click the Steps tab, click Archive and Purge, and thenclick Edit

4. On the General tab, in the Command box, edit the following parameters as ate, and then click OK

appropri-■ Note For the soft purge, the sum of LiveHours and LiveDays is the live window of data that will be tained for the BizTalk Tracking database All tracking data associated with completed instances older thanthe live window will be deleted and archived.

main-• @nLiveHours tinyint: Default is 0 hours

• @nLiveDays tinyint: Default is 1 day

• @nHardDeleteDays tinyint: Default is 30 days

• @nvcFolder nvarchar(1024): Specify the folder or UNC share to put the tracking databackup files

• @nvcValidatingServer: SQL Server instance where validation is performed Default isnull

• @fForceBackup int: Default is 0 This is not currently implemented

Here is an example command that specifies that soft purge occurs every 12 hours andhard purge occurs every 7 days:

exec dtasp_BackupAndPurgeTrackingDatabase 12, 0, 7, '\\BizTalkBackupServer\data',null, 0

In the preceding example, we left the validation server value as null; however, we mend that you set up a validation server for the tracking data to ensure that the backup files

recom-of the tracking data for reporting and compliance purposes are valid Also, the data can bequeried on the validation server, offloading potentially long-running queries from the produc-tion BizTalk databases To configure a validation server for the DTA Purge and Archive SQLAgent job, you must have a separate instance of SQL Server available Having a validationserver requires that the @nvcFolder variable in the DTA Purge and Archive job points to a UNCshare reachable by the validation server The SQL Server instance where the BizTalk databasesare configured cannot also act as the validating server On the server designated as the valida-tion server, perform these steps:

1. In either ISQL on SQL Server 2000 or in SQL Management Studio on SQL Server 2005,open a file to execute a SQL file Connect to the SQL instance that is the validationserver

2. Select File ➤Open and then browse to this SQL script on the server/drive whereBizTalk Server 2006 is installed: \Program Files\Microsoft BizTalk Server 2006\

Schema\BTS_Tracking_ValidateArchive.sql

3. Execute the query to create a SQL Agent job called ValidateArchive on the validatingserver

4. Open either Enterprise Manager for SQL Server 2000 or SQL Management Studio forSQL Server 2005 to set up the required linked servers Linked servers must be createdbetween the following:

• Each of the BizTalk Messagebox (BizTalkMsgBoxDB) SQL Server instances and theBizTalk Tracking (BizTalkDTADb) SQL Server instances The SQL instance hostingthe DTA database requires a linked server to each SQL instance hosting a BizTalkMessagebox and vice versa

• The BizTalk Tracking (BizTalkDTADb) SQL Server instance and the validatingserver SQL Server instance Create a linked server on each SQL instance to theother SQL instance so that the SQL instance hosting the DTA database has a linkedserver to the validating server and vice versa

Next, we turn our attention to monitoring best practices for the SQL Agent jobs

Monitoring the BizTalk Group SQL Agent Jobs

Because the SQL Agent jobs are critical to maintaining BizTalk performance, the jobs must be

monitored so that operations personnel can be alerted if a job fails The Microsoft SQL Server

Management Pack contains MOM rules for monitoring SQL databases, SQL Server Agent jobs,

etc., for comprehensive monitoring of SQL Server items The BizTalk Server 2006 Management

Pack for Microsoft Operations Manager 2005 includes two rules, disabled by default, for

moni-toring the health of two of the most important BizTalk SQL Server Agent jobs The rule names

as defined in the Management Pack are

• Critical Error: A BizTalk SQL Server Agent job failed—Backup BizTalk Server

• Critical Error: A BizTalk SQL Server Agent job failed—Tracked Message Copy

To monitor all BizTalk Server SQL Server Agent jobs from within the BizTalk Server 2006Management Pack, enable these rules and create additional rules for other jobs that you want

to monitor To enable these rules, perform the following steps in the MOM Administrator

Parame-You need to add the SQL Server computers into the BizTalk Server 2006 Computer Group

in MOM This is because the MOM rule needs to be evaluated on the SQL Server computer,

and the SQL Server computer will not be recognized as a BizTalk Server computer unless

BizTalk and SQL Server happen to be installed on the same machine

Backup Procedures

This subsection covers the backup procedures for BizTalk applications; however, a BizTalk

application is usually just one part of an overall solution that includes other applications,

servers, and databases In general, backup of an application solution that includes BizTalkrequires the following general procedures:

• Back up application code, artifacts, documentation

• Back up server configuration documentation

• Back up BizTalk servers and BizTalk Group databases

• Back up related non-BizTalk databases

Steps and procedures for backing up the first two items listed are outside the scope of thischapter; however in general, application code, artifacts, code documentation, and server con-figuration documentation should be kept in a source code control system that is backed upautomatically with rotating backup sets maintained at an offsite location

The following subsections focus on the last two items listed including backup proceduresfor BizTalk runtime servers and for the BizTalk Group

BizTalk Servers

The servers where BizTalk is installed and configured should be backed up using your rate standards for server backup In addition, the config.xml file used to configure each servershould be backed up along with documentation on what host instances, receive ports, andsend ports are installed on the server This information can be stored in your source code con-trol system as solution artifacts Essentially the procedures used to perform the followingsteps must be in a format that administrators can use to perform a restore or disaster recoveryevent:

corpo-• BizTalk installation: Document what features/service pack/hotfixes are installed on

the BizTalk runtime server Document what other products such as SharePoint, IIS, orthird-party adapters are installed

• BizTalk configuration: Back up the config.xml that was used to configure the server.

This file can be reused to configure the server with minor edits depending on whetherthe BizTalk Windows server name changed or the SQL instance location of the data-bases has changed

• Master secret: This is an extremely important backup item that is covered later in this

chapter Without the master secret, a BizTalk Group cannot be restored The mastersecret is encrypted and stored in the registry of the master secret server It is required

in order to access the credential (SSOdb) database

• BizTalk application configuration: Document host instances, receive ports, send ports,

and of course versions of BizTalk application binaries

Maintaining the preceding documentation is the minimum requirement necessary torestore the BizTalk runtime servers It is recommended to automate installation, configura-tion, and application deployment as much as possible to support normal operations as well

as to provide an automated method to restore the BizTalk runtime servers

The next subsection covers procedures for backing up the master secret

The Master Secret

BizTalk Server 2006 includes a new Microsoft Management Console (MMC) snap-in for

man-aging Enterprise SSO and the master secret, as shown in Figure 9-2 To launch the SSO

Admin-istration tool, go to Start ➤All Programs ➤Microsoft Enterprise Single Sign-On ➤SSO

Administration To back up the master secret, right-click the System node and select Backup

Secret within the GUI

Clicking Backup Secret displays the dialog box shown in Figure 9-3, where you enter alocation for the backup file, a password, and optionally a password reminder This file should

be removed from the server and stored in a safe place such as a source control system locally

as well as at an offsite location

Figure 9-2.SSO Administration MMC console

Figure 9-3.Backup Secret dialog

The Enterprise SSO tools SSOManage.exe and SSOConfig.exe are still available in theC:\Program Files\Common Files\Enterprise Single Sign-On directory to support scripting,

so the master secret can be backed up using the command-line tool SSOConfig.exe with the–backupSecret switch as well

Next, we cover procedures for backing up the BizTalk Group

BizTalk Group

This subsection covers backup procedures for the BizTalk Group, which consists of a set ofdatabases created by BizTalk Server 2006 during configuration All of the normal requirementswhen performing SQL backups apply: allocating sufficient storage space where backup filesare stored, copying backup files to an offsite location, testing restore files on a regular basissuch as monthly, etc Another consideration is to ensure backup devices and media are secure

to protect business-sensitive data

■ Note BizTalk Server includes a SQL Server role named BTS_BACKUP_USERS so that BizTalk databasescan be backed up without requiring System Administrator permissions within SQL Server, except for theprimary server controlling the backup process

If not done already, configure the Backup BizTalk Server SQL Agent job following theinstructions in the earlier subsection titled “Configuring the Backup BizTalk Server SQL AgentJob.” The Backup BizTalk Server SQL Agent job backs up the following databases:

• BizTalk Configuration (BizTalkMgmtDb)

• BizTalk Messagebox (BizTalkMsgBoxDb)

• BizTalk Tracking (BizTalkDTADb)

• Rule Engine (BizTalkRuleEngineDb)

• BAM Primary Import (BAMPrimaryImport)

• Trading Partner Management (TPM)

• HWS Administration (BizTalkHWSDb)

• BizTalk EDI (BizTalkEDIdb)

• Credential Database (SSOdb)You must also back up the following BizTalk Group databases, which are not part of theBackup BizTalk Server SQL Agent job because they do not participate in DTC transactions:

• BAM Archive (BAMArchive)

• BAM Star Schema (BAMStarSchema)

These databases can be backed up using normal SQL Server backup procedures becausethey do not participate in distributed transactions; however, these databases require special

consideration, described in the next subsection, if BAM is configured with BM.exe and used as

part of a BizTalk solution

BizTalk Server 2006 includes a table named adm_OtherBackupDatabases in the BizTalkManagement database (BizTalkMgmtDb) Other application databases that participate in DTCtransactions (i.e., accessed within an atomic scope in an orchestration) should be added to

adm_OtherBackupDatabases to remain transactionally consistent with the BizTalk databases

Table 9-2 lists the column names

Table 9-2.Columns in the adm_OtherBackupDatabases Table

Field Name Value

DefaultDatabaseName The alias for the database Can be the same as the database name or

the application name

DatabaseName The actual name of the database

ServerName The name of the SQL Server instance hosting the database

BTSServerName Name of a BizTalk server Not used, but required

Databases added to the adm_OtherBackupDatabases table will automatically be backed

up by the Backup BizTalk Server SQL Agent job

■ Caution You must add any non-BizTalk custom database that performs distributed transactions with

BizTalk to this table so that the table can be restored to the same log mark and remain transactionally

con-sistent For example, if you have an orchestration that updates a database named App1 within an atomic

scope in BizTalk, the database App1 must be added to the adm_OtherBackupDatabases table

The next step is to add the necessary schema changes to the databases added to theadm_OtherBackupDatabases table Otherwise, the Backup BizTalk Server SQL Agent job will

fail Browse to the <installation directory>\Program Files\Microsoft BizTalk Server 2006\

Schema directory, and then run Backup_Setup_All_Procs.sql and Backup_Setup_All_

Tables.sql in the destination database This creates the necessary procedures, tables, and roles

to participate in the Backup BizTalk Server SQL Agent job and assigns permissions to the

stored procedures

Now let’s take a look at backup procedures for the SQL Server Analysis Services databases

BAM Analysis Services and Supporting Databases

BizTalk leverages SQL Server Analysis Services for reporting and analysis functionality as part

of the Health and Activity Tracking and Business Activity Monitoring features In BizTalk

Server 2006, the Tracking Analysis Server OLAP database is available in BizTalk installations as

part of HAT to support the service metrics and message metrics functionality for SQL Server

2000 Analysis Services only The Tracking Analysis Server database is not supported on SQLServer 2005 Analysis Services and is not available as an option when configuring the BizTalkGroup with a SQL Server 2005 database back end.

A BizTalk Group configured with BAM enabled in the BizTalk Configuration Wizard results

in two additional SQL Analysis Services OLAP databases if the Tracking Analysis Server base is present:

data-• BAM Analysis (BAMAnalysis)

• Tracking Analysis Server (BizTalkAnalysisdb)These Analysis Services databases must be backed up following the procedures for back-ing up SQL Analysis Services databases

There are two scenarios for backing up BAM SQL Server databases when BAM is enabledthrough the BizTalk Configuration Wizard:

• BAM enabled for the BizTalk Group but not configured

• BAM enabled and configured with BM.exe (i.e., the BizTalk solution includes BAMfeatures)

The next two subsections cover these scenarios

BAM Enabled but Not Configured in a BizTalk Group

Since BAM is not configured with BM.exe, there are not any BAM-related Data TransformationServices (DTS) packages present in the solution Therefore, the BAM SQL databases can bebacked up using regular SQL Server backup procedures or can be added to the Backup BizTalkServer SQL Agent job by adding the table to the adm_OtherBackupDatabases table for con-venience Here is a list of the BAM SQL databases that must be backed up:

• BAM Archive (BAMArchive)

• BAM Star Schema (BAMStarSchema)This will ensure that a full set of databases for the BizTalk Group are maintained The nextsubsection covers backup procedures when BAM is enabled and configured with BM.exe

BAM Enabled and Configured in a BizTalk Group

When BAM is enabled and configured for a BizTalk Group using BM.exe, it results in the ation of one or more DTS packages that must be backed up in case they are accidentallydeleted as well as duplicated on the disaster recovery site (Disaster recovery is covered in itsown section later in this chapter.) Backup procedures for DTS packages are documented inSQL Server Books Online

cre-Before backing up the BAM databases, ensure that neither the BAM cube process nordata maintenance DTS packages are running when the backup package is scheduled to run.Ensure consistent schema across all BAM databases by backing up the BAM databases andDTS packages each time a BAM activity is deployed and not deployed

The BAM Analysis and BAM Star Schema databases should be backed up each time

a BAM view is deployed and undeployed Follow these procedures when backing up BAM

databases:

1. Run the Backup BizTalk Server job to back up the BAM Primary Import database aswell as the other BizTalk Server databases

2. Run the BAM data maintenance DTS package for all activities

■ Tip Incorporate these steps into a DTS package, scheduling it to run on a regular basis To guarantee

data integrity, ensure no other BAM cubing or DTS packages run when this DTS package is scheduled

Back up the BAM Archive database after the partition is copied into the BAM Archivedatabase but before the partition is deleted from the BAM Primary Import database so that a

complete set of archived data is maintained This can be achieved by modifying the data

maintenance DTS package for each activity to add a step to back up the BAM Archive databasebefore the last step in the DTS package called End Archiving

3. Back up the BAM Archive database, and then the BAM Star Schema database

Next, we cover backup procedures for Business Activity Services

BAS Site and Databases

Business Activity Services is an optional installation option and may not be part of a solution

If BAS is part of a solution, it requires special backup procedures because the BAS

environ-ment consists of the following:

• A web site hosted in Microsoft Windows SharePoint Services and InfoPath templates

Windows SharePoint Services and InfoPath provide a common user interface for all ofthe services included in BAS

• A Trading Partner Management database This database stores trading partner data forBAS It is not a runtime database

• Two Windows SharePoint Services databases: the Configuration and Content databases

These databases store the global settings for the WSS server as well as site content form the following steps to back up the BAS site and database:

Per-1. After BAS is configured, back up all of the changes made to the web applicationconfiguration files and Windows SharePoint Services site templates so these can

be recovered later There may be modifications in other places, for example, inclient-side JavaScript files if the site has been customized by the developmentteam These changes must be documented and backed up to a source code controlsystem as well

2. Ensure the Backup BizTalk Server SQL Agent job is configured since it backs up theTrading Partner Management database.

3. Follow the instructions in the “Windows SharePoint Services Administrator’sGuide” to back up the Windows SharePoint Services Configuration and Contentdatabases This guide is available for download here: www.microsoft.com/

3e33fa13d230&displaylang=en

downloads/details.aspx?amp;displaylang=en&familyid=a637eff6-8224-4b19-a6a4-The next subsection covers steps to back up the Base EDI adapter

Base EDI Adapter

Additional backup steps are required in order to completely restore the EDI adapter The firststep is to back up the DocumentsHome directory This directory is located here by default:

<root>\Documents and Settings\All Users\Application Data\Microsoft\BizTalk Server 2006\EDI\Subsystem

■ Note Path references to BizTalk Server 2006 may actually be in the BizTalk Server 2004 directory if anin-place upgrade was performed when BizTalk Server 2006 was installed

In this directory are subdirectories and folders containing EDI adapter settings, sent andreceived documents in EDI and XML format, log files, in-flight files, and the compiled engineinput file (EIF)

The entire DocumentsHome directory should be backed up frequently using a file-basedhigh-capacity backup system Ideally, the DocumentsHome directory is mirrored using arobust high-capacity storage technology This also allows fast restore time because the systemautomatically switches to the mirrored disk when necessary If disk mirroring is not an option,the DocumentsHome directory should be backed up very frequently to minimize data loss.Depending on legal requirements with partners, incoming EDI documents can be con-figured to be received at an alternate receive location that makes a copy of the incomingdocument before sending the document to the EDI receive location This provides an addi-tional layer of archive for inbound documents Another option is to enable message bodytracking on inbound EDI documents Legal implications may surround message body track-ing depending on the legal agreements with trading partners Be sure to review all legalagreements before enabling message body tracking Also, message body tracking greatlyincreases database growth, which must be taken into account because of potential perform-ance impact

Now let’s look at backup procedures for DTS packages related to the BizTalk solution

DTS Packages

All DTS packages that are part of the solution must be duplicated at the disaster recovery site.The BizTalk Configuration Wizard does not create any DTS packages However, if BusinessActivity Monitoring is part of the solution and is configured with the BAM monitoring tool

(BM.exe), there will be DTS packages created that generate/update the OLAP cubes The DTS

packages have names like the following:

• BAM_AN_<ViewName>

• BAM_DM_<activity name>

■ Note There are no DTS packages that require backing up if BAM is not configured using the BM.exe tool

To back up the DTS packages with SQL Server 2000, follow these steps:

1. Navigate to the Data Transformation Services folder in SQL Server 2000

2. Click Local Packages to see a list of DTS packages for the server

3. In the right pane, right-click each package and select Design Package

4. In the menu, click Package and then Save As

5. Click the drop-down for Location and select Structure Storage File

6. Click the button with the caption … and enter a path/file name

7. Click OK to generate the DTS file for the package

8. Connect to the destination disaster recovery server using Enterprise Manager

9. Expand the target server/instance

10. Right-click the Data Transformation Services folder and select Open Package

11. Browse to the package exported in the preceding steps and import the package to thetarget server

12. Perform the preceding steps for all DTS packages that are part of the solution

To back up SSIS packages with SQL Server 2005, follow these steps:

1. Open SQL Server Management Studio and connect to Integration Services

2. Expand the Stored Packages folder in Object Explorer

3. Expand the subfolders to locate the package that needs to be exported

4. Right-click the package, click Export, select File System, and then browse to a location

to save the package

To back up SQL Server Integration Services packages with SQL Server 2005, follow thesesteps:

1. Open SQL Server Management Studio and connect to Integration Services

2. Expand the Stored Packages folder in Object Explorer

3. Expand the subfolders to locate the package that needs to be exported.

4. Right-click the package, click Export, select File System, and then browse to a location

to save the package

There may be additional non-BizTalk DTS packages related to the solution These DTSpackages must also be duplicated at the disaster recovery site as well

Backing Up SQL Agent Jobs

BizTalk Server 2006 Log Shipping will re-create the SQL Agent jobs running in production onthe disaster recovery site; however, it is still a best practice to maintain backups of the SQLAgent jobs in case they need to be restored outside of a disaster recovery event Here are thesteps to back up a SQL Agent job in SQL Server 2000:

1. Open SQL Server 2000 Enterprise Manager

2. Expand the database server/instance

3. Expand the Management folder

4 Expand SQL Server Agent, and then click Jobs.

5. In the right pane, right-click each job listed, select All Tasks, and then Generate SQLScript

6. Choose a location by clicking the button with the caption … and enter a file name

7. Click OK to generate the script

8. Run the script using SQL Server Query Analyzer on the target disaster recovery site SQL Server instance where the BizTalk Configuration database is located

9. Go through the preceding steps for each job

For SQL Server 2005, the steps are similar:

1. Connect to the database instance using SQL Server Management Studio

2. Expand SQL Server Agent and click Jobs

3. Right-click each job and select Script Job as ➤Create To ➤File

4. Enter a file name and click Save

5. Go through the preceding steps for each job

The next subsection covers backup procedures for related non-BizTalk applications anddatabases

Related Non-BizTalk Applications and Databases

How related non-BizTalk application databases are backed up depends on the BizTalk tion As mentioned earlier, if an orchestration updates another database from within anatomic scope that results in a distributed transaction, the other database must be added

solu-to the adm_OtherBackupDatabases so that it is backed up by the Backup BizTalk Server SQL

Agent job and can be restored to the same log mark as all other databases that participate in

distributed transactions as part of the solution

For applications and databases that do not participate in distributed transactions withBizTalk but are still part of the overall application solution, these applications and databases

should be backed up following your corporate standards/guidance Essentially, the same

requirements apply in that the source code, code documentation, runtime environment,

etc., must be backed up such that the application and database can be restored successfully

Always practice a restore in a lab environment to confirm that enough information is

avail-able to be successful as well as automate as much of the process as possible

Next, we cover restore procedures for a BizTalk solution

Restore Procedures

Restoring a BizTalk-based solution, or any large application environment, is a challenging

process if not well documented, tested, and periodically rehearsed from an operations

train-ing standpoint BizTalk Server 2006 has its own set of unique steps required for successful

restore This subsection covers steps for recovering from various failure scenarios that do not

require transitioning to the disaster recovery site In some scenarios, this discussion leverages

the destination system databases and the SQL Agent automation available in order to safely

perform restore procedures minimizing manual steps This discussion covers restore steps for

the following scenarios:

• Restore procedures when refreshing the BizTalk databases in a development or testenvironment

• Restore procedures when migrating the production BizTalk databases to a more ful production database server without switching to the disaster recovery site

power-• Restore procedures when recovering the production database environment from ahardware failure such as a SAN failure without switching to the disaster recovery site(destination system)

• Restore procedures for a BAS site when recovering from a hardware failure

• Restore procedures for SQL Agent jobs and DTS packages

• Restore procedures for the master secret

• Restore procedures for the BizTalk runtime environmentThe next subsection covers how to stop and start BizTalk processing while performing any

of the restore scenarios listed previously

Stopping and Starting BizTalk Application Processing

This subsection lists the steps to stop, start, pause, or resume BizTalk processing using either

the Services administration tool or the command line Depending on the features configured

on a BizTalk runtime server, there are up to six services that must be managed:

• BizTalk Base EDI Service (edi subsystem)

• BizTalk Service BizTalk Group: <BizTalkServerApplication>

(btssvc$BizTalkServerApplication)

• Enterprise Single Sign-On Service (Entsso)

• Rule Engine Update Service (ruleengineupdateservice)

• BAM Event Notification Service (NS$BamAlerts)

• World Wide Web Publishing Service (W3SVC)Using the Services administration tool in the Control Panel, simply click Start, Stop,Pause, or Resume as needed for the scenario From a command prompt, enter the follow-

ing commands (where ServiceName corresponds to the values in parentheses in the

preceding list):

• Start a service: net start ServiceName

• Stop a service: net stop ServiceName

• Pause a service: net pause ServiceName

• Resume a service: net continue ServiceName

These commands can of course be scripted by placing the commands in a batch file orusing WMI so that all services can be controlled by a single step For example, a Stop.cmd filecould contain the following:

Net stop "edi subsystem"

Net stop Entsso

Net stop ruleengineupdatservice

Net stop btssvc$BizTalkServerApplication

Net stop NS$BamAlerts

Refreshing a Development or Test Environment

Here we cover the steps to restore a development environment or test environment back to

a “known” or “initial state.” These procedures can be used to help ensure that a testing ronment remains consistent between test runs or as new functionality is added to theapplication This scenario requires a consistent full backup set of the following items:

envi-• BizTalk databases

• Related non-BizTalk application databases

• Analysis Services databases for BAM or for Tracking Analysis Server

• DocumentsHome directory for EDI

• Windows SharePoint Services site customizations such as configuration files, site plates, client-side scripts, etc

tem-• Windows SharePoint Services Configuration and Content databases for BAS

■ Note To create the “initial state” full backup files, configure the development or test BizTalk Group as

needed, ensure no processing is occurring by following the procedures to stop processing listed in the

pre-ceding subsection, and then perform a full backup on all databases, analysis services databases, and the

DocumentsHome directory if using EDI by following the guidance detailed in the earlier subsection titled

“Backup Procedures.”

This procedure is based on “Moving BizTalk Server Databases” and related tion in the BizTalk Server 2006 core documentation Please be sure to review this section of the

documenta-BizTalk documentation before proceeding This is actually a simpler scenario than described

in the documentation, because the BizTalk runtime servers and SQL Server database instance

server names remain the same, so the steps to update database names and database locations

via script are not required

1. Stop all processing using the guidance listed in the earlier subsection titled “Stoppingand Starting BizTalk Application Processing.”

2. Obtain a copy of the “initial state” backup set and restore each BizTalk database andrelated non-BizTalk application database (if applicable) using SQL Server databaserestore procedures

3. Restore the applicable Analysis Services databases if using BAM or the Tracking sis Server database for HAT metrics with SQL Server 2000

Analy-4. Restore the BAS site if using BAS by following the guidance in the subsection titled

“Restore Procedures for BAS Site and Database” in the “Disaster Recovery” section later

in this chapter

5. Restore the DocumentsHome directory using the full backup that is part of the “initialstate” backup set if using EDI

6. Enable application processing by following the steps in the earlier subsection titled

“Stopping and Starting BizTalk Application Processing.” The development or test ronment is now restored to the “initial state.”

envi-Migrating Production Databases to More Powerful Servers

Migration is probably the most common scenario that a BizTalk application operations teamwill encounter with respect to having to move a database In this scenario, application pro-cessing is stopped using the procedure listed in the subsection titled “Stopping and StartingBizTalk Application Processing” earlier The next step is to perform a full backup on the appli-cable database that is being migrated Then perform the steps necessary to update references

to the new database location for the BizTalk Group The specific steps are covered in theBizTalk Server 2006 core documentation in the section titled “Moving BizTalk Server Data-bases” for the following databases:

• BAM Primary Import database

• BAM Archive database

• BAM Star Schema database

• BAM Analysis database

• BAM Notification Services database

• Messsagebox databasePlease refer to the BizTalk Server 2006 core documentation for the specific steps to movethese databases

Recovering Production Database Environment from Hardware Failure

This scenario covers restoring the BizTalk Group databases that are backed up by the BackupBizTalk Server SQL Agent job There are two options for this scenario The first is to perform afull disaster recovery event by following the procedures listed in the section titled “DisasterRecovery” later in this chapter This is the option available when reviewing the BizTalk Server

2006 core documentation

Another option that leverages the disaster recovery infrastructure without actually forming a full disaster recovery is to obtain a copy of the databases from the disaster recoverydestination system database instances and perform a restore of the databases at the produc-tion site The second option is available if the BizTalk application operations team is able tocorrect the hardware failure in a timely manner in accordance with availability and corporaterequirements and those server and database instance names do not change Since this sce-nario requires that BizTalk Log Shipping is configured, before proceeding with either option,review the section that follows titled “Disaster Recovery.”

per-■ Caution The second option is not documented in the BizTalk Server 2006 documentation and therefore

is not supported by Microsoft However, choosing the second option does not remove the first option Whenperforming the second option, a copy of the databases is maintained at the destination system so that if thatprocedure fails, a full disaster recovery can be performed by completing the steps in the first option to bringthe destination system online

The second option assumes that the BizTalk runtime servers, database servers, and allrelated servers and sites are back to fully operational, but the most up-to-date version of the

application databases are required in order to restart processing The disaster recovery site

(destination system) will generally have the latest copy of the database available, so this

sce-nario leverages the availability of those databases to quickly restore processing at the

production site

■ Note Performing option two will require that BizTalk Log Shipping be removed and then reconfigured at

the destination system once the production system is back online Otherwise an error will be received in the

destination system that states “The databases have already been restored to a mark” and the destination

system SQL Agent job “BTS Log Shipping—Restore Databases” will fail

In order to obtain the latest version of the databases from the destination system, theoperations team must ensure that all of the log backup sets (except for the latest set available)

have been successfully restored to the databases To determine the last successful backup set

restored, review the contents of the Master.dbo.bts_LogShippingHistory table on each

data-base instance in the destination system This table is populated by the Get Backup History job

and updated by the Restore Databases job When a backup is successfully restored, the

Restored column is set to 1 and the RestoredDateTime is set to the current date and time

When all of the databases being restored to the server from a particular backup set have

been successfully restored, that backup set ID is written to the Master.dbo.bts_

LogShippingLastRestoreSet table Once all of the log backup sets except for the last available

have been confirmed to have been successfully restored, follow these steps:

1. Stop application processing by following the procedures in the subsection titled ping and Starting BizTalk Application Processing” to prevent any database activityfrom occurring until the production database environment is fully configured

“Stop-2. Depending on whether you are on SQL Server 2000 or SQL Server 2005, navigate to theSQL Agent Jobs view on the destination system SQL Server database instances

3. Right-click and select Disable Job to disable the following SQL Agent jobs on the nation system disaster recovery SQL Server database instances:

desti-• BTS Log Shipping—Get Backup History

• BTS Log Shipping—Restore Databases

4 Right-click BTS Log Shipping—Restore To Mark and select Start Job on the destination

system SQL Server database instances

5. Once you have verified that the job BTS Log Shipping—Restore To Mark has pleted, detach each database from the destination system SQL Server databaseinstance, and copy each database file over to the appropriate storage area on thesource system (production) so the databases can be attached to the correct produc-tion SQL Server database instance in order to bring the production databaseinstances online

com-■ Caution Ensure that a copy of the database files remains at the destination system in case it is needed

in the event of an unsuccessful attempt to restore production processing, and the destination system must

be brought online by completing the steps in option one

6. Disable the following SQL Server Agent jobs on the source system SQL Server databaseinstances (this step assumes that the Backup BizTalk Server and DTA Purge andArchive jobs have been configured and enabled):

• Backup BizTalk Server (BizTalkMgmtDb)

■ Note If the BAM Archive, BAM Star Schema, or BAM Analysis databases were affected by the hardwarefailure as well, then these databases should be restored by using a backup older than the BAM PrimaryImport database backup

8. Enable the following SQL Agent jobs on the source system production SQL Serverdatabase instances:

■ Note Do not enable the SQL Agent job MessageBox_Message_Cleanup_<BizTalkMsgBoxDb> by mistake

It is always disabled by default

• Backup BizTalk Server (BizTalkMgmtDb)

sys-“Stopping and Starting BizTalk Application Processing.”

10. Remove and then reconfigure BizTalk Log Shipping at the destination system

Next we cover another restore scenario when the BAS site is not available

When Recovering from Hardware Failure of a BAS Site

In the event that a BAS site encounters a hardware failure, but otherwise the BizTalk solution

is fully functional, then only the steps to restore BAS are required These steps are detailed in

the subsection titled “Restore Procedures for BAS Site and Database” in the “Disaster

Recov-ery” section later in this chapter

SQL Agent Jobs

The SQL Agent jobs are a critical tool for maintaining the BizTalk Group If one of these jobs

is accidentally deleted or needs to be restored as part of restoring the BizTalk Group, obtain

the backed-up script file for the SQL Agent job and execute the script for the SQL Agent job

in a query window Check the status of the SQL Agent jobs in SQL Server Ensure the correct

account is configured to run each job

DTS Packages

If the BizTalk solution has BAM configured with BM.exe, BM.exe will create a set of DTS

pack-ages to produce the OLAP cubes For each DTS package, import the package using SQL Server

2000 Enterprise Manager or SQL Server 2005 Integration Services Check the status of the DTS

package in Enterprise Manager

The Master Secret

The master secret is a critical item that must be backed up and stored in a safe place It is notpossible for BizTalk Server to function or to be restored without the master secret There aretwo scenarios where the master secret server must be restored:

• Failure of the master secret server for an existing BizTalk Group

• Restoration of the master secret server as part of restoring a BizTalk Group to anotherset of servers

This subsection covers the procedures to restore the master secret server for the BizTalkGroup If the original master secret server fails and cannot be recovered, but the BizTalk Group

is still available and functioning except for the master secret server, another server can be moted as the master secret server To promote a Single Sign-On Server in the BizTalk Group tomaster secret server, follow these steps:

pro-1. Create an XML file that includes the name of the SSO server that will be promoted tomaster secret server For example:

2 On the Start menu, click Run, and then type cmd.

3. At the command-line prompt, go to the Enterprise Single Sign-On installation

direc-tory The default installation directory is <drive>:\Program Files\Common Files\

Enterprise Single Sign-On

4. Type ssomanage -updatedb <update file>, where <update file> is the name of the XML

file created in step 1

5. Type ssoconfig -restoresecret <restore file>, where <restore file> is the path and name

of the file where the master secret backup is stored

Now let’s move on to the procedures for restoring the BizTalk runtime environment

BizTalk Runtime Environment

If the BizTalk runtime environment is intact, then restoring the BizTalk runtime environment

is a matter of verifying connectivity by opening the BizTalk Administration Console and thenrestarting processing by starting the items stopped in the subsection titled “Stopping andStarting BizTalk Application Processing” earlier

■ Caution If the BizTalk applications are dependent on related non-BizTalk applications and databases,then these related applications and databases must be available before restarting processing

If the BizTalk runtime environment must also be rebuilt, and the server names will be thesame, first install BizTalk following the same procedures originally used to install BizTalk.

Once BizTalk is installed, run Configuration.exe and join the BizTalk Group that has been

pre-viously restored

■ Note Do not create a new BizTalk Group This will result in a new set of databases, whereas the goal is to

use the existing BizTalk Group that was restored

Restore the master secret on the server with the same server name as the original mastersecret server Or, restore the master secret to a new server and then perform the steps to desig-

nate the new server as the master secret server Redeploy the BizTalk applications and

bindings into the environment as needed

Next, you’ll learn the restore procedures for non-BizTalk, but related, applications anddatabases

Related Non-BizTalk Applications and Databases

A BizTalk solution may update or receive data from non-BizTalk applications as part of the

overall solution If the related non-BizTalk applications include a database that participates in

distributed transactions with BizTalk, this database should be added to the Backup BizTalk

Server SQL Agent job and restored to the same log mark as the BizTalk databases Otherwise,

restore the non-BizTalk application and databases following the documentation for that

application

This wraps up our discussion on maintaining the BizTalk Group Next we discuss disasterrecovery procedures for BizTalk applications

Disaster Recovery

Business-critical software solutions must have a disaster recovery plan in order to protect

against major system disruptions A disaster recovery plan must include steps to bring the

backup site online as well as steps to deal with potential data loss as a result of the major

system disruption BizTalk Server 2006–based solutions require a comprehensive disaster

recovery plan that covers both the BizTalk servers and the BizTalk Group running in SQL

Server BizTalk Server 2006 disaster recovery requirements include the following:

• BizTalk Server 2006 Log Shipping configuration for disaster recovery

• BizTalk Server 2006 Log Shipping procedures for restoring the BizTalk Group as part ofdisaster recovery

• BizTalk runtime environment disaster recovery proceduresThese items make up the core disaster recovery requirements for BizTalk Server 2006

Additional disaster recovery procedures are required for any additional application databases,

application code, other middleware products, etc

■ Note Application teams must plan to test disaster recovery procedures before entering production and

on a recurring basis to ensure current operations personnel understand the process and can implement itsuccessfully

There is better automation of the required tasks to configure and implement disasterrecovery for a BizTalk Server 2006 solution that helps to simplify the process Also, the BizTalkServer 2006 core documentation greatly increases the amount of documentation regardingBizTalk Server Log Shipping and disaster recovery The procedures in this section are based onthe product documentation and should be reviewed along with this chapter In addition, thissection details additional configure steps encountered while testing out the procedures notfound in the BizTalk Server 2006 core documentation

■ Caution The steps to manually update the required database fields in order to move a BizTalk Group

to a new set of database server instances without using BizTalk Log Shipping are not documented forBizTalk Server 2006 Therefore we strongly recommend configuring BizTalk Log Shipping as part of anyBizTalk Server 2006 production environment

Next, let’s take a look at how BizTalk Log Shipping works

How Does BizTalk Log Shipping Work?

Because BizTalk Server 2006 implements distributed transactions between BizTalk databases

in the BizTalk Group through log marks, typical SQL Server disaster recovery technology such

as SQL Server Log Shipping cannot be used for BizTalk databases that participate in DTCtransactions Therefore, BizTalk Server 2006 provides BizTalk Log Shipping

■ Tip When referring to BizTalk Log Shipping, the source system is the production SQL Server database instances and the destination system is the disaster recovery SQL Server database instances.

BizTalk Log Shipping uses capabilities within SQL Server that takes into account log marksand DTC transactions while providing very similar functionality to SQL Server Log Shipping

As with SQL Server Log Shipping, BizTalk Log Shipping performs log backups at the specifiedinterval in the Backup BizTalk Server SQL Agent job The log backups are then continuouslyapplied to a SQL Server instance that is the disaster recovery server

The primary difference between SQL Log Shipping and BizTalk Log Shipping is that whenperforming a disaster recovery event with BizTalk Group databases, the last log is applied withthe STOPATMARK SQL Server RESTORE command option to restore all databases to the same point

by the SQL Agent job named BTS Log Shipping—Restore To Mark for each database instance

in the destination system Figure 9-4 describes how BizTalk Log Shipping works

When the disaster recovery SQL Server instances in the destination system are ured for BizTalk Log Shipping, the backup files created by the Backup BizTalk SQL Agent job

config-are restored at the disaster recovery site every 15 minutes The backup files config-are copied over

the network by a SQL RESTORE command Full backup files are only copied in the following

situations:

• When BizTalk Log Shipping is first configured

• When a new database is added to the BizTalk Log Shipping SQL Agent job

• When a RESTORE failure occursEach SQL instance at the disaster recovery site is configured individually as part of BizTalkLog Shipping When a SQL instance is configured for BizTalk Log Shipping and the SQL Agent

Figure 9-4.BizTalk Log Shipping process

job is enabled, the SQL Agent job will connect to the management database on the productionBizTalk Group, find the most recent full backup set at the UNC share, and attempt to restorethe database.

■ Note If you move the full or log backups for a source database from the location in which the BackupBizTalk Server job put them, the associated row for that database in the bts_LogShippingDatabases table onthe destination system must be updated by setting LogFileLocation or DBFileLocation to the new locationwhere the destination system should retrieve them By default these values are Null, which tells the destina-tion system to read the backup files from the location stored in the adm_BackupHistory table

On the disaster recovery SQL instances configured for BizTalk Log Shipping, the bases will be displayed in a “loading” state in SQL Server 2000 and “restoring” state in SQLServer 2005 This is because the last log in a backup set is never restored automatically Once

data-a new log is data-avdata-aildata-able, BizTdata-alk Log Shipping restores the next-to-ldata-ast log When data-a disdata-asterrecovery event occurs and the disaster recovery site must be brought online, the last log isrestored automatically using the STOPATMARK command by the SQL Agent job named BTS LogShipping—Restore To Mark on each destination system SQL instance to recover the databases,and the databases will no longer be in a “loading” or “restoring” state

BizTalk Server 2006 Log Shipping supports two scenarios: In one scenario, all databases

on all BizTalk databases on all production SQL server instances are log-shipped to a single aster recovery SQL server database instance The other scenario maps all source databases oneach source SQL Server instance to an associated destination SQL Server instance Note that

dis-it is fully supported to have the same number of SQL Server database instances in the disasterrecovery site as there is in production, but on fewer physical servers—i.e., it is not required tohave the same number of physical servers, just the same number of database instances for thesecond option

The next subsection covers configuration of the destination system SQL Server instancefor BizTalk Log Shipping

Configuring the Destination System for Log Shipping

Here we cover the steps to configure BizTalk Log Shipping As mentioned previously, ensurethat the same path where database files are located in production exists on the destinationsystem So, in the earlier example where there are three SQL Server database instances in pro-duction, all three database instances must store the database files (MDF and LDF files) in thesame path on each server, and this path must also exist on the destination system SQL Serverdatabase instances The database file path can be set or changed within SQL Server

Another configuration step on the destination system SQL instances is to create a linkedserver that points to the source system SQL instances There should be a linked server createdthat points to the production SQL instance hosting the management database This will allowthe SQL Agent job running on the destination system SQL Server instances to access theBizTalk Management Database to retrieve the backup history and database and log backupfile location