Programming4us
         
 
 
Applications Server

BizTalk Server 2006 Operations : Maintaining the BizTalk Group (part 2) - Backup Procedures

6/4/2011 4:53:18 PM

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 BizTalk requires 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 this article  ; however in general, application code, artifacts, code documentation, and server configuration documentation should be kept in a source code control system that is backed up automatically with rotating backup sets maintained at an offsite location.

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

BizTalk Servers

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

  • BizTalk installation: Document what features/service pack/hotfixes are installed on the BizTalk runtime server. Document what other products such as SharePoint, IIS, or third-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 whether the BizTalk Windows server name changed or the SQL instance location of the databases has changed.

  • Master secret: This is an extremely important backup item. Without the master secret, a BizTalk Group cannot be restored. The master secret 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 to restore the BizTalk runtime servers. It is recommended to automate installation, configuration, 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 managing Enterprise SSO and the master secret, as shown in Figure 1. To launch the SSO Administration 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.

Figure 1. SSO Administration MMC console

Clicking Backup Secret displays the dialog box shown in Figure 2, where you enter a location 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 2 : Backup Secret dialog

The Enterprise SSO tools SSOManage.exe and SSOConfig.exe are still available in the C:\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 of databases created by BizTalk Server 2006 during configuration. All of the normal requirements when performing SQL backups apply: allocating sufficient storage space where backup files are stored, copying backup files to an offsite location, testing restore files on a regular basis such 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 databases can be backed up without requiring System Administrator permissions within SQL Server, except for the primary server controlling the backup process.

If not done already, configure the Backup BizTalk Server SQL Agent job following the instructions in the earlier subsection titled "Configuring the Backup BizTalk Server SQL Agent Job." 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 the Backup 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 because they 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 BizTalk Management database (BizTalkMgmtDb). Other application databases that participate in DTC transactions (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 2 lists the column names.

Table 2 Columns in the adm_OtherBackupDatabases Table
Field NameValue
DefaultDatabaseNameThe alias for the database. Can be the same as the database name or the application name.
DatabaseNameThe actual name of the database.
ServerNameThe name of the SQL Server instance hosting the database.
BTSServerNameName 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.

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 consistent. 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 the adm_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 rolesto 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 SQL Server 2005 Analysis Services and is not available as an option when configuring the BizTalk Group 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 database is present:

  • BAM Analysis (BAMAnalysis)

  • Tracking Analysis Server (BizTalkAnalysisdb)

These Analysis Services databases must be backed up following the procedures for backing up SQL Analysis Services databases.

There are two scenarios for backing up BAM SQL Server databases when BAM is enabled through 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 BAM features)

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 Transformation Services (DTS) packages present in the solution. Therefore, the BAM SQL databases can be backed up using regular SQL Server backup procedures or can be added to the Backup BizTalk Server SQL Agent job by adding the table to the adm_OtherBackupDatabases table for convenience. 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 next subsection 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 creation of one or more DTS packages that must be backed up in case they are accidentally deleted as well as duplicated on the disaster recovery site. Backup procedures for DTS packages are documented in SQL Server Books Online.

Before backing up the BAM databases, ensure that neither the BAM cube process nor data 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 and DTS 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 as well as the other BizTalk Server databases.

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

    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 Archive database 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 database before 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 environment 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 of the services included in BAS.

  • A Trading Partner Management database. This database stores trading partner data for BAS. 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. Perform the following steps to back up the BAS site and database:

    1. After BAS is configured, back up all of the changes made to the web application configuration files and Windows SharePoint Services site templates so these can be recovered later. There may be modifications in other places, for example, in client-side JavaScript files if the site has been customized by the development team. These changes must be documented and backed up to a source code control system as well.

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

    3. Follow the instructions in the "Windows SharePoint Services Administrator's Guide" to back up the Windows SharePoint Services Configuration and Content databases. This guide is available for download here: www.microsoft.com/downloads/details.aspx?amp;displaylang=en&familyid=a637eff6-8224-4b19-a6a4- 3e33fa13d230&displaylang=en.

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 first step 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 an in-place upgrade was performed when BizTalk Server 2006 was installed.

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

