Network Appliance, a pioneer and

TECHNICAL

industry leader in data storage technology,

REPORT

helps organizations understand and meet

complex technical challenges with
advanced storage solutions and global
data management strategies.
SnapManager® for Microsoft® Exchange

John Phillips and Adrian Simays, Network Appliance Inc. | 8/2003 | TR 3233
Best Practices

Network Appliance Inc.

TECHNICAL REPORT

1
TECHNICAL REPORT

Table of Contents

1 Introduction 3

2 Exchange and Filer Design 4

3 Preparing the Exchange Host (Windows Server) and Filer 8

4 Installing Network Appliance SnapDrive Software 9

5 Creating and Managing Virtual Disks with SnapDrive GUI 12

6 Installing and Configuring Network Appliance SnapManager for Exchange 13

7 Snapshot 15

8 Backing Up and Restoring Exchange with SnapManager 17

9 Using SnapManager for Exchange with Network Appliance SnapMirror 23

10 Management Tools 26

11 Summary 29

12 Ethernet and FCP Technology Diagrams 30

13 Additional Resources 31

Network Appliance Inc.

2
TECHNICAL REPORT

1) Introduction
This paper is intended to be a best practice guide and is for experienced Microsoft Exchange
administrators who have read the Network Appliance™ SnapDrive™ and SnapManager for Exchange
installation and administration guides. Readers of this best practice guide should have a solid
understanding of the Exchange storage architecture and Exchange administration, as well as Exchange
backup and restore concepts. The recommendations found in this document are best practices to
assist with the design and configuration of SnapManager for Exchange in Windows® 2000 and
Windows 2003 environments with Microsoft Exchange 2000 and Microsoft Exchange 2003.

Note: Both the SnapDrive and SnapManager for Exchange installation and administration guides can
be found at http://now.netapp.com (username and password required).

Factors That Affect Exchange Scalability

Microsoft Exchange is considered a mission-critical application by small and large companies alike. If
employees are not able to send and receive e-mail, access their calendars, or retrieve contact
information, it can be disruptive and costly to businesses.

In order to design and implement highly available Exchange architectures, system managers must look
well beyond the availability of their server hardware. Exchange server scalability is often limited by how
long it takes to back up and restore data rather than by server performance.

Exchange databases can grow rapidly in size while storing e-mail, rich media, calendaring, and contact
and workgroup information. As the databases grow larger, it becomes increasingly difficult to complete
time-consuming tape backup operations in a reasonable amount of time. In the case of an outage it can
take days to restore service, assuming all of the backup tapes are available and error-free.

If a virus or software error renders a particular database inaccessible, all of the users whose mailboxes
exist within that database cannot access their data. The range of outages can be anywhere from a few
hours to several days or even a week or more. To improve data availability, administrators must strive
to balance server scalability and manageability by imposing mailbox limits and by limiting the number of
users per server or storage group.

Network Appliance SnapManager 3.0 for Exchange

Network Appliance SnapManager for Microsoft Exchange enables Microsoft Exchange to leverage the
many powerful and specialized features inherent in Network Appliance storage technology.

Benefits at a glance:

Quickly back up and restore Exchange storage groups and databases using Network Appliance
Snapshot™ technology

The Network Appliance SnapDrive Microsoft Management Console (MMC) application provides
an easy-to-use graphical interface to simplify the management of NetApp disk, storage, and
Snapshot resources

Network Appliance Inc.

3
TECHNICAL REPORT

Full integration with the Microsoft Volume Shadow copy Services (VSS) snapshot API
architecture when running Exchange 2003 on Windows Server 2003

Greater data consolidation and scalability for Exchange servers

Network Appliance storage technology offers industry-leading performance

Exchange data stored in Snapshot copies can be automatically mirrored to one or more
locations for archival or disaster recovery purposes

Exchange servers are able to serve more data and are easier to scale and manage

Flexible pools of storage can provide storage resources for multiple Exchange servers, and
capacity can be added on-the-fly without downtime as storage needs grow
The ability to quickly back up and restore online Exchange data in Snapshot copies is the primary
purpose of SnapManager for Microsoft Exchange. SME dramatically reduces the time it takes to back
up and recover Exchange data from online Snapshot files.

2) Exchange and Filer Design

Planning Exchange and Filer Use
There are many factors to consider when designing a Microsoft Exchange environment on a Network
Appliance filer. Important factors include volume sizing for Exchange data and transaction logs, which
include the number of disks per storage volume and the placement of critical Exchange files.

First, LUNs (disks) must be provisioned by the filer for use by the Exchange server(s). The process in
which LUNs are created and mounted by the Exchange server is summarized below:

1. A volume, or collection of physical disks, is created on the filer

2. LUN objects, which are created by using SnapDrive, are created on LUN-dedicated filer
volumes*

3. LUNs are mounted by the Exchange server and appear as “disks” with drive letters, etc.

4. Exchange data is moved to or created on the LUNs as configured by SnapManager for

Exchange

*If file access (network shares) is required for home directories, etc., a separate volume should be
created for that purpose. To ensure optimum LUN performance, volumes created for LUNs should not
be used for other purposes.

Calculating Exchange Database Size

To ensure that you create volumes that meet the Exchange database requirements, you must calculate
the potential size of your virtual disks.

The following formula can help you calculate your Exchange database size:

Network Appliance Inc.

4
TECHNICAL REPORT

DB size = ((number of mailboxes * mailbox quota) / single instance sharing ratio) + deleted item cache

Where:

The single instance ratio can be found through a performance monitor counter under
MSExchangeIS Private. In the following example it is calculated to be 1.5.

The deleted item cache is 20% (calculated by multiplying by 1.20).

For 1000 users with 100MB, mailbox quota (((1000 * 100MB) / 1.5) * 1.2) = 8000MB, or about 80GB

Applying this result for future growth, assuming the Exchange environment will grow by 10% annually
over the course of three years (for illustration purposes only), add an additional 24GB ((80GB * .10) *
3).

Calculating Exchange Transaction Log Size

How much disk space is required for your Exchange database transaction logs can be calculated by
estimating the number of transaction logs that are generated on your server. To estimate how many
transaction logs are generated, note the number of transaction logs that accumulate in the transaction
log directory immediately before a backup. Use that number to estimate how much disk space you
need (you should do this over a period of several days and use the maximum number).

