While today reading my blog rolls, I found a very good article about the removal of Single Instance Storage from Exchange 2010, which I also a very important element for my organization to plan our Exchange 2007 Transition / Upgrade to Exchange 2010, so I found it to be as interesting topic, and sharing you from ExchangeServerPro.

Here you go…

What is the Real Effect of Removing Single Instance Storage in Exchange Server 2010

When Exchange Server 2010 was released a lot was made of the decision by Microsoft to remove Single Instance Storage (SIS) from the Exchange database engine.

Plenty of articles have been written about this so I won’t revisit the issue in much detail, except to summarise with these points:

• Disk storage technology has basically plateaued in speed capabilities (ie, disks aren’t getting faster)
• Disk storage technology is a lot cheaper in high capacity, lower performance types (eg SATA II, SAS)
• The previous Exchange database engine used a schema that permitted SIS but did not permit further optimization of performance (specifically, allowing sequential reads)
• Removing SIS and redesigning the database schema to permit sequential reads resulted in massive performance improvements (as much as 70% less disk IO for typical behaviour)

Does This Mean More Exchange Storage?

The major concern from Exchange Server customers was the impact this would have on their Exchange storage requirements. If SIS is removed, does that mean more disk and tape storage is going to be required? Especially as more and more organizations are already moving to larger mailboxes?

Furthermore, is that increase going to be exponential because of the increasing popularity of disk duplication (eg SAN mirroring) and the nature of Exchange Server 2010 Database Availability Groups (multiple database copies across many servers)?

Short answer, yes. All of those storage requirements are likely to increase when your organization moves to Exchange Server 2010.

How Much More Storage is Needed?

In real world migrations I have seen mailbox databases grow by between 20% and 50% just from moving all of the mailboxes from an Exchange 2003 or 2007 server to Exchange Server 2010.

Similarly, growth of email storage over time also increases by similar factors.

So with that in mind, how can an organization mitigate the risk of storage costs getting out of control when they move to Exchange Server 2010?

Reducing Storage Costs for Exchange Server 2010

Firstly, take advantage of the Exchange Server 2010 database performance improvements by deploying Exchange 2010 on lower cost storage (eg SATA II or SAS instead of 15k SCSI). Some customers are tempted to use “what we’ve already got” and deploy on their existing high performance SAN, when in reality a smarter move would be to provision the Exchange 2010 mailbox servers with lower cost, lower speed direct-attached storage (DAS) for storing mailbox databases.

Secondly, don’t duplicate Exchange 2010 data unnecessarily. If you have deployed an Exchange 2010 DAG, don’t also utilize SAN mirroring for mailbox database storage. Let the Exchange 2010 application-layer replication handle it for you (Exchange 2010 SP1 introduced block-level replication to resolve one of the remaining criticisms of the Exchange 2010 asynchronous file-level replication).

Finally, look to alternative methods of de-duplicating Exchange mailbox data in organizations utilizing large mailboxes. For example, many backup applications are now including data de-dupe capabilities, as do enterprise-grade email archiving solutions.

Zahir Hussain Shah
Infrastructure Practice Consultant – Unified Communications
MCSE, MCTS, MCTIP Enterprise Administrator, CCNA, ITIL
Blog: http://zahirshahblog.com | LinkedIn | Twitter

Exchange 2010 feature called Database Availability Group (DAG) is the new High Availability feature of Exchange 2010.

DRP Design

In both the production site and the Disaster Recovery site we need a server with Windows Enterprise edition since DAG relies on Microsoft Failover Clustering which is only available in the Enterprise edition. Both sites need a Domain Controller and a GC role. The DR site will be in a different Active directory Site so that users want log in to it

Installing

Installing Standard installation of Exchange 2010 edition on Windows 2008 R2 Enterprise that includes HAB,CAS,Mailbox – Roles. configuring all the basic configuration simillar on both servers and testing sending and reciving mail.

Creating a DAG.
In the Exchange Management Console

1. Expand Organization Configuration.
2. Click Mailbox.
3. In the middle pane, click the Database Availability Group tab.
4. In the right control pane click "New Database Availability Group".

The Create a DAG wizard starts.

Enter a name for your DAG. If you have a server with a HUB role but no mailbox role, then the wizard will select the HUB server and create the witness directory for you. If you don’t have an available HUB server, then you must manually specify the ‘Witness Server’ and a ‘Witness Directory’.

For macking sure that we want have permission problams with the Witness share directory add the ‘Exchange Trusted subsystem’ group to the witness server local administrators group. This is also necessary becasue in order to create a DAG you must also create a computer account in Active Directory. You might need to delegate ‘Exchange Trusted subsystem’ group to create and manage the computer account in Active Directory.

EMS Command for creating the DAG

We can also create the DAG with a Power Shall command instead of the GUI process -

New-DatabaseAvailabilityGroup -Name E10DAG -WitnessDirectory C:DAG1 -WitnessServer FQDNofaServerinPrimarySite -DatabaseAvailabilityGroupIpAddresses 192.168.15.233,192.168.25.233 -Verbose

