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.

Some mailboxes show up as Shared or Linked... after Migrating to Exchange Server 2007

Here's a scenario where after migrating users from Exchange Server 2003 to Exchange Server 2007, some of the user mailboxes show as "Shared" Mailbox or "Linked" Mailbox within the Exchange Management Console... instead of showing them as "User" Mailbox.

A Linked mailbox is a mailbox that is associated with an external account. Thus Linked mailboxes are normal mailboxes that can hold an External account in a separate resource forest.

Few of these mailboxes here were shown as Linked mailboxes after migration because an orphan Active Directory Account has the "Associated External Account" right on the mailbox in question.

To fix this and have them show up as normal "User" mailboxes remove that orphan Active Directory account that has the "Associated External Account" right on the mailbox in question and run the following command from the Exchange Management Shell:

set-mailbox -id MAILBOX_NAME -ApplyMandatoryProperties

Now we come to why few mailboxes are shown up here as Shared mailboxes. If you have Self permission with associated external account checked, you get the shared mailbox on migration. That is the reason these mailboxes are showed up as shared.

To fix this, remove the "Associated External Account" permission from the Self and again run that command:

set-mailbox -id MAILBOX_NAME -ApplyMandatoryProperties

To read and understand more about the ApplyMandatoryProperties Parameter, read this excellent blog entry from Evan Dodds.

Information Store Crashing, Exchange 2007

The Microsoft Information Store Service (Store.exe) is repeatedly crashing an Exchange 2007 Mailbox Server.
In the application log, we get the following error message and store.exe is crashing due to EXCDO.DLL file:

Faulting application store.exe, version XXXX, time stamp XXXX, faulting module EXCDO.DLL, version XXXX, time stamp XXXX, exception code XXXX, fault offset 0x00000000001ed390, process id 0x1fc8, application start time XXXX.

Have opened up a case with MS PSS and had them analyze the crash dumps. They have identified it as a Bug. The issue is casued by Mac's, Entourage clients that does calendar bookings in the ICS format and the crash is occuring due to Entourage Client accessing a badly created ICS.
MS will provide a fix to this issue in Update Rollup 6.

If anyone is experiencing this issue, make sure you call MS PSS first thing and have them provide the temp bug fix to you.

Generic User Accounts | Exchange 2007 Shared Mailboxes

In an organization, there are mailboxes required that are shared by many individuals in a particular department... I will say them as generic accounts that a group of people use for common mail access. However, the Information Security team may take it as offensive as they have an active mailbox enabled user account... and if you decide to close on them, it becomes really difficult as users are used to them as it helps them to organize and manage their tasks efficiently... and instead creating the Distribution List with the same email address won't solve the purpose.

In Exchange 2007, we have concept of shared mailbox recipient type. When we create a mailbox as 'shared' it creates a disabled active directory account to which the mailbox is connected. Shared mailboxes do not have an associated password so we must grant mailbox permissions for the users requiring access to that mailbox.

Advantages

• Disabled accounts act as a security measure.
• Since the user account is disabled by default no initial password is required.
• If desired, existing mailboxes can be converted to shared mailboxes. Users can still be able to access emails and continue to receive emails on that mailbox.
• Will let the users to continue their operations more or less the same way.
• No need to setup Distributions Lists on account of closure of their respective generic accounts.