The following formula works best for calculating virtual disk size required for a transaction log drive:

Virtual disk size = ((number of transaction logs generated per day * 5MB) * (number of Snapshot copies
to keep online + 1 for the active file system))

Where:

Each transaction log is 5MB (after a log file is filled, a new 5MB log file is created)

If a server generates 200 transaction logs in one day, then there is about 1GB of transaction logs at the
end of the day (200 * 5MB = 1GB). If the plan is to keep five days of SnapManager backups online at
the same time, then:

((200 * 5MB) * (5 + 1)) = 6000MB, or about 6GB.

Note: If storing transaction logs from multiple storage groups on the same virtual disk, then apply this
formula to each set of transaction log files and combine the total of each transaction log set to estimate
a virtual disk size.

Snapshot Management
When sizing virtual disks for Microsoft Exchange, consider the number of Snapshot copies that will be
created and the length of time they will be kept. Disk space consumed by a Snapshot backup consists
only of the blocks that have changed since the last one was created.

For example, a 100GB store has a Snapshot copy created at midnight. If between midnight and noon
the following day, 500MB of data was added to, changed in, or deleted from the information store data

Network Appliance Inc.

5
TECHNICAL REPORT

files, the copy would consume only 500MB.

However, if that same 100GB store Snapshot copy was kept for 20 days and experienced the same
rate of data change during that period, the Snapshot copy would now consume 10GB (500MB * 20
days). Properly managing Snapshot requires balancing the number of copies and the length of time
they are kept.

Space Reservation
As part of the space reservation feature, WAFL® reserves blocks equal to two times the specified size
of the LUN being created. If a volume of 80GB is being created with a planned growth rate of an
additional 24GB, enough spindles to accommodate 208GB ((80 + 24) * 2) will be required. Space
reservation is designed to guarantee writes for virtual disks. More information on space reservations
can be found later in this document.

Migration Impact
Migrations are another factor that can influence available disk space. When migrating from an existing
mail system to Microsoft Exchange, single-instance store features are unavailable. Single-instance
store provides pointers to a single mail message, so one 100kB e-mail sent to 50 people in the mail
system will require 100kB of space (Exchange 2000 supports single-instance store per storage group).
Since single-instance stores cannot be retained during a migration, 50 instances of the 100kB e-mail
will require 5MB of space. Once the migration is complete, new e-mails received in Exchange will be
stored using the single-instance store. (Even during Microsoft Exchange 5.5 to Microsoft Exchange
2000 upgrades you may require up to 30% more disks during the migration process. Be prepared to
design the volumes with enough free space to accommodate the migration, even if this space is
unused once the migration is complete.)

Volume Sizing Recap

Following the examples provided in this section, one could estimate the volume size for the storage
group volume to be:

Exchange storage group 80GB

Future growth accommodation 24GB

Maximum storage group size 104GB

Snapshot copies 10GB

Space reservation 104GB

Total volume size 218GB*

* This number represents a single storage group containing 1,000 users with 100MB per mailbox.

Network Appliance Inc.

6
TECHNICAL REPORT

Following the examples provided in this section, one could estimate the volume size for the transaction
log volume to be:

Transaction log Snapshot copy 6GB

Daily Exchange transaction logs 500MB

Space reservation 6.5GB

Total volume size 13GB*

* This number represents transaction logs for a single storage group.

Remember, there may be times when the number of mailboxes or the size of the public folders
sporadically grows on an Exchange server and thus requires additional free disk space. Having extra
free disk space on hand avoids emergency administrator intervention.

Unlike traditional storage systems, NetApp filers allow disks to be added on-the-fly on an as-needed
basis as storage needs grow.

Exchange File Placement

Designing the placement of Exchange files will be critical to the overall performance and the protection
of critical Exchange data. When configuring Microsoft Exchange in an SME environment, the following
Exchange files should be stored on LUNs:

Exchange storage groups containing private and public databases

Exchange transaction logs

Exchange SMTP files (for high-volume environments)

When configuring SnapManager for Exchange, it is important to place the Exchange databases and the
Exchange transaction log files on separate volumes. This is recommended for both recovery and
performance. If the databases and log files are stored on the same volume and a catastrophic failure
occurs to the disks in that volume, all Exchange data will be affected. For optimal performance,
separate LUNs should be used for each storage group.

The databases within a given storage group must reside on a dedicated LUN. All databases within a
storage group are backed up and restored together. Restoring an individual database within a storage
group is not possible unless that database (priv.edb, for example) resides on its own dedicated LUN.
However, the transaction logs from different storage groups can share a LUN.

Exchange SMTP Mailroot Directories

For high-volume Exchange environments, performance can be improved by placing the Exchange

Network Appliance Inc.

7
TECHNICAL REPORT

SMTP Mailroot directories on a dedicated volume. When messages arrive at the Exchange 2003 server
through the SMTP service, the data is written to the hard disk as an .eml file. By default, these files are
stored locally on the Exchange server. The SMTP Mailroot directories include:

msExchSmtpBadMailDirectory

msExchSmtpPickupDirectory

msExchSmtpQueueDirectory
Moving these directories requires editing Active Directory; administrators must use caution when
performing this action. More information can be found in Microsoft's Knowledge Base Article 318230.

MSCS Quorum Disk Requirement

If the deployment will use the filer as a quorum device, another LUN will need to be created in addition
to those created for the Exchange database and transaction log LUNs. Microsoft recommends that
Exchange virtual servers not own the quorum device. Create an additional two-disk volume with a LUN
dedicated for the quorum resource.

For more information on MSCS clusters and Exchange, please see the Additional Resources section at
the end of this paper.

Multiple Virtual Disks per Volume in Exchange

Although SnapDrive and Data ONTAPTM support multiple virtual disks per volume, disaster recovery
and performance should be considered before implementing. Multiple LUNs stored on the same volume
could result in data loss for an entire Exchange organization. If the Exchange database and transaction
log files are stored on the same volume and the volume becomes unavailable, archived Snapshot
backups will be the only way to restore the Exchange environment.

Another consideration when storing multiple LUNs on the same filer volume is performance. Avoid
placing heavily used storage groups on the same volume. Filer volumes used for Exchange should
never be shared with non-Exchange data.

