• Part 1 – Basic Concepts of Exchange Server 2007 High Availability
• Part 2 – How to use Local Continuous Replication
• Part 3 – How to use Single Copy Clusters
• Part 4 – How to use Cluster Continuous Replication
• Part 5 – How to use Standby Continuous Replication

Related posts:

• Exchange Server 2007 CCR recommendations
• Video Series: Exchange Server 2007 SP1 Standby Continuous Replication
• Project Coconut: Part 6 – Finishing the job
• Troubleshooting top Exchange 2007 SP1 SCR issues
• Project Coconut: Part 4 – Configuring Standby Continuous Replication

This article Exchange Server 2007 High Availability is © 2009 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

• Project Coconut: Introduction
• Project Coconut: Part 1 – Getting the environment up to scratch
• Project Coconut: Part 2 – Sizing the Exchange Server 2007 servers
• Project Coconut: Part 3 – Deploying the first Exchange Server 2007 server
• Project Coconut: Part 4 – Configuring Standby Continuous Replication
• Project Coconut: Part 5 – Its mailbox migration time!
• Project Coconut: Part 6 – Finishing the job

The mailboxes have all been moved and the new Exchange Server 2007 system is bedding in.  During and after your mailbox migration you may find one or two issues appear with some users’ mailbox access.

Classfactory error when moving mailbox to Exchange Server 2007

Some mailboxes may be reported as failed in your mailbox move report, with the following error information:

Error occurred in the step: Opening source mailbox. Failed to open mailbox with error: ClassFactory cannot supply requested class, error code: -1056749262.

Check the properties of the account in Active Directory Users & Computers and you should find that the account is disabled.  Exchange will not move a mailbox for a disabled user account.  Your options here are to enable the account temporarily while you move the mailbox, or just delete the mailbox from your legacy Exchange server.

Users unable to access Outlook Web Access after mailbox moves

Some users may report that they are not able to access OWA after their mailbox has been moved to the Exchange Server 2007 server.

Check the properties of the account in Active Directory Users & Computers and verify that in the Security tab the account is configured to inherit permissions.  If the tick box is cleared you should tick it and apply the change.

Removing legacy Exchange servers from the organisation

Microsoft has published some good guidance on removing your legacy servers from the Exchange organisation here on Technet.  Lets go through the steps here.

1. Move all mailboxes to an Exchange Server 2007 server in the organisation.  I’ve already covered that in the last part of this series.

2. Move all content from the public folder database on the legacy server to a public folder database on an Exchange 2007 server in the organization.

Exchange 2003 permits you to do this via the Exchange System Manager console.  Navigate to your legacy Exchange server and drill down to the Public Folder store.  Right click and select “Move all replicas”.

This operation can take some time for large public folder trees.  The move may also generate a lot of transaction logging and therefore a lot of disk IO on both the source and target server.  If the public folder databases are sharing disk with other databases or mail queues then you may want to consider doing this outside of business hours.

3. Move the OAB generation to the Exchange Server 2007 server.  A simple way of moving all OABs to the Exchange Server 2007 server is using the Exchange Management Console with the Get-OfflineAddressBook and Move-OfflineAddressBook cmdlets.

[PS] C:\>Get-OfflineAddressBook | Move-OfflineAddressBook -Server LABEX2 -confir
m:$false
WARNING: Do not turn off public folder publishing for offline address book
(OAB) "\Default Offline Address List" before it is generated on the target
server "LABEX2". If you turn off public folder publishing prematurely, the
entire OAB will be downloaded for all users who are associated with this OAB.

4. Remove public folder and mailbox stores.  You can do this by simply right-clicking and deleting the databases in Exchange System Manager.  However, Exchange will not permit you to delete a public folder store that still contains replicas, nor a mailbox store that still contains mailboxes.  System Manager will display an error that one or more users currently use this mailbox store (ID no: c1034a7f).

You can locate these stragglers using Active Directory Users & Computers.  Right-click the root of the domain and start a search.  Leave the first criteria blank and click on the Exchange tab.  Tick “Show only Exchange recipients” and “Users with Exchange mailbox”.  Click Find Now, and then add the Exchange Home Server column using the View menu.  Sort by this column and you should quickly see which users Exchange still thinks have mailboxes on the legacy server.

