1

Backup and Recovery

Administering BizTalk Server 2010 is quite different than previous versions of BizTalk
Server. We have a new Administration Dashboard with new features and
functionality. Some of these features are.
 Performance tuning
 Ability to streamline our deployments across Environments.
 Trading Partner Management
This chapter is all about Backup and Recovery.
 We will discover that Backup and Recovery is a Team effort
 We will learn about the steps involved to create a proper Backup Plan.
 We will learn about the types of Backup Storage available.
 We will discover open-source tools that will help you implement your
backups.
 We will learn how to recover from a Disaster.
 We will walk-thru actual Backup and Restore scenarios provided by
some of your peers
BizTalk 2010 Administration is a team effort. It involves many IT Roles; BizTalk
Server Administrator, BizTalk Applications Administrators, DBA’s, System
Administrators, Network Administrators, BizTalk Developers, System Analysts and
Business Analysts.
The key roles for the Backup and Recovery of a BizTalk 2010 Server Environment are:
 The BizTalk 2010 Administrator Role has overall responsibility for the
BizTalk 2010 Server Environment.
 The BizTalk Applications Administrator Role has the responsibility of
managing one or more BizTalk Applications.
 The Database Administrator Role has the responsibility of
administering BizTalk SQL Servers.
  The System Administrators Role the responsibility of administering the
Windows Server for the BizTalk 2010 Environment.
 The Network Administrators Role has the responsibility of ensure
Networking ACLs between environments. And sometimes across
networks.

Backing Up the BizTalk Server Environment

Before we discuss the why and how of backing up of a BizTalk 2010 Server
Environment, we first need to understand the need for a Disaster Recovery Plan and
what it consists of.

Disaster Recovery Plan

Disaster recovery procedures improve system availability by employing steps to resume
operation of a failed system. Disaster recovery differs from fault tolerance in that disaster
recovery typically requires manual intervention to restore the failed system whereas a
fault-tolerant design can continue to operate without manual intervention if the system
encounters a failure condition.
Disaster Recovery is a process that spans along the whole lifecycle of the target system,
since the early inception and planning of the Disaster Recovery strategy, followed by the
actual implementation of the different procedures, policies and deliverables, culminated
when the strategy is actually applied in the midst of any disruptive events that might
happen during the operation of the system.
The fundamental basis of Disaster Recovery Planning is to develop a methodology that
begins with project planning and loss avoidance and following through to ongoing testing
and maintenance. The Microsoft Operations Framework Service Management
Functions provide us with the guidance to meet our goals.

Microsoft Operations Framework

This strategy is meant to change and evolve as long as it needs to be iteratively re-aligned
with any changes undertaken into the original system. All these stages aligned with the
iterative cycle and the corresponding phases defined by the Microsoft Operations
Framework. We will discuss this more in Appendix A – MOF
Microsoft Operations Framework (MOF) 4.0 delivers practical guidance for everyday
IT practices and activities, helping users establish and implement reliable, cost-effective
IT services. It encompasses the entire IT lifecycle by integrating, and it is available for
download from Microsoft technet.microsoft.com/library/cc506049.aspx

2
The Backup section provides us with the necessary steps to follow when creating a
Disaster Recovery Plan. Before we start creating our plan we need requirements.
These are normally defined within a Service Level Agreement (SLA) and/or Disaster
Level Agreement (DLA). Without this we cannot proceed.

Creating the Disaster Recovery Plan

The following diagram shows the recommended steps we follow when creating our
Disaster Recovery Plan.

These are the the steps we will follow.

1. The first step is create an Outline of our Backup and Restore Plan.
2. We then define where the backup will be stored.
3. Next we define What we will Backup.
4. Then we define our Backup Schedule
5. And finally we Select our Offsite Location that will store our Archive
Backups.

Outline Backup and Restore Plan

The following diagram shows the recommended steps to follow when creating our plan.

The steps we take are as follows.

1. Our first step is to create our Backup and Restore Sections.
2. Next we need to identify the required tasks.
3. Finally, we need to assign Tasks to each Role.

3
Disaster Recovery Site
The Disaster Recovery Site is also referred to as the “Backup Site”. Wikipedia defines a
Backup Site as a location where an organization can easily relocate following a
disaster. There are three types of Disaster Recovery Sites.
 Cold Site
 Hot Site
 Warm Site

Cold Site
The Cold Site is simply an offsite data center location where the BizTalk Environment
can be rebuilt. It does not contain backup or configuration data.

Hot Site
The Hot Site is a mirror of the BizTalk Environment. Real time synchronization exists
between the sites.

Warm Site
The Warm Site is a compromise between the Cold and Hot Sites. The Warm Site has
connectivity established between the sites. It has the basic hardware required to operate.
There is no Real Time synchronization between the sites. Backups are usually sent by
FTP or courier.
The following diagram shows the recommended steps to follow when selecting the
Disaster Recovery Site.

4
There are two steps we need to take.
1. Our first step is to decide the Type of Backup Site.
2. We have a choice of using either a Cold, Warm, or Hot Backup Site.

Defining what will be backed up

It is extremely important the we define what we are going to back up. We will need to
create a checklist document that includes all the details about each item.
The following diagram shows the recommended steps to follow.

The steps we take are as follows.

1. We first create a Backup Checklist.
2. Then we need to create our backup Tasks.
3. Finally, we assign our backup tasks to roles.

Defining the backup schedule

It is critical to define the when backups are to occur. The following diagram shows the
recommended steps to follow.

5
Essentially there are two step.
1. We must first determine when our backups will occur.
2. Then we need to decide who is responsible for each task. This can be the
Database, System, Application, or BizTalk Administrator.

Selecting the offsite location for archive backup

Because any type of disaster could occur, it is not recommended to store archive backups
in the same location as our BizTalk environment.
The following diagram shows the steps for the selection of an Offsite Location.

6
The steps we take are as follows.
1. We must decide on the type of offsite location
2. We can use either a Remote Data Center, Third-Party Provider, or Cloud
Storage.

On-site Backup Sources

In order to insure that we can recover BizTalk Server 2010 after any type of failure, it is
critical to back up the BizTalk Server 2010 Artifacts, Components and Dependencies.
Backup Storage Locations

Typically we would use a file share or Source Control as the Storage Location.
The use of Team Foundation Server 2010 is a good example.

Note:
This Folder Layout would only be accessible to the BizTalk Administrators
Group. There would be separate folders for each BizTalk Environment
excluding Development.