Remember, Exchange databases and Exchange log files should never be stored on the same volume.

3) Preparing the Exchange Host (Windows Server) and Filer

There are several things that need to be done to prepare a filer and the Exchange host for optimal
performance and to eliminate the possibility of error. Refer to the latest SnapDrive and SnapManager
for Exchange administration guides to ensure the proper licenses and options are enabled on the filer.

Filer Requirements

Data ONTAP 6.5 or above and SnapDrive 3.0; for current Data ONTAP requirements please
visit http://now.netapp.com

FCP, iSCSI, SnapRestore®, and SnapMirror® (if SnapMirror is used) licenses must be enabled

Network Appliance Inc.

8
TECHNICAL REPORT

A qualified Gigabit or Fibre Channel host bus adapter (HBA) target card for use with iSCSI or
FCP

4) Installing Network Appliance SnapDrive Software

SnapDrive interfaces directly with Network Appliance filers and the Microsoft Windows Server volume
manager to facilitate the management of virtual disks provisioned on NetApp storage.

Network Appliance SnapDrive software is composed of a Win32 service, a Microsoft Management

Console (MMC) Windows management application, and the device drivers for iSCSI and FCP.

SnapDrive provides a layer of abstraction and a consistent, transparent interface between Network
Appliance filers and Windows applications. The Fibre Channel protocol (FCP) and iSCSI resources that
are managed by SnapDrive appear to the Windows host server and its applications as locally attached
disks.

In addition to providing a management interface and presenting NetApp LUNs to the Windows
operating system as basic disks, SnapDrive is capable of managing all of the functions related to
Snapshot copies.

Prior to launching the installation of SnapDrive, use the following checklist to help eliminate the
potential for errors or delays during or after the installation.

Resolve any hardware, cabling, or network issues or other errors.

Make sure all of the necessary software and printed or electronic documentation (found on
http://now.netapp.com) are organized and nearby before beginning.

Configure DNS, host name, and IP address–related services:

o Verify that all related systems, including filers, Exchange servers, and clients, are
configured to use an appropriately configured DNS server (for more information, see
TR 3124 at www.netapp.com/tech_library/3124.html).

o Manually add the filers' host names to DNS.

o Enable, configure, and test RSH access on the filer(s) for administrative access (for
more information, see the Data ONTAP product documentation).

License all of the necessary protocols and software on the filer.

Configure the filer(s) to join the Windows 2000 or Windows 2003 Active Directory domain by
using the FilerView® administration tool or by running filer> cifs setup on the console (for more
information, see Chapter 3 of the Data ONTAP 6.5 File Access Management Guide).

Network Appliance Inc.

9
TECHNICAL REPORT

Make sure the filers' date and time are synchronized with the Active Directory domain
controllers. This is necessary for Kerberos authentication. A time difference greater than five
minutes will result in failed authentication attempts.

Verify that all of the service packs and hot fixes are applied to the Microsoft Windows and
Microsoft Exchange servers.
SnapDrive Installation Tips
Prior to installing the SnapDrive application, the iSCSI or Fibre Channel HBA drivers must be installed.
The SnapDrive installation wizard provides an option to install the drivers before proceeding with the
installation.

Note:

Do not proceed with the SnapDrive 3.x installation until the iSCSI or HBA drivers are installed
and the host rebooted.

When using FCP, it is not necessary to install the iSCSI drivers.

Figure 1) SnapDrive installation wizard

Network Appliance Inc.

10
TECHNICAL REPORT

Figure 2) SnapDrive service account

Once the device driver is installed, select the same account used by the Microsoft Exchange services
when selecting the service account for the SnapDrive and SnapManager for Microsoft Exchange
services.

When creating or configuring the properties for the domain service account, select the “Password never
expires” checkbox. Doing so protects the account and service from failing due to user password
policies.

Reminder: It's important to make certain the service account has the following permissions:

Read and write or full control access to the locations on the filer in which LUNs will be created
(likely if it's already a member of the administrator's group).

RSH access to the filer(s). For more information on configuring RSH, see the Data ONTAP
Administration Guide.

Network Appliance Inc.

11
TECHNICAL REPORT

Microsoft Volume Shadow Copy Services (VSS) and SME 3.0

When using SnapManager for Microsoft Exchange in conjunction with Microsoft Exchange 2003 and
Windows Server 2003; the NetApp VSS Hardware Provider must be installed. Customers may
download the NetApp VSS Hardware Provider software from http://now.netapp.com. For more specific
information and system requirements on installing SnapManager for Microsoft Exchange, see Chapter
2 of the SnapManager for Microsoft Exchange Installation and Administration Guide.

SnapManager for Microsoft Exchange is integrated with the VSS architecture in Windows Server 2003
and Exchange Server 2003. The following chart describes where SnapManager for Exchange and
NetApp storage fit into the VSS framework.

SnapManager for Exchange and the VSS Architecture

Volume Shadow Copy Service

Windows Server 2003

VSS Requestor
NetApp SnapManager for Microsoft Exchange

VSS Writer
Exchange Server 2003

VSS Hardware Provider

NetApp FAS200, FAS800 series, FAS900 series filers

5) Creating and Managing Virtual Disks with the SnapDrive GUI

Once installed, SnapDrive can be used to create LUNs on Network Appliance filers for use by Windows
2003 and Windows 2000 hosts.

The process of creating a LUN is virtually the same, and there is no distinction at the host application
level. LUNs are virtual disks on the filer that are accessed over either TCP/IP (for iSCSI) or Fibre
Channel (for FCP) disk access protocols.

General Tips for Creating LUNs:

When specifying a UNC path to the volume or qtree to create a LUN, use IP addresses instead
of host names. This is particularly important with iSCSI, as host-to-IP name resolution issues
can interfere with the locating and mounting of iSCSI LUNs during the boot process.

Always use SnapDrive to create LUNs for use with Windows to avoid the complexities inherent
in Fibre Channel.

Calculate disk space requirements to allow for data growth, Snapshot copies, and space
reservations.

Network Appliance Inc.

12
TECHNICAL REPORT

Leave automatic Snapshot scheduling off as configured by SnapDrive. To turn off automatic
Snapshot activities, use FilerView or the following example command:

filer> vol options voldata1 nosnap on