The entire DocumentsHome directory should be backed up frequently using a file-based high-capacity backup system. Ideally, the DocumentsHome directory is mirrored using a robust high-capacity storage technology. This also allows fast restore time because the system automatically 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 configured to be received at an alternate receive location that makes a copy of the incoming document before sending the document to the EDI receive location. This provides an additional layer of archive for inbound documents. Another option is to enable message body tracking on inbound EDI documents. Legal implications may surround message body tracking depending on the legal agreements with trading partners. Be sure to review all legal agreements before enabling message body tracking. Also, message body tracking greatly increases database growth, which must be taken into account because of potential performance 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 Business Activity 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 the target 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 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.

There may be additional non-BizTalk DTS packages related to the solution. These DTS packages 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 on the disaster recovery site; however, it is still a best practice to maintain backups of the SQL Agent jobs in case they need to be restored outside of a disaster recovery event. Here are the steps 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 SQL Script.

  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 and databases.

Related Non-BizTalk Applications and Databases

How related non-BizTalk application databases are backed up depends on the BizTalk solution. As mentioned earlier, if an orchestration updates another database from within an atomic scope that results in a distributed transaction, the other database must be added 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 with BizTalk 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 available to be successful as well as automate as much of the process as possible.

Next, we cover restore procedures for a BizTalk solution.

Other -----------------
- BizTalk Server 2006 Operations : Configuration and Management
- Exchange Server 2003 : SMTP Protocol Configuration and Management - Managing SMTP Message Transfer Support
- Exchange Server 2003 : Virtual Servers - Configuring Authentication
- Exchange Server 2003 : Configuring Virtual Server Settings
- Overview of Exchange Server 2003 Virtual Servers
- Microsoft Exchange Server 2003 : Public Folder Security
- Microsoft Exchange Server 2003 : Administering Public Folders
- BizTalk 2010 Recipes : Business Rules Framework - Deploying and Undeploying Policies
- BizTalk 2010 Recipes : Business Rules Framework - Calling the Business Rules Engine from an Orchestration
- BizTalk 2010 Recipes : Business Rules Framework - Calling the Business Rules Engine from dot NET
- BizTalk 2010 Recipes : Business Rules Framework - Creating Custom Fact Retrievers
- BizTalk 2010 Recipes : Business Rules Framework - Setting Rule Priorities
- BizTalk 2010 Recipes: Business Rules Framework - Creating Facts
- BizTalk 2010 Recipes: Business Rules Framework - Creating and Testing Rules
- BizTalk 2010 Recipes: Business Rules Framework - Creating a Business Policy
- Exchange Server 2003 : Creating Public Folders (part 2)
- Exchange Server 2003 : Creating Public Folders (part 1)
- Exchange Server 2003 : Creating and Managing Address Lists and Recipient Policies (part 3) - Working with Offline Address Lists & Creating and Applying Recipient Policies
- Exchange Server 2003 : Creating and Managing Address Lists and Recipient Policies (part 2) - Administering Address Lists
- Exchange Server 2003 : Creating and Managing Address Lists and Recipient Policies (part 1) - Creating and Modifying Address Lists
 
 
Most View
- SQL Server 2008 R2 : Planning for SQL Server Data Replication & SQL Server Replication Types
- Programming Excel with VBA and .NET : Tasks in Visual Basic - Find Truth & Compare Bits
- Windows Server 2008 : Recovering Role Services and Features (part 1)
- Windows 7 : Keeping the Registry Safe
- Windows Server 2008 Server Core : Understanding Internal and External Commands
- Windows Phone 7 : Finding Text on a Web Page
- .NET Components : Serialization and Class Hierarchies (part 1) - Custom Serialization and Base Classes
- Installing SQL Server 2008 Using a Configuration File
- iOS SDK : Debugging (part 2) - Watchpoints
- Windows 7 : Thwarting Spam with Windows Live Mail’s Junk Filter (part 1)
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS