Update Rollup 9 for Microsoft Exchange Server SP1 Released

Microsoft has released Update Rollup 9 for Microsoft Exchange Server 2007 Service Pack 1 (SP1).

This update rollup contains some imortant bug fixes.

KB 970162 details about the issues fixed in this release of update rollup.

Read more on MSExchange Team Blog.

Standby Continuous Replication - On Standalone Mailbox Servers - Part 3

In Part 2, we discussed about the Preperation of the SCR Target server, in this Part 3, we will talk about SCR Activation for the Database Portability scenarios and in the end, we will discuss about SCR Activation using the Recover Server switch.

Database Portability is a new feature of Exchange 2007 and it allows us to mount the exchange database on any of the exchange servers in same organization. So in case of a database corruption say in SG1, we can manually perform the activation of the SCR target database.

Here are detailed steps for SCR Activation for the database portabilty scenarios:

1. Dismount the SCR Source database.

2. Now we need to disable the SCR and need to make the target database available for mounting.

This is done by the following command:

Restore-StorageGroupCopy SourceServerName\SG1 -StandbyMachine TargetServerName

Note: If the SCR source is not available, the Force parameter should be used with the Restore-StorageGroupCopy command.

3. After this has completed, we need to verify whether the database is in a Clean Shutdown state. If the database is in a Dirty Shutdown state, we can bring the database to a Clean Shutdown state by running Eseutil recovery mode (Eseutil /r) against the database.

4. Now after the database is in the Clean Shutdown state, we need to update the Active Directory with the new locations of the Storage Group and database files.

Here are the commands to change the paths for SG1Target and DBTarget from the temp paths to the paths for the SCR target's storage group and database files:

Move-StorageGroupPath TargetServerName\SG1Target -SystemFolderPath Path -LogFolderPath Path -ConfigurationOnly

Move-DatabasePath TargetServerName\SG1Target\DBTarget -EdbFilePath Path -ConfigurationOnly

5. Now we need to make the database to allow itslef to be overwritten during a restore operation. We can do this from its properties from the EMC.

6. Next, we can mount this database.

7. Ok now, the database is mounted, but we need to rehome the mailboxes to point to SCR Target Server. Please note that Microsoft Exchange System Attendant and System mailboxes should not be included in this.

Here is the command to do this:

Get-Mailbox -Database SourceServerName\SG1\DB I where {$_.ObjectClass -NotMatch '(SystemAttendantMailboxExOleDbSystemMailbox)'} I Move-Mailbox -ConfigurationOnly -TargetDatabase TargetServerName\SG1Target\DBTarget

So now this information has been replicated across the Active Directory, users can access the mailboxes now.

Please note if the Source server is not accessible, for clients running Outlook 2003 and earlier versions, we need to change their outlook profile to point to new target server.

Now, there might be scenarios where the whole source server is completely down and is not accessible pertaining to any hardware failure or something else, in these cases we can use Recover Server to activate the SCR target.

Here are the detailed steps for SCR Acttivation using Recover Server:

1. Disable the SCR and make the target databases available for mounting.
This is done by the following command:

Restore-StorageGroupCopy SourceServerName\SG1 -StandbyMachine TargetServerName -Force

2. Uninstall exchange server from the target server.

3. Rename the target server as the name of the source server if you have Outlook 2003 clients and want them to rehome automatically.

4. Run Setup /recoverserver. This should be run from the location where exchange binaries are located.

5. If the databases are in Dirty Shutdown state, use Eseutil to recover the databases.

Standby Continuous Replication - On Standalone Mailbox Servers - Part 2

In the Part 1 of this article, we discussed about SCR and how to enable it. In this Part 2, we will focus on the second step i.e. Prepare the SCR Target Server.

We can have the target server prepared initially so that in case of a failure, the SCR activation can be done pretty quickly that will save us precious time.

For all the Storage Groups (from the source server) whose copy has been setup on the SCR target server, we will create the Storage Groups on the Target server and create the mailbox database on it. We can keep the path of the log files and the database on any temp location as we will mount this store, dismount it and remove that temp directory.

