For many of us, the transition from Exchange 2003 to Exchange 2007 is taking its toll. This is because Exchange 2007 requires us to take up a new way of thinking, completely, in the planning, deployment & Disaster Recovery scenario as well as in the server sizing side.

I have already mentioned that Exchange 2007 Databases are no longer bound to a particular server name and that MS have included Log Shipping (Replication) into Exchange Server 2007 making it possible for you to keep an almost (log shipping is ASYNCHRONOUS) up-to-date copy of your live Information Stores in another location. Be this a separate folder / disk set or subsystem.

Now there are some limitations to LCR, off the top of my head these are:
- Only 1 Database per Storage Group can be configured for LCR
- Databases can ONLY be replicated to what windows thinks is Direct Attached Storage
- Replication is asynchronous, which means your off-line database will always be at least 1MB behind in email   content (1 log File)
- Ok, so now we looked at that, lets see how this technology / system helps us & our clients in the production environment.

Scenario:
I have a client with about 150 users who is on a tight budget and decides he does not require high-availability, what he does require, however, is fast reliable D/R solution which can bring his services up in the least amount of time.
An intranet Server will also be purchased & will use the same HDD type as those in Exchange Server.

Additionally backup of A/D, Exchange & Intranet will be performed onto tape daily.

Reduced Performance after D/R is acceptable while the production Exchange Server is brought back online, what is important to the client is service availability.

Solution:

Deploy Single Exchange 2007 Server with recommended config + additional 2x 300GB HDD (Mirrored for LCR).

Create Multiple Storage Groups each with a Single Information Store enabled for LCR. Place the Replica on the 300GB Mirrored Patition

Deploy intranet server.

Now lets look at how the above solution compares to the scenario requirements in various D/R situations:

Database Level Corruption:- Since Off-Line database is generated from log file replication by an off-line jet engine the corruption would not have propagated so all we need to do is point our Information Stores in Exchange 2007 to the LCR Databases & mount them, replay uncommitted/replicated logs, repair origional database off-line & then swtich back at your next convenience
                                                                                                                  Estimated Down time           <30mins
                                                                                                                  Data Loss                             0%
                                                                                                                  Performance Degradation      Temporary
Server Failure / Total System Failure:- Intranet Server makes use of the same hard disks as those in the Exchange server, therefore install Exchange 2007 on the intranet server, move the Live Database HDD’s / LCR + Log HDD to the Intranet server, Mount the databases & Replay Logs. For the users with Outlook 2007 + Auto-discover the new server name settings automatically update, for those with Previous Versions of Outlook, manually re-home or use Exchange Profile Update tool + Login Script to re-home outlook profiles
                                                                                                                  Estimated Down Time           <3 hours
                                                                                                                  Data Loss                             0%
                                                                                                                  Performance Degradation      Temporary

Of course, in the event that the production Exchange server was totally destroyed (Disks Included) you would have no option but to revert to the conventional Tape Backup & Restore procedure which has not changed much, except that you can now take VSS backup of the Off-Line Databases, and in this case restore time would depend on the size of data, availability of hardware etc. etc. etc. However, these scenario’s are pretty rare in the production environment & the only real alternative would of course be a geo-cluster…

Now I’ll leave you to draw your own conclusions as to how this can make your life easier- All I know is it’s a real alternative to traditional recovery methods & can save me a lot of headache, sleepless nights & SLA penalties therefore included in all my solutions.
CCR coming Soon …