Figure 3) Specifying a virtual disk path

Important Tips for Using Fibre Channel:

Verify that all of the hardware and software meets the supported system requirements. The
latest hardware and software requirements for filer platforms, host platforms, Fibre Channel
switches, and third-party software are available on the NOW™ Web site. Log onto the NOW
Web site at http://now.netapp.com and view the SAN support matrix for the latest information
and updates.

For more information on configuring Fibre Channel between Windows hosts and filers, please
see the Host Bus Adapter Installation and Setup Guide for Fibre Channel Protocol on Windows.

6) Installing and Configuring Network Appliance SnapManager 3.0 for Exchange

General Info
After following the steps outlined in the SnapDrive 3.x Installation Guide and as listed in the previous
sections of this paper, proceed with the installation of SnapManager for Exchange. The SnapManager
for Exchange program is a powerful tool that allows for moving the Exchange database and log files as
well as controlling backup schedules and managing Snapshot. It is important to protect access to SME,
since the altering of Exchange settings could produce undesirable results.

Network Appliance Inc.

13
TECHNICAL REPORT

Esefile
Microsoft's esefile utility verifies the page-level integrity of the Exchange databases and is required by
SME. Esefile can be found on the Microsoft Exchange server/service pack CD located under
Support\Utils\i386 (since the esefile utility is updated with service pack releases, you must manually
copy this utility from the latest Exchange service pack).

Upon first use of SME, the user is prompted to specify the location of the esefile.exe utility. While it is
possible to cancel this request, it will appear during every use of the management console until
configured. If page file verification is not run during the backup process, it will be required prior to a
restore.

SnapManager 3.0 for Microsoft Exchange in a Cluster Environment

When configuring a cluster environment, it is critical to install SME on both nodes of the cluster. In the
event the first node in the cluster becomes unavailable, the SnapManager functions can immediately
be performed on the second node without waiting.

Installing SnapManager for Exchange on the cluster nodes is the last step when configuring a clustered
Exchange environment.

1. On the first node of the cluster, install SME and use the configuration wizard to move the
Exchange data paths to the LUN resource locations.

2. Create a Snapshot backup of the Exchange environment after the installation and configuration
are complete on the first node.

3. After a successful backup, fail the cluster to the second node in the cluster and ensure the
Exchange services work as expected.

4. Install SME on the second node of the cluster and run the configuration wizard to update the
database locations on the server.

5. Create another Snapshot copy of the data to ensure backups work from both nodes of the
cluster.

Upgrading from Exchange 5.5

During the upgrade from Exchange 5.5, the SnapManager for Exchange 5.5 program cannot be
upgraded to the latest version of SnapManager for Exchange. If SnapManager for Exchange 5.5 exists,
it must be uninstalled before SnapManager for Exchange 2000 can be installed.

The full Exchange migration guide and upgrade steps can be found at http://now.netapp.com.

An important step prior to migrating databases to Exchange 2000 or Exchange 2003 is to run the
esefile (eseutil for Exchange 2003) utility on the Exchange 5.5 database. Esefile will check the
consistency of the data to ensure there are no problems with the data prior to migration. If the esefile

Network Appliance Inc.

14
TECHNICAL REPORT

utility is not run against the database and an Exchange upgrade fails, the entire environment must be
rolled back to an Exchange 5.5 environment before recovering to a recent Snapshot backup.

7) Snapshot
It is beyond the scope of this paper to explore Snapshot in great detail. However, it is necessary to
understand the fundamentals of the unique Network Appliance Snapshot functionality and how it
relates to Microsoft Exchange.

Network Appliance Snapshot backups occur in a matter of seconds, and each consumes only the
amount of disk space that has changed since the last Snapshot copy was created. Thus they consume
minimal disk space while providing up to 255 online point-in-time images using Data ONTAP 6.4. The
amount of disk space consumed by an individual Snapshot copy is determined by two factors:

The rate data changes within the file system (in MB/sec or MB/hour, for example)

The amount of time that elapses between creation of Snapshot copies

The measure of change (in megabytes, gigabytes, etc.) that occurs in the file system between creation
of Snapshot copies is called the delta. The total amount of disk space required by a given Snapshot
copy equals the delta changes in the file system and a small amount of Snapshot metadata.1

For more information on Snapshot technology and Snapshot internals, see TR 3043, SnapMirror and
SnapRestore: Advances in Snapshot Technology (www.netapp.com/tech_library/3043.html).

Snapshot Copies Created by SnapManager for Exchange

When SnapManager for Exchange creates Snapshot backups, it names them according to the server
name, date, and time. The one exception is the most recent Snapshot copy, which ends with "recent"
instead of a date and time. When another Snapshot backup occurs, it assumes the "recent" name, and
the former one is renamed to reflect its original date and time.

Exchange Database Snapshot

exchsnap__tmlssrv1__recent 1% ( 1%) 0% ( 0%) Jan 30 03:54
exchsnap__tmlssrv1_01-30-2003_03.43.15 2% ( 1%) 0% ( 0%) Jan 30 03:39
exchsnap__tmlssrv1_01-30-2003_03.31.34 3% ( 2%) 0% ( 0%) Jan 30 03:27
exchsnap__tmlssrv1_01-30-2003_03.18.29 14% (11%) 0% ( 0%) Jan 30 03:14

Transaction Log Snapshot

eloginfo__tmlssrv1__recent 0% ( 0%) 0% ( 0%) Jan 30 03:54
eloginfo__tmlssrv1_01-30-2003_03.43.15 7% ( 7%) 0% ( 0%) Jan 30 03:39
eloginfo__tmlssrv1_01-30-2003_03.31.34 11% ( 5%) 0% ( 0%) Jan 30 03:28
eloginfo__tmlssrv1_01-30-2003_03.18.29 15% ( 4%) 0% ( 0%) Jan 30 03:14

Mounting Snapshot Copies of LUNs for Write Access

Snapshot backups of the Exchange storage group databases are read-only point-in-time images. This
protects the data and guarantees the integrity of the Snapshot backups. In certain situations an
administrator may require read/write access to the storage group in a Snapshot copy to build a
recovery or other server for testing purposes. In this case write access rather than the need to actually

Network Appliance Inc.

15
TECHNICAL REPORT