Steps and Commands:

As in the part 1 of this article, we have enabled the SCR for SG1 on the Source Server. Here we will create the Storage Group SG1Target and mailbox database DBTarget on the Target Server.

1. New-StorageGroup -Server TargetServerName -name SG1Target -LogFolderPath C:\SG1Target -SystemFolderPath C:\SG1Target
2. New-MailboxDatabase -StorageGroup TargetServerName\SG1Target -Name DBTarget -EdbFilePath C:\SG1Target\dbtarget.edb
3. Mount-Database DBTarget
4. Dismount-Database DBTarget
5. Delete everything from C:\SG1Target

Please note that these storage groups that we have set up on the target server are only temporary objects that will be used to carry out the database portability recovery during the SCR Activation Process. We can create them later on also but creating them now will save us the precious time while performing the recovery.

Standby Continuous Replication - On Standalone Mailbox Servers

SCR - Standby Continuous Replication, the wonderful new feature introduced in Exchange Server 2007 SP1, introduces a new dimension in High Availabilty for Exchange Server 2007. SCR is designed for scenarios that use standby recovery servers and allows replicating a copy of Storage Group to a number of remote servers.

SCR uses the same log shipping and replay technology as local continuous replication (LCR) and cluster continuous replication (CCR).

It is very useful in the DR planning especially if we don’t want to go for full fledged clustering with automatic failover technologies like CCR because of various reasons like cost constraints of servers, OSs that are needed to have these types of setups.

SCR introduce redundancy in two scenarios for the Mailbox Servers:

• One Storage Group or Multiple Storage Groups go corrupt - Use Database Portability to activate SCR target databases.
• Full Server failure - Use Server Recovery to activate SCR target databases.

The starting point for SCR is called the source, which is any storage group, except a recovery storage group and the endpoint for SCR is called the target. SCR can support multiple targets per storage group. Although SCR can be combined with CCR and LCR, in this article we will focus and discuss its configuration on the standalone Mailbox Servers.

The whole process revolves around three activities:

1. Enable SCR
2. Prepare the SCR Target Server
3. SCR Activation

Enable SCR

Requirements:

1. The paths must be the same for both soource and the target like if source server is C:\Exchange\Data and C:\Exchange\Logs then these paths must be available on the target server.
2. There is a hard coded 50 log lag between the Source and Target, by default there is a 24 hour replay time which is configurable.
3. There can be only 1 database per storage group.

Command:

Enable-StorageGroupCopy SourceServerName\SG1 -StandbyMachine TargetServerName -ReplayLagTime 0.0:0:0

Parameters:

ReplayLagTime specifies how long the Replication Service waits before replaying replicated transaction logs to the replica Database (EDB) on the target. Default - 1 day

TruncationLagTime sets a lag time for truncating log files on that replica. Default - 0.

We can validate and check the status of the replication by running:

Get-storagegroupcopystatus -standbymachine TargetServerName

We will discuss the next two steps in the next parts of this article.

451 4.4.0 DNS query failed

I was working on this annoying issue few days back, the mails sent to few domains are getting stuck in the queues on the Hub Transport server. The error message on the queue states 451 4.4.0 DNS query failed.

Well, it looked liked from here that there might be some issue with the DNS, ran few nslookup tests from the HUB servers itself, and surprisingly the domain and its MX records were resolving fine and i was able to connect to them absolutely fine.
More interestingly, if you hardcode the entry of the MX Record for that domain in the hosts file, the mails went through straight away.

I researched around few forum posts stated below, it seem like that this is a Bug with Exchange Server 2007 on Windows Server 2008, some issue related to IPv6.

Reference Posts:

http://social.technet.microsoft.com/Forums/en-US/exchangesvrtransport/thread/2e9a6263-7863-4d13-9480-7611db222e9e
http://social.technet.microsoft.com/Forums/en-US/exchangesvrtransport/thread/5ac614ee-e4fb-41d9-88f0-363f912634b1