If the users don’t really have a mailbox you can right-click and remove their Exchange attributes.

5. Verify that internet mail is configured to route through your Exchange Server 2007 servers.  You can configure your Hub Transport server to send and receive internet mail using the instructions here.

6. Verify inbound protocol services point to an Exchange Server 2007 Client Access Server.  You can read about publishing Exchange 2007 with ISA Server 2006 here.

7. Delete the routing group connectors that connect the Exchange 2003 or Exchange 2000 routing groups and the Exchange 2007 routing group.  You can do this quickly and easily using the Get-RoutingGroupConnector and Remove-RoutingGroupConnector cmdlets.

[PS] C:\>Get-RoutingGroupConnector | Remove-RoutingGroupConnector -confirm:$fals
e

8. Remove Exchange 2003 or Exchange 2000 recipient policies that are only Mailbox Manager policies.

9. If you have Exchange 2003 or Exchange 2000 policies that are both E-mail Addresses and Mailbox Manager policies, remove the Mailbox Manager part of the policy.

10. Move the Public Folder hierarchy from the legacy Exchange admin group to the Exchange Server 2007 admin group.  To do this in Exchange System Manager right click the Exchange 2007 admin group and create a new Public Folders container.

 Then, drag the Public Folder tree from the legacy admin group to the Public Folder container you just created.

11. Delete the Recipient Update Services.  You can delete the domain RUS via Exchange System Manager, but the Enterprise RUS must be deleted via ADSIEdit.msc.  So you may as well use ADSIEdit.msc to delete them all.

12. Uninstall Exchange 2000/2003 from the server.  If any of the above steps have not been completed properly Exchange will not allow you to uninstall it via Add/Remove Programs.  However, if you are able to set the action to Remove then all requirements have been met and Exchange will uninstall.  You will often need your Exchange media available for the uninstallation.

So, what next?

I’ve now completed the minimum steps required to transition the Exchange 2003 organisation to Exchange 2007, however there are still tasks that should be performed on the Exchange 2007 server to finish the job.  You should consider upgrading your Email Address Policies and your Address List objects to Exchange 2007.  Though this is not strictly required, it pays to get it out of the way so you don’t run in to problems later on when you want to edit them

The Microsoft Exchange Team Blog has a great writeup of how to go about doing this here.

Uprading Email Address Policies

To find any legacy EAPs in the organisation you can run a filtered Get-EmailAddressPolicy command.

[PS] C:\>Get-EmailAddressPolicy | where { $_.RecipientFilterType -eq "Legacy" }
| Format-List Name,*RecipientFilter*,ExchangeVersion

Name                       : Default Policy
RecipientFilter            :
LdapRecipientFilter        : (mailnickname=*)
LastUpdatedRecipientFilter :
RecipientFilterApplied     : False
RecipientFilterType        : Legacy
ExchangeVersion            : 0.0 (6.5.6500.0)

This will reveal all “Legacy” EAPs and their RecipientFilter details.  To upgrade the Default Policy with its simple filter you can run the following Set-EmailAddressPolicy command.

[PS] C:\>Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients
Confirm
To save changes on object "Default Policy", the object must be upgraded to the
current Exchange version. After the upgrade, this object cannot be managed by a
 previous version of Exchange System Manager. Do you want to continue to
upgrade and save the object?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):y

Upgrading Address List Objects

Legacy Address Lists can be located using a filtered Get-AddressList cmdlet.

[PS] C:\>Get-AddressList | where {$_.RecipientFilterType -eq "Legacy"} | Format-
List Name,*RecipientFilter*,ExchangeVersion

Name                       : All Users
RecipientFilter            :
LdapRecipientFilter        : (& (mailnickname=*) (| (&(objectCategory=person)(o
                             bjectClass=user)(!(homeMDB=*))(!(msExchHomeServerN
                             ame=*)))(&(objectCategory=person)(objectClass=user
                             )(|(homeMDB=*)(msExchHomeServerName=*))) ))