7
The following table shows the recommended TFS 2010 Source Control Project Folder
layout for a BizTalk 2010 Production environment.
Base Folder Sub-Folder(s) Content
Project(Name) Assemblies Applications DLL
Project(Name) Bindings Application Bindings
Project(Name) BAM Tracking Profile BAM Tracking Profiles
Project(Name) BAM Activities BAM Activities
Project(Name) Referenced DLL Dependent DLL’s
Project(Name) Deployment Scripts Deployment Scripts
Project(Name) Documentation Project Documentation
Project(Name) Database Scripts Database Scripts
Project(Name) MSI MSI files
Project(Name) BRE Policies Project Policies
Project(Name) BRE Vocabularies Project Vocabularies
Project(Name) BRE Custom DLL Custom BRE Components
Project(Name) Services Custom Services
Project(Name) Components Custom Component DLL’s

Artifacts
Artifacts should be backed up and stored in the following TFS 2010 Source Control
Project Folder locations:
Artifact Storage Location Comments

BizTalk Configuration Files \Bindings TFS 2010 – Source Control

BizTalk Application Configuration
Files
\Configuration Application configuration is
stored in the BizTalk
configuration file.
This file is in source control
and gets restored to the
BizTalk install directory.

BizTalk Passwords \Configuration\ TFS 2010 – Source Control

Passwords

BizTalk BAM Portal Config \Configuration\Bam TFS 2010 – Source Control

8
 Config

BizTalk Servers Configuration \Logs TFS 2010 – Source Control

Log
BizTalk Database Backups Secondary Drive on
BizTalk SQL Server or
UNC Share

Enterprise Master Secret \Configuration\SSO TFS 2010 – Source Control

Database Servers Software Log \Logs TFS 2010 – Source Control

BizTalk Application Database \Database Scripts TFS 2010 – Source Control

Scripts

BizTalk Application MSI \Project MSI TFS 2010 – Source Control

Referenced DLL \Referenced DLLs TFS 2010 – Source Control

BizTalk Server
The following Components are Backed Up by the Responsible Resource
Component Responsible Resource
BizTalk configuration files BizTalk Applications Administrator
BAM Portal (IIS configuration) BizTalk Applications Administrator
Application Configuration Files BizTalk Applications Administrator
Password information for configuration BizTalk Applications Administrator

Software Update Log BizTalk Applications Administrator

BizTalk Databases Database Administrator
Enterprise Single Sign-On master Database Administrator, BizTalk Applications
secret. Administrator
Software Update Log Database Administrator, BizTalk Applications
Administrator
BizTalk Windows Accounts Systems Administrator

It is extremely important to back up the Enterprise SSO Master Secret. Without

it, we would not be able to restore our BizTalk Environment.

9
 The SSO Key needs to be stored in a safe location.

Make a backup copy of the Master Secret and give it to a few top level IT officers
to store in a secure location. Ideally, you want someone who is not bound to
leave your company. Database Jobs
The following sql server jobs will need to be configured and monitored by the DBA Role.
These are the only SQL Agent Jobs that are not setup when BizTalk is configured. If
these jobs are not properly configured and enabled, it would be almost impossible to
restore our BizTalk Environment.
SQL Job Detail Comments
Backup BizTalk Server Job to backup BizTalk databases The Backup BizTalk
on a scheduled basis. Databases Server job does not delete
backed up by this job are: outdated backup files, so
1.) BizTalkMsgBoxDb we need to manually
manage those backup
2.) BizTalkMgmtDb
files to conserve disk
3.) BizTalkDTADb space.
4.) BAMPrimaryImport
5.) BAMAlertsNSMain After we have created a
6.) BAMAlertsApplication new full backup of our
databases, we should
7.) BizTalkRuleEngineDb move the outdated
8.) SSODB backup files onto an
archival storage device to
reclaim space on the
primary disk.

DTA Purge and Archive Job to archive and purge the

BizTalk Tracking Database.

This is important because if this

database is left to grow, it will
result in the database running
out of space and a system
failure.

10
The Backup BizTalk Server job needs to be configured before enabling it.
Configuring the Backup BizTalk Server job
Open the properties of the Backup BizTalk Server (BizTalkMgmtDb) job in SQL
Server Management studio and edit the job’s properties. The main configuration to make
is setting up the four job steps according to our backup needs:
Before configuring this job, we must decide on how we are going to set the four step
parameters. We can accept the default settings, which will work well for most
implmentations. As our needs change, we can modify these settings later.
 Set Compression Option Step: This step will configure the job to
apply compression or not to the backups. The default value for its
parameter is 0 (compression off). To enable compression, we set it to 1
as shown in the following figure.

11
  Backup Full Step: This step executes the actual full backup generation.
Its parameters are
 Frequency: specifies how often full backups are taken. The
possible values are d (daily), h (hourly), w (weekly), m (monthly),
or y (yearly).
 Name: The name that will be given to the backup files
 Location of backup files: The path where backup files will be
stores. It´s recommended setting it to a network share outside of
the server where the databases are hosted.
 Force full backup after partial backup failures: It´s default
value is 0 (no full backup forced until the next scheduled

12
 backup). With a value of 1, a full backup will be taken in case a
log backup fails.
 Local time hour for the backup process to run: The time of
the day when the full backup will be taken. A value of null,
means that it will be taken at midnight UTC time. If a numeric
value is configured (0 -23), it will make the backup to be taken
by that hour on the server time zone.
The following figure shows the Job Set Properties for Backupfull.

 MarkAndBackup Step: This step is the one that will mark the logs for
backup (so the mark between the different databases is consistent) and
then backing them up. We will set the name that will be given to the

13
 backup files, and the destination path where they will be stored as shown
in the following figure.

 Clear Backup History Step: This step will clean up old backup files.
Its single parameter configures the amount of days log files will be kept
as shown in the figure below.

14
Automating the Backup process
There are several tools available on Codeplex that simplifies the backup process. We can
easily use these tools to help automate our backup process.
BizTalk Backup Tool and BizTalk Environment Config Loader
The “BizTalk Backup Tool” and the ”BizTalk Environment Config Loader”
tools were developed by Rudolf Henning. We can read more about Rudolf in
Appendix B- Scenario Contributors.
Rudolf describes both these tools and how they are used:

15
The BizTalk Backup Tool
The BizTalk Backup tool is intended to assist a BizTalk Administrator to create
a 'snap-shot' of the config of the BizTalk environment at that moment of time.
Typically it should be part of a scheduled daily/weekly maintenance script.

How does it work