write data is required. This is because Microsoft Exchange must be able to update the database
headers in order to mount them.

LUNs in Snapshot can be mounted for write access by using the Connect Disk function within
SnapDrive to connect to a LUN in a Snapshot copy.

Figure 4) Mounting a Snapshot backup from within SnapDrive.*

Special virtual disk files with an .rws extension are created when connecting to a LUN to facilitate this
purpose. Instead of taking the time to copy the Snapshot data into the active file system, the .rws file is
linked to the original Snapshot data. Therefore read requests are read from the Snapshot data, and
writes are written to the .rws file. When the read/write Snapshot copy is no longer required and
SnapDrive is used to disconnect from the (rws) virtual disk, the .rws file is deleted along with any writes
that occurred to the .rws file. Therefore the source Snapshot copy is not modified.

Issues When Mounting the "Recent" Snapshot Copy

The latest Snapshot backup is always the exchsnap__servername__recent Snapshot copy. This can
be confusing if the former Snapshot backup was mounted while it was named as the "recent" Snapshot
copy. In this example, the mounted version of the formerly "recent" Snapshot copy will continue to be
labeled as such as long as it's mounted. This is true even though it is no longer the actual most recent
copy and has been renamed to reflect the date and time it was created. The change is not reflected in
the active mount.

Network Appliance Inc.

16
TECHNICAL REPORT

Disk Space Consumed by Read/Write Snapshot Copies

Even though read/write Snapshot files are initially linked to the existing blocks in the Snapshot copy, it
is necessary for the filer to allocate blocks equal to the entire size of the file should it be completely
overwritten and a copy of it created. There must be enough available disk space to accommodate the
entire size of the original LUN while the read/write Snapshot copy is mounted. The space consumed by
the read/write Snapshot copy is marked as free disk space when it is dismounted using the Disconnect
Disk command within SnapDrive.

Note: Though technically possible, it is not recommended to create duplicates of read/write Snapshot
copies (.rws files) unless absolutely necessary.

Space Reservation
Space reservation is designed to ensure that protected files (or files that have space reservation turned
on) always have the free space they expect and so that a Snapshot copy of the LUN can complete
even if 100% of its blocks have changed.

Data ONTAP 6.3x only allowed space reservation to be turned on or off at the volume level. Data
ONTAP 6.4 provides for space reservation at the qtree and file levels. Any file may be designated as
protected, but it is turned on by default for LUNs. The rest of this section will discuss space reservation
as it exists in Data ONTAP.

When creating a virtual disk, the filer verifies there is enough available disk space to accommodate the
specified size. By default, WAFL reserves blocks equal to two times the specified size of the LUN so
that all future writes can complete. If space reservation was not enabled, it would be possible to
oversubscribe the available storage. If this occurred, Exchange could unexpectedly run out of disk
space while trying to complete writes to one of its database files.

On each filer volume, reserved space equal to the amount of protected space for all virtual disks (and
any protected files) is set aside. The amount of reserved space is dynamic and can vary if protected
files are added, deleted, etc. If the available disk space runs low, writes to unreserved files and the
creation of Snapshot backups are restricted in favor of completing writes to protected files.

Databases in particular do not react well to surprises stemming from failed file system writes. Microsoft
Exchange somewhat anticipates the possibility of running out of space by its use of reserve logs, but
reserve log files are only designed to capture a very small amount of data required to shut down a
storage group in a consistent state.

Note: SnapDrive requires that all LUNs have space reservation enabled. Disabling space reservation
for a LUN is not supported with SnapDrive.

8) Backing Up and Restoring Exchange with SnapManager

Recommended Settings
Configuring a backup schedule for Exchange data will vary from site to site based on the requirements
of the organization. Proper scheduling of SnapManager backups requires consideration of the tape
archival solution's backup speed. SnapManager backups can be completed much more quickly than
tape solutions if esefile verification is not conducted. This capability may tempt Exchange

Network Appliance Inc.

17
TECHNICAL REPORT

administrators into scheduling SnapManager backups in frequencies as often as hourly. While this
strategy would provide quick recovery times due to the minimal amount of transaction replay during a
restore, there is a catch. Keep in mind that only esefile-verified SnapManager backups can be archived
to tape. Remember, esefile verification will impact the Exchange server's CPU and should be run from
a server other than the production Exchange server.

The best strategy for SnapManager and tape archive schedules is to consider the tape backup strategy
required to meet SLAs, the desired total number of SnapManager backups per day, Exchange client
activity schedules, and the total time required to complete esefile verification. Then devise a schedule
that allows for esefile verification to complete and does not encroach on the time necessary to
complete a tape archive.

For example:

Tape archives of the Exchange server desired: 1 per day

Tape archive time: 2 hours

SnapManager backups per day desired: 4 (7 a.m., noon, 8 p.m., 11 p.m.)

Total storage group size: 100GB

With this data, esefile verification will take approximately 50 minutes (100GB/2GB/min for esefile
verification). SnapManager backups should not be conducted while tape archives are being completed,
so the total time increment required between Snapshot operations is approximately two hours and 50
minutes (50 minutes for esefile verification plus 120 minutes for tape archiving to complete). Since only
four SnapManager backups are required per day, they can be evenly spaced out every six hours
without conflicting with the two-hour-and-50-minute tape archival process. The SnapManager backups
can also be strategically scheduled to occur at times of lighter Exchange usage: 7 a.m. is before the
main logon period of 9 a.m., noon is during lunch, 8 p.m. is after most people go home, and 11 p.m. is
the backup that will be archived to tape.

This strategy relies on the esefile verification speed and the time it takes to complete a tape archive.
Esefile verification times vary from one environment to another. In order to accurately predict esefile
verification speed, create a SnapManager backup of an Exchange 2000 server, mount the storage
group LUNs, and then time the esefile procedure against the database files (both .EDB and .STM). This
will allow accurate prediction of esefile speeds in your environment. Tape archival speeds usually can
be retrieved from tape software backup logs.

Storage Group Sets

A storage group set is one or more Exchange storage groups that belong to the same Exchange server
and are stored on the same filer volume. When one storage group on a volume is selected to be
backed up, all the others on that volume are automatically preselected.

A volume containing a storage group set to be backed up can also contain Exchange storage groups
belonging to other servers. These storage groups constitute their own storage group sets, depending