LastUpdatedRecipientFilter :
RecipientFilterApplied     : False
RecipientFilterType        : Legacy
ExchangeVersion            : 0.0 (6.5.6500.0)

Name                       : All Groups
RecipientFilter            :
LdapRecipientFilter        : (& (mailnickname=*) (| (objectCategory=group) ))
LastUpdatedRecipientFilter :
RecipientFilterApplied     : False
RecipientFilterType        : Legacy
ExchangeVersion            : 0.0 (6.5.6500.0)

Name                       : All Contacts
RecipientFilter            :
LdapRecipientFilter        : (& (mailnickname=*) (| (&(objectCategory=person)(o
                             bjectClass=contact)) ))
LastUpdatedRecipientFilter :
RecipientFilterApplied     : False
RecipientFilterType        : Legacy
ExchangeVersion            : 0.0 (6.5.6500.0)

Name                       : Public Folders
RecipientFilter            :
LdapRecipientFilter        : (& (mailnickname=*) (| (objectCategory=publicFolde
                             r) ))
LastUpdatedRecipientFilter :
RecipientFilterApplied     : False
RecipientFilterType        : Legacy
ExchangeVersion            : 0.0 (6.5.6500.0)

These Address Lists can be upgraded using the Set-AddressList cmdlet.

[PS] C:\>Set-AddressList "All Users" -IncludedRecipients MailboxUsers

[PS] C:\>Set-AddressList "All Groups" -IncludedRecipients MailGroups

[PS] C:\>Set-AddressList "All Contacts" -IncludedRecipients MailContacts

[PS] C:\>Set-AddressList "Public Folders" -RecipientFilter { RecipientType -eq '
PublicFolder' }

The default Global Address List can also be upgraded using the Set-GlobalAddressList cmdlet.

[PS] C:\>Set-GlobalAddressList "Default Global Address List" -RecipientFilter {(
Alias -ne $null -and (ObjectClass -eq 'user' -or ObjectClass -eq 'contact' -or O
bjectClass -eq 'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistribut
ionList' -or ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder'))}

Confirm
To save changes on object "Default Global Address List", the object must be
upgraded to the current Exchange version. After the upgrade, this object cannot
 be managed by a previous version of Exchange System Manager. Do you want to
continue to upgrade and save the object?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):y

For non-default Address List and Global Address List objects some analysis of the custom LDAP filters will be required to determine how to go about upgrading them.  You can refer to the Evan Dodd’s blog post here for more details.

Is that it?

That is all for this Project Coconut series of posts, however there is a lot more to talk about with Exchange Server 2007 which I look forward to writing about.

Project complete.

Related posts:

• Exchange Remote Connectivity Analyzer Updated
• Publish Exchange Server 2007 OWA Using ISA Server 2006
• Configuring the Exchange Server 2007 Client Access Server
• Exchange Server 2007 High Availability
• Exchange Server 2007 Update Rollup 6 (Critical)

This article Project Coconut: Part 6 – Finishing the job is © 2008 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

• Enable-StorageGroupCopyStatus -StandbyMachine reports error “Another standby continuous replication source is already configured…”
• SCR Target Log Files Fail to Truncate After the TruncationLagTime is Surpassed
• SCR does not replicate logs in a disjoint namespace scenario
• Database seeding error: Error returned from an ESE function call (0xc7ff1004), error code (0×0)
• SCR Hidden Network share not created in a Cluster with Event id 2074

Read more here.

Related posts:

• Exchange Server 2007 High Availability
• Project Coconut: Part 6 – Finishing the job
• Project Coconut: Part 4 – Configuring Standby Continuous Replication
• Project Coconut: Part 1 – Getting the environment up to scratch
• Project Coconut: An Exchange Server 2000 to 2007 Transition – Introduction

This article Troubleshooting top Exchange 2007 SP1 SCR issues is © 2008 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

• Project Coconut: Introduction
• Project Coconut: Part 1 – Getting the environment up to scratch
• Project Coconut: Part 2 – Sizing the Exchange Server 2007 servers
• Project Coconut: Part 3 – Deploying the first Exchange Server 2007 server
• Project Coconut: Part 4 – Configuring Standby Continuous Replication
• Project Coconut: Part 5 – Its mailbox migration time!
• Project Coconut: Part 6 – Finishing the job

