Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

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

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
11/25/2012 11:15:29 AM

2. 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, backing up an application solution that includes BizTalk requires the following general procedures:

  • Backing up application code, artifacts, and documentation

  • Backing up server configuration documentation

  • Backing up BizTalk servers and BizTalk Group databases

  • Backing up related non-BizTalk databases

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

2.1. 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 event:

  • 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 file 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.

2.2. The Master Secret

BizTalk Server 2009 uses the Microsoft Management Console 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 box

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.

2.3. BizTalk Group

This subsection covers backup procedures for the BizTalk Group, which consists of a set of databases created by BizTalk Server 2009 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, and so on. 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)

  • 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 2009 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 2009\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.

2.4. BAM Analysis Services and Supporting Databases

BizTalk leverages SQL Server Analysis Services for reporting and analysis functionality as part of the Business Activity Monitoring features. In BizTalk Server 2009, the Tracking Analysis Server OLAP database is available in BizTalk installations as part of the BizTalk Group 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.

2.4.1. BAM Enabled but Not Configured in a BizTalk Group

Since BAM is not configured with BM.exe, there are not any BAM-related SSIS 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 is maintained. The next subsection covers backup procedures when BAM is enabled and configured with BM.exe.

2.4.2. 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 SSIS packages that must be backed up in case they are accidentally deleted as well as duplicated on the disaster recovery site.

Before backing up the BAM databases, ensure that neither the BAM cube process nor the 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 SSIS package for all activities.

    Incorporate these steps into an SSIS package, scheduling it to run on a regular basis. To guarantee data integrity, ensure no other BAM cubing or SSIS 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 SSIS package for each activity to add a step to back up the BAM Archive database before the last step in the SSIS 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.

2.5. SSIS Packages

All SSIS 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 SSIS packages with SQL Server 2005/2008, 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/2008, 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.

2.6. Backing Up SQL Agent Jobs

BizTalk Server 2009 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.

For SQL Server 2005/2008, 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.

2.7. 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, and so on, 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 -----------------
- SQL Server 2008 R2 : Managing Workloads with the Resource Governor - Modifying Your Resource Governor Configuration
- SQL Server 2008 R2 : Managing Workloads with the Resource Governor - Monitoring Resource Usage
- Windows Server 2008 Server Core : Decompressing Files with the Expand Utility, Performing Advanced File Comparison with the FC Utility
- Windows Server 2008 Server Core : Modifying Files with the Edlin Utility, Repairing System Databases with the ESEnTUtl Utility
- Microsoft Dynamics CRM 4.0 : Silverlight - Tools and Resources
- Microsoft Dynamics CRM 4.0 : Infrastructure Design Considerations - Windows SharePoint Integration
- Connecting Dynamics GP to Microsoft Office 2010 : Improving performance by globally turning off Outlook integration
- Connecting Dynamics GP to Microsoft Office 2010 : Skipping the exports by using Prebuilt Excel Reports
- Microsoft Dynamics AX 2009 : Integration with Microsoft Office - Reading Excel files
- Microsoft Dynamics AX 2009 : Integration with Microsoft Office - Creating Excel files
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
 
programming4us
Natural Miscarriage
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Game Trailer