Network Appliance Inc.

18
TECHNICAL REPORT

on the Exchange server they belong to. To create a recoverable backup of the storage group, you must
use the SnapManager backup feature and explicitly configure that storage group as the backup target
to the Exchange server it belongs to.

SnapInfo Directories
The SnapInfo directory contains the information about each storage group backup set created by a
SnapManager backup. A subdirectory under the SnapInfo directory is created for each backup set and
contains the transaction logs backed up as part of that Snapshot operation as well as the recovery
information for that specific Snapshot duplicate. Every time a SnapManager backup is created, a new
backup set subdirectory is created under the SnapInfo directory and is populated with the appropriate
information and data. A complete backup set consists of this SnapInfo subdirectory and the
corresponding backup of the virtual disk drive that stores the Microsoft Exchange databases.

Note: The SnapInfo directory can be found on the virtual disk configured for the transaction logs. Do
not attempt to delete or move any of the files or folders found in the SnapInfo directory.

Tape Archive
The combination of SnapManager for Exchange and tape archives of SnapManager backup sets
provides a solid disaster recovery solution for Microsoft Exchange information store data. Please keep
in mind that information store data is only one piece of a complete Exchange disaster recovery plan. A
complete disaster recovery backup strategy must also include system-level backups of the Exchange
server as well as Active Directory domain controllers in the domain running Microsoft Exchange.

The recommended strategy for archiving SnapManager for Exchange backups requires two different
backup operations.

1. The first operation utilizes NDMP or dump for the storage group database Snapshot copies.
This will ensure the complete archive of the Snapshot backup containing the storage group
databases.

2. The second operation should use a CIFS-based or local backup of the LUN where the
transaction logs and SnapInfo directory are located. The archives should be generated off of
the most recent verified backup set of the entire Exchange server, ensuring all storage groups
and their associated log files are properly archived under the most recent Snapshot name.
NetApp recommends that the transaction log backup operation occur chronologically first, followed by
the database volume backup. This order of operations will reduce the amount of time when a tape
backup and a SnapManager backup may conflict due to the renaming of transaction log directories.

Archiving single storage groups from SnapManager backups is not recommended. This task requires a
full understanding of the Snapshot naming conventions used by SnapManager for Exchange and
should not be attempted without knowing which Snapshot backups contain the appropriate storage
groups and logs for a given point in time.

The appropriate steps to archive an entire Exchange server are:

1. Create a SnapManager backup of the entire Exchange server (all storage groups).

Network Appliance Inc.

19
TECHNICAL REPORT

Figure 5) Creating a SnapManager backup for the Exchange server.

2. Use NDMP or dump to back up the Snapshot files containing storage group databases.

o The naming convention for the appropriate Snapshot file to archive is

/vol/LUN_volume_name/.snapshot/snapshot_name.

Figure 6) Viewing LUN locations in Computer Manager.

o In this example, dump the volumes that are associated with drives G: and H:, which are
/vol/data2 and /vol/data3 on the eddie filer.

Network Appliance Inc.

20
TECHNICAL REPORT

o The appropriate Snapshot copies to dump in this example with two storage groups
would be /vol/data2/.snapshot/exchsnap__tmw2k3__recent and
/vol/data3/.snapshot/exchsnap__tmw2k3__recent.

3. Use CIFS or a local backup program to back up the appropriate SnapInfo transaction log
directory or directories.

o Only the most recent SnapManager backup of the log files will need to be archived.
The naming convention for the appropriate directory using a CIFS-based backup is
\\Exchange_server_name\SnapInfo_LUN_Drive_Letter$\SnapInfo_Directory_Path
\Exchange_server_name\storage_group_name\Exchange_server_name__recent.

o This example used two storage groups, so both of the following directories will need to
be archived:
F:\NetApp SnapManager\SnapInfo\EXCH__TMW2K3\SG__First Storage
Group\TMW2K3__recent

F:\NetApp SnapManager\SnapInfo\EXCH__TMW2K3\SG__SG2\TMW2K3__recent
Other Exchange Backup Solutions
SnapManager for Exchange utilizes log files for full recoverability. The use of other vendor backup
utilities may inhibit the ability of SnapManager to recover data if the utility truncates log files after
completion. Make sure that any backup utilities used to back up Exchange while running in a
SnapManager for Exchange environment do not truncate log files.

Combining backup types against the Exchange database is not supported and will likely lead to loss of
data. Only SME backups should be performed against the Exchange databases. Other backup utilities
should still be used for the Windows system files and for the Windows system state data, including the
Active Directory information for disaster recovery purposes.

Restore Best Practices

When restoring a Snapshot backup to a production Exchange environment, there are two choices
available to the administrator. A point-in-time restore allows a restore to be made at a specific point in
time, taking the Exchange environment exactly as it was when the backup was created. If the last
backup was performed the night before at midnight, the restore will bring the Exchange system online
reflecting the way it looked at midnight the night before.

An up-to-the-minute restore can be performed using any available SnapManager backup as long as a
contiguous set of transaction logs exists that allows transactions to be played forward from the backup
time to the current point in time.

Regardless of the restore procedure that is chosen based on the situation, there are many important
factors to keep in mind regarding Exchange restores. All databases in a target storage group will be
dismounted at restore time. For Microsoft cluster environments, all resources on the virtual disk (all
storage groups on the same virtual server) are taken offline.

Renaming Storage Groups

Network Appliance Inc.

21
TECHNICAL REPORT

It is important not to try to start the Exchange virtual disk during the restore process. Any storage
groups that have been renamed cannot be restored using Snapshot copies created prior to the name
change. NetApp recommends performing a backup of the storage group immediately following any
major changes, such as renaming a storage group or database.

Disaster Recovery
While Snapshot provides protection against Exchange data corruption or virus infections, it does not
protect against a catastrophic hardware failure with the Exchange server or a problem with the
operating system. To protect against these potential issues, a standby server will provide the fastest
recovery option.

There are two methods available for a rapid recovery of Exchange data in the event of a disaster: a
standby recovery server using identical hardware and a standby recovery server using nonidentical
hardware. Although these methods sound similar, there are different steps required for each.