Project Coconut, now with even more blown deadlines!

What is Standby Continuous Replication?

Standby Continuous Replication (SCR) is a great new feature of Exchange Server 2007 SP1. SCR is basically a way to maintain an up to date replica of your storage groups and mailbox databases on a second server in case of a disaster. Typically this would be a server in a DR site somewhere in your network.

You can also use it to host replicas for multiple mailbox servers around your network, providing a single shared standby server.

SCR uses the same transaction log shipping and replay that is used in Local Continuous Replication and Cluster Continuous Replication. Each time a transaction log is written and closed off (they are each 1mb in size) it is copied to the standby server and then replayed into the standby database. If you are considering using SCR in your own environment here are a few planning points:

• SCR is available in both Standard Edition and Enterprise Edition of Exchange Server 2007 SP1.
• SCR is available in both clustered and non-clustered Mailbox Servers (this applies to both the source and the target server).
• The target server must be installed with the Mailbox Server role and have the same disk layout as the source server for a given storage group replica. For example if a storage group is configured to use L:\SG1Logs for logging and H:\SG1Data for the database, these paths must be available on the target server. You should also ensure that equivalent disk space is provisioned on the target server.
• Unlike CCR and LCR you cannot use a the passive database copy on an SCR target server to run your backups.
• An SCR source server can have more than one target, and an SCR target server can be the target for more than one source server.
• SCR can effect your backups.

How to configure Standby Continuous Replication

To demonstrate SCR I have two Exchange Server 2007 servers running in the lab.

• LABEX2 – member server running Exchange Server 2007 Client Access, Hub Transport, and Mailbox Server roles. This will be the SCR source server.
• LABDC1 – domain controller running Exchange Server 2007 Mailbox Server role. This will be the SCR target server. After installing the server I deleted the default Storage Group and Mailbox Database as they are not needed. Note: in a production environment I wouldn’t recommend using a domain controller for this.

Note the Storage Group and Mailbox Database folder paths on LABEX2. These folders must be available (the system will create them itself) for SCR to use on LABDC1. If the drive letter does not exist on the target server, or the folder path is in use already, then SCR will fail.

[PS] C:\>Get-StorageGroup -Server LABEX2 | fl name, systemfolderpath, logfolderp
ath

Name             : First Storage Group
SystemFolderPath : C:\FSGLog
LogFolderPath    : C:\FSGLog

[PS] C:\>Get-MailboxDatabase -Server LABEX2 | fl name, edbfilepath

Name        : Mailbox Database
EdbFilePath : C:\FSGData\Mailbox Database.edb

When enabling SCR, the first of the commands can be run from either the source or target server, but the remainder must be run on the target server. For that reason it is easier to just run all of the commands on the target server.

First we enable replication.

[PS] C:\>Enable-StorageGroupCopy "LABEX2\First Storage Group" -StandbyMachine LA
BDC1

If we take a look at the status of SCR at this time we can see that First Storage Group has changed from “Not Configured” to “Disabled”.

[PS] C:\>Get-StorageGroupCopyStatus -Server LABEX2 -StandbyMachine LABDC1

Name                      SummaryCopySt CopyQueueLeng ReplayQueueL LastInspecte
                          atus          th            ength        dLogTime
----                      ------------- ------------- ------------ ------------
First Storage Group       Disabled      0             0
Second Storage Group      NotConfigured 0             0

When SCR is first enabled it does not immediately generate the target database. There is a delay of 50 transaction logs which must first be shipped to the target server. These will then not replay until the “ReplayLagTime” interval has elapsed, which by default is 24 hours.

To speed up the process of creating the SCR replica on the target server you can manually seed the replica.

[PS] C:\>Suspend-StorageGroupCopy "LABEX2\First Storage Group" -StandbyMachine L
ABDC1

Confirm
Are you sure you want to perform this action?
Suspending Storage Group Copy "First Storage Group".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):y

[PS] C:\>Update-StorageGroupCopy "LABEX2\First Storage Group" -StandbyMachine LA
BDC1