Rudolf describes this as follows.
The way I have it set up it is called from a batch file that looks like this:
BTSBackup.exe -config:C:\backups\{yyyy-MM-dd}\config -
envconfig:c:\backups\{yyyy-MM-dd}\envconfig -
apps:C:\backups\{yyyy-MM-dd}\MSI -bind:C:\backups\{yyyy-MM-
dd}\bindings -comp:c:\backups\{yyyy-MM-dd}\comp -
track:c:\backups\{yyyy-MM-dd}\tracking -log
xcopy "C:\Backups" "\\someserver\Off-site-backups" /S /C /Y /R

This makes it possible to 'revert' to a 'point in time' if needed (of course it is

never as easy as just restoring one thing to fully revert but it helps)
Also, if for some reason you have to build a new environment based on an
existing one the files created during this backup gives you everything you need
to set up a duplicate environment.
One thing to watch out for is 3rd party software (like Enterprise libraries,
custom gac'ed assemblies and so on) that might be dependencies of BizTalk
assemblies. These still have to be backed up manually or through another
script.
The tool is simply a command line utility that takes several parameters
depending on what you want to back up. It utilizes both WMI and the BizTalk
ExplorerOM library to do its work. The following items are backed up:
BTSNTSvc.exe.config files (both 32 and 64-bit if present)
Messaging and Pipeline Component directories
Generates a BtsAdminConfiguration.xml file with which hosts, instances,
adapters and handlers can be recreated
Export all current applications to MSIs so they can be restored as needed
Export all current application binding files
Tracking directory custom files (xls, xml, btt etc.)

16
Command line parameters
Usage: BTSBackup.exe [-config:path] [-comp:path] [-envconfig:path]
[-apps:path] [-bind:path] [-track:path] [-log] [-
btsdir:installdir]
Where
config - Back up BTSNTSvc.exe.config files to path
comp - Back up components (pipeline and messaging)
envconfig - Generate BtsAdminConfiguration.xml file to path
apps - Export all application MSI's to path
bind - Export all application binding files to path
track - Back up custom tracking(BAM) related files to path
log - Write outout to log file (BTSBackup.log)
btsdir - Installation directory of BizTalk
Path details
path - May contain macros like {yyyy-MM-dd}
Allowed macros
yyyy-MM-dd
dd-MM-yyyy
MM-dd-yyyy
yyyyMMdd
ddMMyyyy
MMddyyyy

The BizTalk Backup Tool can be downloaded from

biztalkbackup.codeplex.com/

BizTalk Environment Config Loader

This tool is used to automate the configuration of hosts, hosts instances, adapters and
adapter handlers. Rudolf describes this tool as follows.
It can be used in conjunction with the Backup Tool to extract Tracking
Directory Custom Files.
“Using the 'BizTalk environment config loader' with the generated
BtsAdminConfiguration.xml file (Backup tool) you can set up all hosts/host
instances/adapter handlers automatically. These things usually take up a lot of
time to do it manually. Of course you can also manually edit this xml file to
adjust settings/config for the required environment.”
“One huge help is that you can have a bunch of host instances created at once
using the same service account - otherwise you have to manually do it or copy
and paste username and passwords.”

17
 Purpose
When managing multiple BizTalk environments it is often a headache to keep
them in sync. This tool was created to automate the setup of a BizTalk
environment after the initial install and configuration (the normal
configuration wizard provided by Microsoft). This way you can ensure that
development and testing environments are the same as the production
environment.
How does it work
The tool makes use of WMI to create or remove objects in the BizTalk group. It
must run locally on one of the servers of the BizTalk group in question. It takes
an XML file as input that specifies how the environment must be configured.
For host instances you can specify the account and password the service must
run under or alternatively you can specify a default user name and password as
parameters when running the utility.
It can configure the following objects:
Hosts
Host instances
Adapters
Adapter receive handlers
Adapter send handlers
For each type of object you can specify whether to add or remove it. It
processes the XML configuration file by Hosts first, then Host instances and
then Adapters with their send and receive handlers.
Configuration
You specify the settings needed to configure BizTalk within the XML
Configuration File. The following attributes can be used:
Hosts
hostname - Name of the hosts
ntgroupname - User group associated with this host
isdefault - is it the default host? (true/false)
hosttracking - is it a tracking host? (true/false)
authtrusted - trusted host (true/false)
hosttype - type of host (1 - In-Process, 0 - Isolated)
ishost32bitonly - is it a 32-bit only host (true/false)

Host instances
servername - name of the server
hostname - name of the host
18
 username - account under which instance will run (can be left blank if default is
specified)
password - password for the account (can be left blank if default is specified)
startinstance - should the instance be started automatically (true/false)
Adapters
name - name of adapter
type - type description
comment - any comments about the adapter

Receive handler
hostname - host name that will service this handler
Send handler
hostname - host name that will service this handler
The following is a sample configuration file:
<BtsAdminConfiguration>
<Hosts>
<Host hostname="NewHostName" ntgroupname="BizTalk Application
Users" isdefault="false" hosttracking="false"
authtrusted="false" hosttype="1"
ishost32bitonly="True"/>
</Hosts>
<HostInstances>
<HostInstance servername="." hostname="NewHostName"
username="" password="" startinstance="true"/>
</HostInstances>
<Adapters>
<Adapter name="FILE" type="FILE" comment="FILE adapter">
<ReceiveHandler hostname="NewHostName"/>
<SendHandler hostname="NewHostName"/>
</Adapter>
</Adapters>
</BtsAdminConfiguration>

Command line parameters

The tool takes the following parameters:
BiztalkConfigLoader.exe [config file] [-r] [-u:username] [-
p:password]
where

19
 config file : BizTalk XML configuration. Default
BtsAdminConfiguration.xml
-r : Remove previous settings first
-u: : Default username used to run host instances
-p: : default password used to run host instances

The BizTalk Environment Config Loader can be downloaded from

biztalkconfigloader.codeplex.com/

BizTalk Application Comparer

The BizTalk Application Comparer was also developed by Rudolf Henning . He
decribes the tool and how it works.
Purpose
This tool is useful to check if two BizTalk groups are set up similarly - e.g. like
a dev/QA/Prod environment. For this reason it does not check 'bindings' but
rather the installed artifacts. Typically bindings 'should' be different between
environments since you do not want dev to access prod resources and so on.
One pitfall is when developers change BizTalk artifacts without changing the
version numbers of assemblies (some people have known to do this grrr...). For
that you'll need to use a tool like my 'Global Assembly Cache comparison tool'
(http://gaccompare.codeplex.com/) that also check assembly file sizes to
high-light the fact that assemblies are different.

BizTalk tracking exporting and importing utilities

These are a set of simple tools to report on or set tracking options in batches. Rudolf
describes these utililities as follows.
How does it work
If you want to disable tracking globally - like in a production environment, you
can use the following in a batch file:
BTSSetTrackingOptions.exe DisableAllTrackingOptions.xml

The following is an example of DisableAllTrackingOptions.xml:

<trackingoptions>
<application name="*">
<receiveports>
<receiveport name="*">
<tracking>
<remove key="*"></remove>
</tracking>
</receiveport>
</receiveports>
20
<sendports>
<sendport name="*">
<tracking>
<remove key="*"></remove>
</tracking>
</sendport>
</sendports>
<orchestrations>
<orchestration name="*">
<tracking>
<remove key="*"></remove>
</tracking>
</orchestration>
</orchestrations>
<pipelines>
<pipeline name="*">
<tracking>
<remove key="*"></remove>
</tracking>
</pipeline>
</pipelines>
</application>
</trackingoptions>

Similarly you can set up a tracking option xml file to enable/disable just
some/all tracking options so that you can run it at a moment's notice.
The BizTalk Application Comparer Tool can be downloaded from
biztalkappcompare.codeplex.com/

Backing Up IIS 7
Backing up IIS7 configuration is quite simple. We just copy the
\windows\system32\inetsrv\config directory (and subdirectories) into a backup
directory.
IIS 7 provides us with a command line tool, AppCmd.exe
1. To use it we open an Command Prompt
2. We then enter %windir%\system32\inetsrv\appcmd.exe add
backup "My Backup Name" where “My Backup Name” is the name of
your backup.
Alternately, we could automate the process by using a PowerShell Script.
Included with IIS 7 is a feature called IIS 7.0 Configuration History
This tool creates snapshots of our IIS 7 Configuration.

We can read more about its use on Learn.IIS.Net

learn.iis.net/page.aspx/129/using-iis-configuration-
history/

21
System Operations Manager 2007 R2 (SCOM)
If we are using System Operations Manager R2 to monitor our BizTalk Environment, it is
critical to backup our SCOM Environment. This is especially true if we have created a
new Management Pack for your customizations.
We will address these customizations in Chapter 3 – Monitoring
Besides the BizTalk 2010 Management Pack, we could have the following Management
Packs installed:
Microsoft Windows Base Operation System
Microsoft Windows Server Clusters (if clusters are used)
Network Load Balancing
Microsoft Windows IIS
Microsoft SQL Server
Optional: BizTalk Server RFID 2010 Management Pack

How to Backup System Center Operations Manager 2007 R2

Our first step is to plan what to backup. The following diagram shows these steps.

The steps in the diagram are as follows.

1. Our first step is to create an Inventory document.
2. We then need to backup the SCOM databases.
3. Then we backup the IIS 7.0 Configuration.
4. Backing up the Root Management Server Encryption Key is our next
step.
5. We then need to create a list of all our management packs
6. Next, we backup our customized management packs
7. Then we backup our SCOM registry keys
8. Lastly, we backup all our SCOM files.
22
We do not know in advance where a disaster could occur.
Disasters are not limited to our BizTalk 2010 Environment. Because SCOM 2007 R2
plays an important role for monitoring our BizTalk Environments, it is extremely
important that we are able to restore it.
It is critical for us to backup the configuration of the all Management Packs used for
monitoring our BizTalk Environment. In order to insure that this is done properly, we
might need to Backup our entire SCOM Server

Aman Dhally has contributed the following scenario from his blog, “SCOM
Admins” opsmgradmin.blogspot.com/ on Backing Up System Center
Operations Manager 2007 R2. We can read more about Aman in
Appendix B – Scenario contributors.

Aman describes how we handle this in depth.Scenario: Backup SCOM

DatabasesBacking up the SCOM Databases is a task usually handled by the
DBA. There are also situations where the SCOM or BizTalk Administrator will
need to handle this task.
OperationsManager Database
The OperationsManager database contains almost all of the Operations
Manager environment configuration settings, agent information, management
packs with customizations, operations data, and other data required for
Operations Manager to operate properly

If our backup procedure sets the OperationsManager database to be offline

during backup, Operations Manager caches incoming data, and then, after
backup is complete, Operations Manager stores that data in the database

The Reporting Databases

Operations Manager Reporting uses the following databases:
Operations Manager 2007 data warehouse (OperationsManagerDW) - The
OperationsManagerDW database contains all of the performance and other
operational data from your Operations Manager environment
SQL Server Reporting Services databases (ReportServer and
ReportServerTempDB) - SQL Reporting Services then uses this data to
generate reports such as trend analysis and performance tracking

23
 ACS Database - The Audit Collection Services (ACS) database,
OperationsManagerAC, is the central repository for events and security logs
that are collected by ACS forwarders on monitored computers.

The OperationsManagerAC database can grow significantly depending upon

how many ACS forwarders send events to the ACS database and the filters
configured to control what events are written to the database.

Master Database - The master database is a system database, which records

all of the system-level information for a Microsoft SQL Server system, including
the location of the database files. It also records all logon accounts and system
configuration settings. The proper functionality of the master database is key to
the operation of all of the databases in a SQL Server instance.
MSDB Database - The MSDB database, Msdbdata, is a SQL system database,
which is used by the SQL Server agent to schedule jobs and alerts and for
recording operators. The proper functionality of the MSDB database is key to
the operation of all the databases in a SQL Server instance.

Backup Root Management Server Encryption Key

To restore SCOM from scratch we need “RMS Encryption Key”. We must
backup “RMS Encryption Key” and store it in secure locations. The key
should be stored in TFS Source Control.

Create a list of all Management Packs Installed

It is recommended to keep the latest list of all “Management Pack” installed in
SCOM. The list will helps us to download if we need to restore SCOM.
Best Practices is to create a CSV file. The Operations Manager Command Shell has an
operation, “Get-ManagmentPack | Export-csv <path>:\ManagmentPackList-
<date>.csv”, to do this.

Backup of Unsealed (Customized) Management Packs

We take the following steps.
1. Open the “System Center Operations Manager Console” click on
“Monitoring”
2. Click on “Management Packs” and sort the Management Packs by
“Sealed” or “Unsealed”
3. Choose the “Management pack” which we want to export

24
 4. Then right click it and choose “Export management pack”

Backup SCOM Registry Keys

Open Registry Editor and navigate to “My
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
Operations Manager\” and export the whole key.

The Registry Key can be stored in Source Control

Backup SCOM Installation Folder

The last step we want to do is to backup our installation folder

When restoring your folder, make sure we don’t restore the “Health Service
State” folder.

Backing up Business Activity Monitoring (BAM)

The following are the recommended “Best Practices” we should follow for backing up
BAM Analysis and the Tracking Analysis databases.
Best Practices for backing up the BAM Analysis and Tracking Analysis
Databases
Both these databases store content in SQL Server 2008 R2 Analysis Services Cubes. The
Backup BizTalk Server job does not backup these databases. We must use SQL
Analysis Manager for backup
We must first verify that the BAM Cube Process and data maintenance DTS Packages are
running when the backup package is scheduled to run. We must backup the BAM
Database and BAMStarSchema database each time we deploy or undeploy a BAM view
We backup the BAM databases in the following order:
1. We first run the Backup BizTalk Server Job to backup the BAMPrimaryImport
database and our other BizTalk Databases.
2. Next we run the BAM data maintenance DTS package for all activities.
3. Then we backup the BAMAnalysis database.
4. Lastly, we backup the BAMStarSchema database

It’s a good idea to Incorporate these steps into a DTS package, and schedule the
package to run on a regular basis. To ensure data integrity, make sure no other

25
 BAM cubing or data maintenance DTS packages run when this backup package
is scheduled to run

If we are not using SCOM R2 for monitoring the BAM SSIS Packages and SSIS
Logging is enabled, the sysssislog table will be populated with hundreds of records
every time the BAM SSIS package is executed. The growth of this table could have an
adverse effect on performance.
We have two options. We Disable SSIS Package Logging or Implement Circular Logging
in BAM SSIS Packages
These options are described in depth on the following blog post:
blogs.msdn.com/b/asgisv/archive/2010/02/17/best-practices-for-
configuring-bam-data-maintenance-and-cube-update-ssis-packages.aspx

Backup Schedule
It is a Best Practice to implement a Backup Schedule. The following is a schedule of the
backup procedures.
Component
BizTalk configuration files
BAM Portal (IIS configuration)
Schedule Responsible
Resource/Role
Whenever changes occur BizTalk Applications
It is recommended to backup on a Administrator
weekly or monthly schedule
Whenever changes occur BizTalk Applications
Administrator

Application Configuration Files Whenever changes occur BizTalk Applications

Administrator

Password information for Whenever changes occur BizTalk Applications

configuration Administrator

Software Update Log Whenever changes occur BizTalk Applications

Administrator

BizTalk Databases Daily – Logs every 15 minutes Database Administrator

Enterprise Single Sign-On
master secret.
Whenever changes occur Database Administrator
This can occur when you change
the master secret because the
registry has become corrupted or
update the credentials database.

26
Software Update Log Whenever changes occur Database Administrator

System Backup Policies

BizTalk Application Servers should be backed nightly by the System Administrator
(Network Server Group). The backups should be stored offsite to protect against a loss of
facility disaster

Clear Backup History

SQL Server 2008 R2 stores the history of all backups in the MSDB Database. There are
times where older history is no longer required. The following Stored Procedure can be
executed with a parameter(-30) for the days of history we want to retain.
USE msdb
GO
DECLARE @DaysToKeepHistory DATETIME
SET @DaysToKeepHistory = CONVERT(VARCHAR(10), DATEADD(dd, -30,
GETDATE()), 101)
EXEC sp_delete_backuphistory @DaysToKeepHistory
GO

BizTalk Database Servers should be backed up by using a combination of Full and

Transaction Log methods. The “Backup BizTalk Server” SQL Server job is the only
approved way to back up the BizTalk Databases
Database Log Shipping
BizTalk Log Shipping is a feature that simplifies the process of restoring the multiple
BizTalk core databases in case the SQL tier becomes unavailable due to a planned or
unplanned downtime.
A Log Shipping solution depends on having the full backups, backup logs and a SQL
Server instance located offsite. When the Log Shipping SQL Server jobs are running,
they will maintain a backup SQL Server instance by applying the backups and logs in
near real-time (delay in minutes). If a disaster occurs, the admin would need to start a job
that would apply the last log backup to the databases. The BizTalk Servers could be then
repointed to the backup SQL Server Instance, and processing could continue. This is a
“warm failover” method that is suggested as a best practice to use with BizTalk Server. If
log shipping is not used, an admin would need to manually apply the full backups and log
backups in the correct order. This could be a confusing situation because of the 8
different databases and the potential of hundreds of backup files.

Configuring the DR SQL tier for Log Shipping

27
To set up the Log Shipping process, we need to run certain sql scripts on the DR site SQL
Server and modify some configuration files that will be used during the recovery process.
1. In SQL Server Management Studio, connect to the DR site SQL
server instance
2. Open the script file that can be found on the following path on any
server where BizTalk Server 2010 is installed
%SystemDrive%\Program Files\Microsoft BizTalk Server 2010\S
chema\LogShipping_Destination_Schema.sql

3. Run the script. It will drop and recreate the tables that are required to
restore the source databases during the recovery process.
4. Open the script file that can be found on the following path on any
server where BizTalk Server 2010 is installed
%SystemDrive%\Program Files\Microsoft BizTalk Server
2010\Schema\LogShipping_Destination_Logic.sql
5. Run the script. It will create all the logic (stored procedures, etc.) that
will actually handle the Log Shipping process.
6. Configure the Log Shipping logic parameters by running the
following script (replacing replace <MyLogShippingSolution> with
a meaningful description, and
<BizTalkServerManagementDatabaseName> and
<BizTalkServerManagementDatabaseServer> with the name and
location of your source BizTalk Management database):
exec bts_ConfigureBizTalkLogShipping @nvcDescription =
'<MyLogShippingSolution>',
@nvcMgmtDatabaseName =
'<BizTalkServerManagementDatabaseName>',
@nvcMgmtServerName =
'<BizTalkServerManagementDatabaseServer>',
@SourceServerName = null, -- null indicates that this
destination server restores all databases
@fLinkServers = 1 -- 1 automatically links the server to the
management database

7. On any computer running BizTalk Server 2010, we open the

SampleUpdateInfo.xml file located on the following path:
%SystemDrive%\Program Files\Microsoft BizTalk Server
2010\Bins32\Schema\Restore
8. We modify the file, replacing any occurrences instances of
"SourceServer" with the name of the source SQL Server, and then all
occurrences of "DestinationServer" with the name of the DR SQL
Server.

28
 9. Save the SampleUpdateInfo.xml file in a safe location, as it will
be needed during the recovery process.

Documentation
Having current documentation of our BizTalk 2010 Environment is critical. Our
documentation should include the following:
 BizTalk 2010 Enviroment
 BizTalk 2010 Installation
 BizTalk 2010 Server Configuration
 BizTalk Applications
o Orchestration
o Maps
o Pipelines
o Schemas
o Custom components
 Business Rules
 Bam
 Trading Partner configuration
 SSO
 SSO Affiliate Applications
 Custom Databases
 ESB Portal Customization
 UDDI

Third Party Tools

There are several Third Party Tools that can help you create documentation.
1. BizTalk Server 2010 Documenter: biztalk2010autodc.codeplex.com / The
BizTalk 2010 Documenter can automatically generate a compiled CHM
or a MS Word document.
2. The Configuration Management Tool:
www.codeplex.com/ConfigSettingsTool/The Configuration Management
Tool can be used to help you manage configuration settings for different
environments.
3. BizTalk SSO Configuration Data Storage Tool:
www.seroter.com/blogpics/wordpress/Seroter_SSOStorage_App.zip

29
 The BizTalk SSO Configuration Data Storage Tool can be used to store your
secure data. It also allows importing and exporting your Configuration.
4. BizTalk Config Explorer: configexplorer.codeplex.com/ The BizTalk
Configuration Explorer will help automate the creation of your technical
documentation. It does this by extracting your configuration data for the
following artifacts:
 Receive Ports
 Send Ports
 Orchestrations
 Maps
 Schemas
 Pipelines
 Assemblies
5. Environment Settings Manager: http://envsettingsmanager.codeplex.com/ The
Environment Settings Manager uses an Excel spreadsheet and a command-line
export utility to store your configuration data.
6. Collection of Visio 2010 Stencil for BizTalk Server: This is a collection of 37 Visio 2010
shapes for representing BizTalk physical architectures or solutions diagrams in Visio 2010
available on Microsoft TechNet Gallery.
gallery.technet.microsoft.com/Collection-of-Visio-2010-30fcaa43
7. PowerShell/SQL Script: there are many available on TechNet gallery
8. BizTalk Integration Auditing Framework: http://biaf.codeplex.com/ The BizTalk
Integration Auditing Framework will provide you with the ability to Audit your
BizTalk Environment. It uses a SQL Database to store your audit data.
9. Scenarios: When creating the plan, we need to take in the different scenarios that could
affect our environment. Essentially, there are two types of Environments.
 Stand-alone: BizTalk 2010 Standard Edition
 Clustering and Load Balancing: BizTalk 2010 Enterprise
EditionStand-alone Scenario
The Stand-alone scenario is based upon a single BizTalk 2010 Standard Edition Server.
The environment consists of BizTalk 2010 Standard Edition and SQL 2008 R2 Standard
Edition hosted on a physical Windows 2008 R2 Standard Edition Server
The steps provided in the On-site Backup Section apply to this scenario. The only
exception is the location for backing up the BizTalk Databases.
Database Backup Storage Locations
The steps we take are as follows.

30
1. Create new folders to store the Backup and Archives. Preferably this should be
on a UNC Share or a secondary drive.
2. Assuming you have a secondary drive D:\, create a new folder named
“D:\SQLBackUp”.
3. Add three new sub-folders; “Data”, “Logs”, and “Tracking”.
Our folder structure will look like this

Database Jobs Backup Locations

The following jobs will store the backups in the following locations.
SQL Job Storage Location
Backup BizTalk Server D:\SQLBackup\Data
D:\SQLBackup\Logs
DTA Purge and Archive D:\SQLBackUp\Tracking

Clustering & Load Balancing Scenario

The Clustering and Load Balancing scenario is based upon a group of two BizTalk 2010
Enterprise Edition Servers and two SQL 2008 R2 Enterprise Edition Servers in an
Active\Passive Windows 2008 R2 Cluster.
The BizTalk 2010 Servers can be physical or virtual machines. The SQL 2008 R2
Servers are configured as an Active/Passive Cluster hosted on physical Windows 2008
R2 Enterprise servers.
The environment for these scenarios includes the following:
 ESB Toolkit 2.1
 ESB Portal

31
  BAM Portal

Recovering the BizTalk Server Environment

It would be a wonderful world if systems didn’t ever fail, but the fact is that from time to
time they break down, either due to the most obvious reasons (e.g. an electrical power
outage) or the most elaborated disruptive events (e.g. the progressive degradation of the
system caused by a hidden bug on the product). We can design our system for high
availability and be fault tolerant as much as we can (and as much as the budget can
afford), but there will be situations where we will have to apply some procedures to
overcome the situation.
Yes, the bottom line is that we must be prepared for the worst if we want keep our
business moving, and this is what this section is about.

BizTalk Disasters
Microsoft BizTalk Server is a really powerful product, incredibly well architected and
made up of multiple components that work together to fulfill our integrations needs, but
just because of that many things can break down at some point. On the next pages we will
be depicting the main situations where something can go wrong and the techniques and
procedures we can apply to get everything up and running again.
There are two main areas we can identify in BizTalk architecture, the Runtime tier and
the SQL tier. Each of these have their own subcomponents and so there are different
scenarios that we should be ready to confront when any of those pieces fail. The disasters
could vary from a SAN unit where our database files are stored becoming unavailable, to
32
one of our BizTalk runtime servers not being able to start its corresponding host instances
or even the whole environment becoming unavailable due to a network infrastructure
issue.

Though we could design different procedures to address the different disruptions our
system can experience (specific components/services failures), it’s much easier and cost
effective to swap to the Disaster Recovery site during any outage and so have a common
approach well understood by the different teams involved.
During a disaster situation there will be different phases we will go through until our
system is stabilized back to normality, and each of those will require different tasks and
procedures to be executed in order to smoothly transition from one phase to the other.
These phases will range from the moment where the issue is identified, going through the
phase where the Disaster Recovery procedures are applied to reestablish the system
stability as much as possible and finally, in certain scenarios, switching back to the
original state of the system by reverting the Disaster Recovery measures.

Houston, we have a problem

The voice of alert about an outage in our system can come from very different sources:
 A user that finds out that purchase orders are not making their way through to the
ERP system
 A system administrator finding out errors on the server logs

33
  An email alert being sent from our SCOM monitoring system
But before panicking we need to access the impact of the issue and if the situation really
requires the Disaster Recovery measures to take place:
The following diagram shows the steps we need to follow:

On certain disaster situations, we might find that only the throughput of our system could
be slightly impacted (e.g. in high availability architectures, if just one of our BizTalk
runtime servers is impacted, the load will be still handled by the rest of the servers that
are still working), or certain “non business critical” areas might not be available, so there
are good chances that we might not need to go through the whole disaster recovery
process but just fix the issue as needed.
If the disruptive event significantly impacts our system stability or the business processes
it supports, a crisis meeting must be held with the appropriate individuals to agree on the
timeline and actions to take to address the issue. The decision board for that meeting
should be composed by the stakeholder of the teams directly involved in the DR process.
Example roles for the board are:
 Business Users representative
 Architecture team representative
 BizTalk Administrators representative
 Database Administrators team representative
 System Administrators team representative
 BizTalk Development team representative
34
  Network Administrators team representative

Addressing the problem

Once the corresponding crisis meeting has been held, it’s the time to get down to work
and take the corresponding Disaster Recovery procedures that should have been already
documented in the Disaster Recovery plan, including those ad-hoc procedures required
by the singularities of the crisis in place, following the action plan agreed in the crisis
board.
The main point of our disaster recovery process will be providing an alternate
environment where our business processes can continue running, and that one will be our
Disaster Recovery site.

Making the DR site available

Before we can make our business processes execution swap to the Disaster Recovery site,
we must ensure that site is in a state that is consistent with the one the Live site was when
the outage happened. To do so, there are several areas we must ensure to be in sync.
SQL Tier
In order to recover a computer running BizTalk Runtime Server, you must be able to
access the BizTalk Server databases, so this is the tier we first have to take care of when
applying our Disaster Recovery measures.
The SQL tier core BizTalk databases (BAM Primary Import database, BAM Notification
Services Application database, BAM Notification Services Instance database, BizTalk
Tracking database, BizTalk Management database, BizTalk MessageBox database, Rule
Engine database, SSO database) disaster recovery is fully covered by the Log Shipping
procedures mentioned in the Backup section earlier on this chapter. Those will take care
of keeping our DR site SQL tier in sync with our live site at any time, so when there
comes the time to swap to the DR site, we just need to execute some procedures to make
those databases available in the DR site to continue with the environment restore.
The main steps to bring the DR Site databases online by means of the Log Shipping
process are:
1. Disable Log shipping stored procedures: the stored procedures to disable are:
 BTS Log Shipping - Get Backup History
 BTS Log Shipping - Restore Databases
These two stored procedures are the ones that take care of keeping the DR Site
databases in synch with the live site ones, by restoring the corresponding backups
generated by the backup jobs. They need to be disabled before executing the next
step.
35
 2. Restore the databases to a consistent transactional state: “BTS Log Shipping
- Restore to Mark” stored procedure needs to be executed so all the BizTalk
databases are restored to the last consistent transactional state stored in the
backups. This ensures that the databases are brought into an operational state..
Once the databases are available, each BizTalk Server in the DR site should be updated
accordingly to point to the DR Site SQL tier. This will be covered in the Runtime Tier
section later on this chapter.
As we mentioned before, if the Log Shipping jobs fail or were not set up at all, the
backup files will have to be manually restores in the right order. In this case, the contents
of the adm_BackupHistory table in the BizTalkMgmtDb database will help us to know
the right order of the files.

Recover BAM Alerts

To complete this task, we will just need to execute the following command in the
command prompt, taking good care of putting the right server name (the one we just
restored in the SQL tier) and credentials and finally starting the BAM Alerts service:
nscontrol register -name BamAlerts -server <ServerName> -service -serviceusername
"<ServiceUserName>" -servicepassword "<ServicePassword>"

Runtime Tier
This represents the BizTalk servers where messages reception, transmission and
processing take place. We must ensure that all the assemblies, configurations and artifacts
from the live environment are present on the recovery site. Depending on the change
management processes we have in place in our organization, our DR site could be or not
be 100% in sync with the live site, so we should have a checklist in our DR plan to ensure
the DR site is configured as required.

36
Our ability and promptness to be able to do so will heavily rely on the backup and change
management processes we have in place. By following the practices described earlier on
the “Automating the Backup Process” section, it will be easier to ensure our disaster
recovery site is ready to be activated.
The Disaster Recovery plan should include a detailed checklist of the different artifacts
and configuration elements that should be synched between the Live and the DR site.
In any case, there’s a high level list of tasks that should be addressed when restoring a
BizTalk Server runtime server, with slight differences depending on the BizTalk edition
being used:

Task Standard Developer Enterprise

Point to the restored SQL Tier

Restore the Certificate Store X

Recover Enterprise Single Sign-On (SSO) X X X

Recover the BizTalk Group X X X

Recover the BizTalk Server Configuration X X X

Recover BizTalk Applications and artifacts X X X

Recover IIS and the BAM Portal X X X

Not required unless you're using BAM.

Point to the restored SQL tier

We need to make some updates after restoring the SQL tier, so all the servers are aware
of the new server and databases they have to point to.
1. Navigate to the following directory: drive:\Program
Files\Microsoft BizTalk Server 2010\Schema\Restore.

Note

37
 On 64-bit computers, browse to the following folder:
%SystemDrive%\Program Files (x86)\Microsoft BizTalk
Server 2010\Bins32\Schema\Restore.

2. At the command prompt, type:

cscript UpdateDatabase.vbs SampleUpdateInfo.xml

This script updates all tables that store information about the location of other
databases. The location of each database (and its corresponding server) is defined
in the SampleUpdateInfo.xml file that we modified when we configured the
Log Shipping process.

Weonly need to run UpdateDatabase.vbs on one server in the BizTalk

group.

On 64-bit computers, we must run UpdateDatabase.vbs from a 64-bit

command prompt.

38
 If EDI is configured, then navigate to %SystemRoot%\Program
Files\Microsoft BizTalk Server 2010\Schema\Restore and
open the SampleUpdateInfo.xml file for editing. Add the following text in the
<OtherDatabases> section
<Database Name="MsEDIAS2" oldDBName="old dta db name"
oldDBServer="old dta server" newDBName="new dta db name"
newDBServer="new dta server" />.

Save the edited SampleUpdateInfo.xml file.

3. Copy the edited SampleUpdateInfo.xml file to the drive:\Program

Files\Microsoft BizTalk Server 2010\Schema\Restore
directory on every computer running BizTalk Server that is part of the
BizTalk Server group.

On 64-bit computers, browse to the following folder:

%SystemDrive%\Program Files (x86)\Microsoft BizTalk
Server 2010\Bins32\Schema\Restore.

4. On each computer in the BizTalk Server group, open a command prompt

to be run as an administrator.
5. Navigate to the following directory: drive:\Program Files\Microsoft
BizTalk Server 2010\Schema\Restore.

On 64-bit computers, browse to the following folder:

%SystemDrive%\Program Files (x86)\Microsoft BizTalk
Server 2010\Bins32\Schema\Restore.

6. At the command prompt, type:

cscript UpdateRegistry.vbs SampleUpdateInfo.xml
This script updates all registry entries that store information about the location of
other databases.

Note

We need to run UpdateRegistry.vbs on every server in the BizTalk group.

On 64-bit computers, we must run UpdateRegistry.vbs from a 64-bit command

prompt.

39
 7. Restart all of the BizTalk Server services. For more information about
how to restart the BizTalk Server services, see How to Start, Stop, Pause,
Resume, or Restart BizTalk Server Services.
Recover Enterprise Single Sign-On (SSO)
Before starting the process of recovering the SSO:
 We must be logged on as a member of the Single Sign-On Administrators group
and a member of the Administrators group to perform this task.
 We must have the password used to generate the master secret key backup file.
 All databases are intact on the remote server.
 The backup master secret file (generated during the BizTalk Server configuration
process) is intact and stored in a safe place.
1. The steps to actually recover the SSO are: Click on Start| All Programs |
Microsoft BizTalk Server 2010 | BizTalk Server Configuration.
2. In Microsoft BizTalk Server Configuration, in the console tree, click on
Enterprise SSO.
3. In the details pane, select Enable Enterprise Single Sign-On on this computer,
and then click on Join an existing SSO system.
4. In Data stores, enter the name of the SQL server hosting the SSO database and
the name of the SSO database.
5. In Windows service, enter the user name and password for the SSO service
account that you used when you originally installed and configured BizTalk
Server.
6. Click on Apply Configuration.
7. A warning that no master secrets were retrieved is displayed. You can use Event
Viewer to verify that the Enterprise Single Sign-On service is now started and
running on the computer.
8. Click on File | Exit.
9. Click Start | Run, type cmd, and then click on OK.
10. At the command prompt, type:
cd Program Files\Common Files\Enterprise Single Sign-On

11. At the command prompt, type:

ssoconfig -restoreSecret <backupfile>

40
 where <backupfile> is the name of the master secret file that you backed up.
12. When ssoconfig prompts you for the backup file password, enter the password
that was specified during SSO configuration. If the password is correct,
ssoconfig displays the following message:
13. The operation completed successfully

Recover the BizTalk Group

This task is meant to join each of our BizTalk Servers (if multiple) into the BizTalk
Group that we just restored in the SQL Tier. For Enterprise and Developer editions, we
will just need to join the group by doing so in the BizTalk Administration console,
selecting the Connect to existing BizTalk Group in the details pane and then selecting
the corresponding BizTalk Management Database that we just restored.

For the Standard Edition, we will have to restore the server configuration by using the
RestoreConfig.vbs script and the configuration file we should have exported
previously from the Live site BizTalk server “Microsoft BizTalk Server Configuration”
tool.
Recover the BizTalk Server Configuration
We will follow the previous steps to restore BizTalk group. We will have to restore the
BizTalk Server configuration on each remaining BizTalk Server. We need to take good
care of restoring the right exported configuration to the right BizTalk Server just in case
our BizTalk servers play different roles in our architecture.

41
Apart from the BizTalk Server configuration, there are other configurations we must
ensure are in synch with the Live Site. To do so, we will restore our hosts, hosts
instances, adapters and adapter handlers configuration using the
BtsAdminConfiguration.xml file generated with the “BizTalk Backup Tool” during
our regular backup processes.
Any other settings and customizations that our BizTalk servers could have gone through
(BTSNTSvc.exe.config file customization, specific IIS settings…) must be confirmed
and re-applied if needed into our DR site. Depending on the maturity of our Change
Management processes, all those changes might be already in place in our DR site, but in
any case those must be included in our Disaster Recovery procedures checklist mentioned
before, to ensure we don’t find any inconsistencies that could impact our system’s
behavior.
Recover BizTalk Applications and artifacts
We will use the MSI files generated with the “BizTalk Backup Tool” to restore all the
assemblies and artifacts that make up our solution to the version that our live
environment was running when it broke down.
Recover IIS and the BAM Portal
Even If we don’t use BAM in our environment, this step is important as we will be
recovering the whole IIS configuration to have any other web sites our architecture might
be composed of up to date in terms of configuration.

1. Restore IIS configuration by running the following command in the command

prompt (being the command prompt executed as an administrator):
cd %windir%\system32\inetsrv, and then press Enter.
appcmd restore backup “backupname”, and then press Enter

Being the name of the IIS backup we take during our backup processes
2. On each application pool in IIS, set the credentials that each of them must run in
behalf of.
3. Start all the application pools

After the storm comes the calm

Once the crisis situation has been sorted out and our original live environment is up and
running again, we will have to take the appropriate measures to be ready for any future
crisis.

42
We need to define and detail the steps to take in this case and include them within our DR
documentation. A high level script for this process would be:

1. If the DR Site is an exact copy of the Live Site

a. The DR Site becomes the new Live site and vice versa
2. If the DR Site is not an exact copy of the Live Site
a. Synch Live and DR Site (configuration, artifacts, etc.)
b. Disable messages reception on the DR site
c. Enable messages reception on the live site
d. Wait for any in-flight processes to finish on the DR site
3. Reconfigure any DR processes (e.g. Log Shipping) in order to keep
DR and Live sites in synch

The Live and DR sites composition is exactly the same

In those scenarios where both sites are built the same way, our DR site will become our
new Live site and in consequence our previous Live site will become our new DR site. In
order to be ready for any future crisis, we will have to configure and apply all the backup
processes on our new Live site (backups, Log Shipping configuration…), so we are able
to swap to the new DR site when required by following the same processes used in the
past.

The Live and DR sites composition differs

Once our Live site is back online, we will want to swap back to it as soon as possible, to
be able to make use of the whole infrastructure required to match our needs (e.g. our DR
site could be composed of a smaller number of BizTalk servers, less powerful
hardware…).
In order to reduce the impact of this process, during the period the DR site is working, no
new deployments or significant configuration changes should be applied to it,
postponing those until the moment when the Live site is back online and so those can be
applied into it. If any deployments or configuration changes cannot be postponed, we will
have to take those into account when swapping back to the Live site and so apply them
again into it.
Once we want to swap back to the live site, we will just need to apply the Log Shipping
and Database restore procedures to resynch the Live site and then bring it back online.

43
Summary
In this chapter, we have learned about the Roles and Steps it takes to Backup and Restore
our BizTalk 2010 Server Environment. We also learned about the use of Team
Foundation Server 2010 Source Control as our On-Site Backup Repository.
We were introduced to several third party tools that can help us automate our Backup and
Restore Process. And, we discovered the importance of backing up System Operations
Manager 2007 R2.
We also went through all the main processes that we will have to execute in case our Live
environment suffers any kind of disruptive event requiring us to swap to the Disaster
Recovery environment.
In the next chapter we will learn how to take advantage of the features BizTalk Server
provides to implement High Availability and make our environment resilient enough to
continue running in the event of a downtime.

44