To implement a standby server using the same hardware, use identical hardware configured
with the same firmware updates, software, and applications as the Exchange host requires.
Either the standby server can be used to mount the hard drives from the original Exchange
server (if necessary), or it can be quickly built to act as the original Exchange server. In addition
to a recent Snapshot copy of the Exchange database and the SnapInfo directory, a copy of the
Windows system state on the Exchange server will be required.

The following is a high-level overview of the steps to take when recovering to a disaster
recovery server using identical hardware. Each organization should have these steps well
documented and tested prior to actually recovering a failed mail system.

1. Have an identical server with Windows 2000 prepared and assign a temporary computer
name.

2. Ensure this server is a member of a workgroup instead of a domain.

3. Important: Ensure the original Exchange server is not online.

4. Restore the system state data to the preconfigured Windows server.

5. Run Exchange 2000 setup using the disaster recovery mode switch (setup.exe
/DisasterRecovery). Install service packs using this mode as well.

6. Reinstall applications such as SnapDrive, SnapManager for Exchange, and antivirus

solutions.

7. Reconnect the LUN drives and use the database configuration wizard to update the
location of the Exchange databases.

Network Appliance Inc.

22
TECHNICAL REPORT

8. Restore the Exchange databases using the latest Snapshot copies. Ensure the Exchange
services have started and the databases are mounted.

For organizations that cannot afford to implement a standby server using identical
hardware, the Exchange services can be moved to another available server that is not
identical to the Exchange host, allowing for quick recovery of the Exchange data. This
procedure includes many of the steps similar to using the identical hardware approach.
Moving Exchange to a different server requires resetting the computer account in the
domain prior to restoring the system state. You must also add the following registry key for
service pack builds:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup DWORD_NAME:
ServicePackBuild SP1 HEX_VALUE: 1268 SP2 HEX_VALUE: 1682 SP3 HEX_VALUE:
1869

Note: It is important in both methods to ensure the new Exchange server uses the IP
address of the original Exchange server to eliminate any possible problems or confusion.
While moving the Exchange services to nonidentical hardware is a cost-effective solution, implementing
a standby recovery server using identical hardware is the recommended solution. Identical hardware
will ensure compatibility with all components and allows for the option of mounting the hard drives from
the production Exchange server in the event something other than the hard drive fails in the Exchange
host. More information on both these procedures can be found in the Additional Resources section at
the end of this document.

9) Using SnapManager for Exchange with Network Appliance SnapMirror

Network Appliance SnapMirror technology mirrors data to one or more Network Appliance filers over a
local area network (LAN) or wide area network (WAN). Once source and destination relationships are
established, a SnapMirror baseline transfer initializes the mirror to create a replica of the source on the
destination. SnapMirror maintains the synchronization of the replica through efficient, incremental
updates. Thus SnapMirror is highly effective and efficient in its use of valuable bandwidth, as it does
not repeatedly send the entire LUN.

The frequency of SnapMirror update events is determined by the frequency of SME backups.
SnapDrive triggers SnapMirror updates upon completion of a SnapManager backup procedure. The
SnapMirror maximum transfer rate can also be adjusted in kilobytes per second.

Key SnapMirror Concepts and Tips:

SnapMirror relationships are based on sources and destinations.

A destination updates the mirrored copy or replica of its source by "pulling" data across a LAN
or WAN when an update event is triggered by the source.

Consistent with the pulling nature of SnapMirror, relationships are defined by specifying
sources from which the destination filers synchronize their replicas.

Network Appliance Inc.

23
TECHNICAL REPORT

Destination filers are identified on source filers by assigning destination filers privileges via the
"snapmirror.access" protocol access option or by inclusion in the snapmirror.allow file.

SnapDrive currently works with volume SnapMirror (VSM) only. Qtree SnapMirror (QSM) is not
supported.
As discussed earlier, SnapManager is integrated with SnapDrive, which interfaces directly with Network
Appliance filers using the iSCSI or FCP disk access protocols. SnapManager relies upon SnapDrive for
disk management, controlling Snapshot, and SnapMirror events.

Figure 7) SnapManager and SnapMirror Components

Checklist for Configuring SnapManager and SnapMirror:

Install (via CIFS setup) both filers into the same Windows domain as the Exchange
organization.

Configure the Exchange, SnapDrive, and SnapManager Win32 services to use the same logon
service account.

Make sure the SnapDrive service account has the "Log on as a service" right in the Windows
operating system (normally occurs during installation).

Verify that RSH commands work between the Exchange server(s) and both filers using the
specified service account.

License and enable FCP and/or iSCSI on both filers.

License and enable SnapMirror on both filers.

Establish SnapMirror relationships.

Network Appliance Inc.

24
TECHNICAL REPORT

Make sure the filer's SnapMirror schedule is turned OFF by assigning the "- - - -" value (four
dashes separated by spaces).

Initialize the mirror configurations.

SnapMirror updates to the specified destinations will occur after the completion of every SME
backup.

SnapDrive and FilerView can be used to verify the successful completion and state of the
configured mirrors.

Network Appliance Inc.

25
TECHNICAL REPORT

Figure 8) SnapMirror Status in FilerView

10) Management Tools

Snapshot Reserve Usage Monitoring
The task of monitoring the Snapshot reserve is automatically configured at the time of LUN creation.
Simply monitor the application event log for warning events generated in the SnapDrive source and
Snapshot monitor event category. Figure 9 demonstrates that due to Snapshot consumption, the
reserve must be expanded to 63%, and there is not enough disk space to do so. In order to rectify such
a situation, either add more disks to the volume or remove some of the oldest SnapManager for
Microsoft Exchange 2000 backups.

Network Appliance Inc.

26
TECHNICAL REPORT

Figure 9) LUN error due to space limitations.

Disk Space Usage Monitoring

The amount of disk space used by Exchange should be monitored to ensure that the logical drives
(LUNs) containing data do not run out of space. Exchange 2000 includes a monitoring function that can
be used to notify administrators of low disk space. To enable this functionality for the LUNs, navigate to
the Tools | Monitoring and Status | Status section of the Exchange 2000 System Manager. Create an
entry for each LUN with the appropriate thresholds for your installation. The example shown in Figure
10 will monitor both the database (F:) and log (G:) drives for low disk space conditions. (A warning is
sent when the available space drops below 2GB, and a critical state message is sent when the drive is
below 1GB.)