[PS] C:\>Resume-StorageGroupCopy "LABEX2\First Storage Group" -StandbyMachine LA
BDC1

The Update-StorageGroupCopy operation can take some time if the number of transaction logs and the size of the database are large, particularly if the seeding is occurring over a slower WAN link. Keep this in mind when seeding your SCR target servers.

Maintaining Standby Continuous Replication

When an Exchange Server 2007 server is an SCR target you cannot backup the replicated databases. These can only be backed up on the source server. Therefore if the SCR target server is not performing any other roles in your Exchange organisation then you only need to perform backups of the operating system and system state. In some cases you don’t need to backup anything at all, as Exchange Server 2007 has excellent restoration procedures for recovering a failed server with its full configuration intact (as this is stored in Active Directory, not on the server itself).

However, because of the potential impact on your normal Exchange backups, it is important to monitor the health of Standby Continuous Replication. At the very least you should use Get-StorageGroupCopyStatus to check the health of each Storage Group’s replication, and monitor the SCR target server for MSExchangeRepl warning or error events in the Application Log.

In the next part of Project Coconut I’ll demonstrate a few shell commands to help with the migration of mailboxes to the new Exchange Server 2007 server.

Related posts:

• Exchange Server 2007 High Availability
• Project Coconut: Part 6 – Finishing the job
• Troubleshooting top Exchange 2007 SP1 SCR issues
• Project Coconut: Part 1 – Getting the environment up to scratch
• Project Coconut: An Exchange Server 2000 to 2007 Transition – Introduction

This article Project Coconut: Part 4 – Configuring Standby Continuous Replication is © 2008 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

• Project Coconut: Introduction
• Project Coconut: Part 1 – Getting the environment up to scratch
• Project Coconut: Part 2 – Sizing the Exchange Server 2007 servers
• Project Coconut: Part 3 – Deploying the first Exchange Server 2007 server
• Project Coconut: Part 4 – Configuring Standby Continuous Replication
• Project Coconut: Part 5 – Its mailbox migration time!
• Project Coconut: Part 6 – Finishing the job

Getting The Environment Up To Scratch

Project Coconut is underway and the first bit of action is getting the environment up to the pre-requisites for Exchange Server 2007. The existing environment is Active Directory in Windows 2000 Native Mode, with Windows 2000 Server domain controllers, and an Exchange 2000 Server organisation also running on Windows 2000 Server member servers.

While there are many Active Directory Sites in this environment there are only two that are relevant to the Exchange Server 2007 deployment – the HQ site, and the DR site. These are two well-connected locations with unique subnets, which rules out clustering the planned Windows Server 2003 hosts, but with Exchange Server 2007 SP1 allows us to implement site resiliency through Standby Continuous Replication (SCR).

Lets start by taking a look at the Active Directory requirements of Exchange Server 2007.

Exchange Server 2007 Active Directory Requirements

The full detail is available here, but I have summarised the requirements as follows:

As you can see the environment does not meet the pre-requisites for Active Directory. Although DNS is properly configured and the Domain and Forest functional levels are correct, the Windows 2000 Server Domain Controllers will not support Exchange Server 2007.

To meet the pre-requisites will require at least one Domain Controller in each of the HQ and DR sites to be built or upgraded to Windows Server 2003 SP1 or later. By building a server in each site, promoting it to a Domain Controller, setting them each as Global Catalogs, and moving the Schema Master FSMO role to the new DC at HQ, the Active Directory pre-requisites will be met.

The decision was made to deploy new, virtualised Domain Controllers at the DR site, and upgrade the existing Domain Controllers at the HQ site. But before either of these tasks is performed the Active Directory Schema must be updated for Windows Server 2003. This is not a trivial undertaking, and as such you should review the following comprehensive guidance from Microsoft:

How to upgrade Windows 2000 domain controllers to Windows Server 2003

If you do not follow this guidance there are a lot of different issues you can run into such as incompatible SMB clients, and mangled Exchange attributes. Be sure to read the article above, and also this article that specifically deals with the Exchange attributes issue.

Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers

Once the Schema has been successfully extended you can install or upgrade your Domain Controllers to Windows Server 2003. In this case I am installing Windows Server 2003 R2 Standard Edition. Because the R2 discs did not have Service Pack 2 included I first slipstreamed SP2 into them. This speeds up the deployment process because you don’t have to waste time installing the Service Pack after the server is up and running.

Microsoft’s guidance linked above on upgrading Domain Controllers is worth following, but what they don’t seem to mention is that you obviously should have on hand the latest Windows Server 2003 compatible drivers for your server hardware, particularly for important components such as the RAID card and the network adapters. Its no fun to see a BSOD or find your DC unable to connect to the network on first boot.

With the Active Directory pre-requisites out of the way it is time to look at the Exchange Organisation pre-requisites.

Exchange Server 2007 Existing Exchange Organisation Requirements

The pre-requisites for an upgrading an existing Exchange organisation to Exchange Server 2007 are as follows:

After all of the fun with Active Directory it is nice to see that for Project Coconut the organisation pre-requisites are already met. The Exchange environment is already consolidated into a single Exchange 2000 Server. Other than auditing the environment to plan the configuration of Exchange Server 2007 there is no preparation work required here.

Next on Project Coconut I’ll be discussing how I sized the hardware for the new Exchange Server 2007 hosts.

Related posts:

• Exchange 2000 and Windows Server 2008 Domain Controllers
• Security descriptor error during Exchange Server 2007 schema extension
• Preparing for an Exchange Server 2007 Transition
• Exchange Server 2007 High Availability
• Problem accessing Active Directory for Exchange 2007 OWA users

This article Project Coconut: Part 1 – Getting the environment up to scratch is © 2008 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Yes I did. The name came about basically like this:

Paul: Hey Steve, I need a good codename for this Exchange project. What do you think?

Steve: Project Coconut.

Paul: …. okay then.

Considering who I asked it could have been much worse.

Project Coconut… what is it?

Project Coconut is the piece of work currently occupying most of my time. It is a project to transition an Exchange 2000 Server organisation to Exchange Server 2007. The organisation is about 1000 users, has a few special bits and pieces requiring some close attention, and is the first (except our in-house upgrade) production deployment of Exchange Server 2007 SP1 I’ll be doing (we’ve done several Exchange Server 2007 RTM deployments to date).

The release of SP1 was well timed as this particular customer wants to implement some site resiliency. Knowing that Standby Continuous Replication was coming with SP1 and having labbed it throughout the beta program we knew this would be a good fit.

The project work will involve some good stuff like bringing the Active Directory up to meet the minimum requirements of Exchange Server 2007, introducing Exchange Server 2007 into the organisation, implementing the Standby Continuous Replication features and testing the DR processes around that, migrating all of the mailboxes to the new server, integrating third party applications into the new messaging environment, removing the legacy Exchange 2000 servers, and bringing the IT staff up to speed on the new administrative features of Exchange Server 2007.

Aaron kept an interesting diary of one of his Exchange Server 2007 projects so I will do my best to write about Project Coconut and the things that others might find useful along the way.

Project Coconut Entries:

• Part 1 – Getting the environment up to scratch
• Part 2 – Sizing the Exchange Server 2007 servers
• Part 3 – Deploying the first Exchange Server 2007 server
• Part 4 – Configuring Standby Continuous Replication
• Part 5 – Its mailbox migration time!
• Part 6 – Finishing the job

Related posts:

• Exchange Server 2007 High Availability
• Exchange Server 2007 Update Rollup 6 (Critical)
• Project Coconut: Part 6 – Finishing the job
• Troubleshooting top Exchange 2007 SP1 SCR issues
• Project Coconut: Part 4 – Configuring Standby Continuous Replication

This article Project Coconut: An Exchange Server 2000 to 2007 Transition – Introduction is © 2008 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

The videos are available for viewing or download here.

Read more about SCR on Technet.

Related posts:

• Exchange Server 2007 High Availability
• Exchange Server 2007 CCR recommendations
• Project Coconut: Part 6 – Finishing the job
• Troubleshooting top Exchange 2007 SP1 SCR issues
• Project Coconut: Part 4 – Configuring Standby Continuous Replication

This article Video Series: Exchange Server 2007 SP1 Standby Continuous Replication is © 2007 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com