The next step is to add your Exchange mailbox servers to your DAG

Right Click ‘Manage Database Availability Group Membership’ and then add the mailbox servers to it.

the Failover Cluster role will be installed on the servers you added to your DAG.

EMS Command For adding an Exchange server to DAG

Add-DatabaseAvailabilityGroupServer -Identity E10DAG -MailboxServer FQDNofMailboxServer -Verbose

The next step is to add databases to your DAG members in order to enable replication.

• Return to Exchange Management Console and expand Organization Configuration.
• Click Mailbox. In the middle pane, click the Database Management tab.

• In the lower pane, right-click the database you wish to replicate within the DAG.
• Choose Add Mailbox Database Copy.
• When the wizard launches, browse for the server in the DAG to which you want to replicate the mailbox database. Pick a Replay lag time and a truncation lag time.

EMS Command For adding a Database to replication

Add-MailboxDatabaseCopy -Identity ‘Mailbox Database 2010A’ -MailboxServer FQDNofServerInDRSite -ActivationPreference 2

Now we must set some parameters on the mailbox database so that it is not automatically activated.

EMS Command

Suspend-MailboxDatabaseCopy -Identity ‘Mailbox Database 2010AFQDNofServerInDRSite’ -ActivationOnly -Verbose

Configuring Replay Lag Time

Configuring Replay Lag time is something that you should seriously consider doing. Lag time is how long the passive copy will wait until the transaction log is replayed into the database. Replication is still happening as fast as possible.

EMS command

Set-MailboxDatabaseCopy -Identity ‘mailbox database 2010AFQDNofServerInDRSite’ -ReplayLagTime 0.1:0:0 -Verbose

There is also another paratemeter that you might want to use–the Truncation Lag Time.

EMS command

Set-MailboxDatabaseCopy -Identity ‘mailbox database 1976375852FQDNofServerInDRSite’ -TruncationLagTime 0.1:0:0

How long you set the ReplayLagTime and TruncationLogTime for depends on two things

• How long it takes you to notice a corruption on the production site.
• How long it takes to replay all transaction log files if you activate the DR site.

Creating the CASArray

New-ClientAccessArray -Name CASArray-HQ -Fqdn FQDNofYourDesiredEndpoint -Site ADsiteInPrimaryDatacenter

Now configure all your databases to have the CASArray-HQ object as the RPCClientAccessServer. This will ensure that Outlook conencts to CASArray FQDN instead of the actual server name.

Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer CASArray-HQ

You must also create a record in DNS with FQDNofYourDesiredEndpoint with an IP of your Exchange server in the primary datacenter. Set the TTL to a low value, such as 5 minutes, to make the switchover go faster to the Disaster Recover sit

Real Life Exchange 2010 Disaster Recovery

Friends,

Today while I was searching on Internet, for reading more to design Exchange 2010 Disaster Recovery Methodologies, this is what I got, and I found it will be quire helpful for everyone, because this got tested and carried out for one Real World Exchange 2010 Disaster Recovery Scenario:

Method goes as follows:

1 | Find some live mailbox servers that had the spare capacity to mount 22 databases. Split the list of databases to be mounted among them.

2 | For each mailbox server, copy over the database and log directories so we had the data to use.

3 | Perform a soft recovery with eseutil /r on each database/log set to commit any uncommitted log files and ensure we could actually mount the data later in the process.

4 | Create the new mailbox databases: new-mailboxdatabase -name <name> -server <server> -EdbFilePath <path to recovery folder, e.g. c:\RecoverDBs\RecoverDB1\<name of original edb>.edb> -LogFilePath <path to logs, e.g. c:\RecoverDBs\RecoverLogs1>

Pro Tip: Use a new name for the database. If the old database was named DAG1-DB001, you might use DAG1-RecoveryDB001.

5 | Set the newly created databases to allow file restore: set-mailboxdatabase <db name> -AllowFileRestore:$true

6 | Copy in the database, logs and catalog data to the correct folders (those specified in step 4)

7 | Mount the databases one at a time: mount-database <DatabaseName>

8 | Once the database is mounted we can now re-home all the users with mail data there: get-mailbox -database <OriginalDatabaseName> | ?{$_.ObjectClass -NotMatch ‘(SystemAttendantMailbox|ExOldDbSystemMailbox)’} | set-mailbox -database <RecoveryDatabaseName>

9 | If you’re running with multiple copies then keep in mind that you’ve only got one live copy of the new database. You can either add a copy of the new database or do what we did and move them to databases on your new DAG that (hopefully) has multiple copies already. If you choose to go the route of moving them to existing healthy databases the command is: get-mailbox -database <RecoveryDatabaseName> | new-moverequest -TargetDatabase <HealthyDatabaseName>

Comments and/or questions are welcome in the comments. I just wrote this from memory so if I missed anything along the way please let me know.

Source:
http://jeremyphillips.org/2010/01/real-life-exchange-2010-disaster-recovery/

Zahir Hussain Shah