Network Appliance Inc.

27
TECHNICAL REPORT

Figure 10) Monitoring virtual disks in Exchange.

Monitoring NIC Utilization in Single-Homed Configurations

NetApp recommends monitoring NIC card traffic utilization as a best practice. However, when the
single-gigabit NIC deployment model is implemented, this task is required. Monitoring the NIC
utilization is necessary in this deployment model because Exchange client, Exchange database, and all
other network traffic can be seen by the single-gigabit interface. Malicious network attacks or broken
network equipment may cause enough traffic to affect Exchange performance.

System monitoring can be used to track the total amount of data received and sent by the interface
using the "Bytes Total/sec" of the network interface object. Simply monitor this counter after initial
installation to derive a baseline. Then set an alert to be sent if traffic flow increases significantly over
the baseline average.

Filer Event Monitoring

Monitor the filer event logs to ensure proper operation of the filer. Issues may be discovered in the
event logs that require administrative action. One such action may be to replace a disk in a volume if
spare disks are not available.

This task can be completed by using the FilerView utility built into Data ONTAP. This utility can be
started by pointing a Web browser to http://filername/na_admin. Next, click the FilerView link. FilerView
will start and will ask for the credentials of a filer administrator. Once logged onto FilerView, click the
Filer menu option on the left side of the screen. Then choose the Syslog Messages menu option.

Network Appliance Inc.

28
TECHNICAL REPORT

Review the log on the right side of the screen for any issues that may require administrative action. For
more information on FilerView, refer to the Data ONTAP System Administrator's Guide.

Figure 11) Syslog messages in FilerView.

Terminal Server
Microsoft Terminal Server is not recommended as a way of administrating SnapDrive or SnapManager
for Exchange. When creating virtual disks from a terminal server session, the drives can appear as if
they were not created or have been disconnected when in fact they are operating without errors. The
only way to fully resolve problems when using Terminal Server is to log out of the session (but do not
disconnect). NetApp recommends avoiding Terminal Server for server management when possible.

11) Summary
Network Appliance SnapManager for Microsoft Exchange is a complete data management solution that
provides backup and restore features using Snapshot technology. By reducing backup and restore
times, minimizing Exchange outages, and consolidating Exchange storage, SME delivers a cost-
effective solution for managing critical Exchange data.

In conclusion, the recommendations made in this paper are intended to be best practices for most
environments. This paper should be used as a set of guidelines when designing, deploying, or
administrating SnapManager for Exchange. To ensure a supported and stable environment, familiarize
yourself with the resources provided in this paper and involve an Exchange specialist if necessary.

Network Appliance Inc.

29
TECHNICAL REPORT

12) Ethernet and FCP Technology Diagrams

Network Appliance Inc.

30
TECHNICAL REPORT

13) Additional Resources

TR 3124: Integrating NetApp Filers with the Microsoft Active Directory
www.netapp.com/tech_library/3124.html

Exchange 2000 Documentation and Release Notes

www.microsoft.com/exchange/techinfo/productdoc/ 2000/E2Kdocumentation.asp

Exchange 2000 Deployment Guide

www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/exchange/exchange2000/
deploy/upgrdmigrate/ex2kupgr/deploy/default.asp

Chapter 9 of Exchange 2000 Deployment Guide, "Tuning Exchange for Performance"

www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/
exchange/exchange2000/deploy/upgrdmigrate/ex2kupgr/deploy/d_09_tt1.asp

Exchange 2000 Planning Guide

www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/
exchange/exchange2000/deploy/upgrdmigrate/ex2kupgr/planus/default.asp

Exchange Up-to-Date Web Site

www.microsoft.com/exchange/techinfo/deployment/2000/E2Kuptodate.asp

Deploying Exchange 2000 Clusters

www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID= 824A63A2-F722-4BFF-A223-
E71B856F83C4

Disaster Recovery for Microsoft Exchange 2000 Server

www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/

Network Appliance Inc.

31
TECHNICAL REPORT

exchange/exchange2000/proddocs/onlinebooks/disrec/default.asp

Exchange 2000 Top 50 Issues and Solutions

http://support.microsoft.com/default.aspx?scid=/support/exch2000/e2khottopics.asp

Microsoft KB article 266096: "Exchange 2000 Requires /3GB Switch When Using More than 1GB of
RAM"
http://support.microsoft.com/default.aspx?scid=kb;[LN];266096

Microsoft KB article 313707: "Exchange 2000 May Lose Network Connectivity under Heavy Load"
http://support.microsoft.com/default.aspx?scid=kb;[LN];313707

Microsoft KB article 298064: "Scalability Planning for Exchange 2000 Server"

http://support.microsoft.com/default.aspx?scid=kb;[LN];298064

Microsoft KB article 318230: "How to Change the Exchange 2000 SMTP Mailroot Directory"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q318230

Microsoft KB article 297289: "How to Move Exchange 2000 to New Hardware and Keep the Same
Server Name"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q297289

* Snapshot metadata consumes a very small amount of disk space (32MB per terabyte).

Network Appliance, Inc. Company Confidential and Proprietary.

© 2002 Network Appliance, Inc. All rights reserved. Specifications subject to change without notice. NetApp, the Network Appliance logo, FAServer,
FilerView, NetCache, SecureShare, SnapManager, SnapMirror, SnapRestore, and WAFL are registered trademarks and Network Appliance,
Network Appliance Inc. ApplianceWatch, BareMetal, Camera-to-Viewer, Center-to-Edge, ContentDirector, ContentFabric, ContentReporter, DataFabric, Data ONTAP,
EdgeFiler, HyperSAN, InfoFabric, MultiStore, NearStore, NetApp Availability Assurance, NetApp ProTech Expert, NOW, NOW (NetApp on the Web),
RoboCache, RoboFiler, SecureAdmin, Serving Data by Design, Smart SAN, SnapCache, SnapCopy, SnapDirector, SnapDrive, SnapFilter,
SnapMigrator, Snapshot, SnapSuite, SnapVault, SohoCache, SohoFiler, The evolution of storage, Vfiler, and Web Filer are trademarks of Network
Appliance, Inc. in the U.S. and other countries. All other brands or products are trademarks or registered trademarks of their respective holders and
should be treated as such.
32