Comunicaciones

Replicación continua en espera en Exchange Server 2007 Service Pack 1

Scott Schnoll

Resumen:

• Configuración de la replicación continua en espera
• La importancia de la redundancia
• Cómo reduce SCR el tiempo de inactividad

Service Pack 1 ofrece varias características y mejoras nuevas para Exchange 2007. Una de ellas, la replicación continua en espera (SCR), está diseñada para ofrecer a las organizaciones redundancia en centros de datos y elasticidad de sitio. Como implica su nombre, la SCR está diseñada

para escenarios que usan o permiten el uso de servidores de recuperación en espera.

Si está familiarizado con la versión para fabricación (RTM) de Exchange 2007, sabrá que también ofrece redundancia en centros de datos y elasticidad de sitio mediante sus características de trasvase de registros y soporte técnico para clúster de conmutación por error de Windows®. En la versión RTM, el trasvase de registros (conocido oficialmente como replicación continua) está disponible de dos formas: replicación continua local (LCR), como se muestra en la figura 1 y replicación continua en clúster (CCR), como se muestra en la figura 2.

Figura 1** Replicación continua local **

Figura 2** CCR trasvasa registros a un segundo servidor en un clúster de conmutación por error de Windows **

La replicación continua ofrece disponibilidad y redundancia de datos permitiendo que los administradores habiliten y mantengan en línea una segunda copia de todas las bases de datos de buzones. Esta copia de la base de datos representa una primera línea de defensa frente a errores, pérdidas o daños a una base de datos de producción. En vez de perder el tiempo localizando una cinta de copia de seguridad para restaurar datos, puede activarse una copia de la base de datos y convertirse en base de datos de producción en cuestión de minutos.

SCR amplía los escenarios en los que puede lograr la disponibilidad de datos y servicios para su organización. Los nuevos escenarios le permiten separar las topologías de disponibilidad elevada de las topologías de elasticidad de sitio, y también le permiten implementar configuraciones personalizadas para necesidades específicas de su organización en cada área.

La versión RTM de Exchange 2007 ofrece redundancia en centros de datos y elasticidad de sitio, pero, puesto que la LCR y la CCR ofrecen sólo un copia adicional de cada base de datos, debe elegir entre la elasticidad y la redundancia. Por ejemplo, piense en las características de disponibilidad de datos y servicios que ofrece la CCR. La implementación de los nodos activos y pasivos en un solo centro de datos ofrece disponibilidad de datos y servicios en centros de datos pero no ofrece elasticidad de sitio (porque ambos nodos están en el mismo sitio físico). La implementación del nodo activo en un centro de datos y el nodo pasivo en un segundo centro de datos proporciona elasticidad de sitio pero no disponibilidad en centro de datos (porque el nodo pasivo, que ofrece estas características, se encuentra en un segundo centro de datos).

La SCR que ofrece el Service Pack 1 ofrece la capacidad de crear copias adicionales de cada base de datos, y significa que esa elevada disponibilidad y la elasticidad de sitio no se excluyen mutuamente; se pueden conseguir ambas. Por ejemplo, como se muestra en la figura 3, puede combinar SCR con CCR para replicar grupos de almacenamiento de forma local en un centro de datos principal (con CCR para la disponibilidad elevada) y de forma remota en un segundo centro de datos o un centro de datos de copia de seguridad (con SCR para la elasticidad de sitio). El segundo centro de datos contiene un clúster en espera que se puede activar y aprovisionar rápidamente con un servidor de buzones en clústeres de sustitución en un escenario de recuperación de sitios.

Figura 3** CCR implementada en el centro de datos Redmond y SCR implementada en el centro de datos Quincy **(Hacer clic en la imagen para ampliarla)

La figura 3 representa una implementación empresarial con dos centros de datos, cada uno con su propio sitio de Active Directory®: Redmond y Quincy. El sitio Redmond se encuentra en el centro de datos (producción) principal y el sitio Quincy se encuentra en un segundo centro de datos (copia de seguridad). CCR se implementa en Redmond para lograr la redundancia de centros de datos. Junto con los elementos de la infraestructura requeridos para Exchange 2007, los destinos de SCR están configurados en un clúster en espera ubicado en Quincy para lograr la elasticidad del sitio. Estos elementos adicionales de la infraestructura, que incluyen acceso de cliente y servidores de transporte de concentradores, servidores Active Directory y DNS, y acceso a Internet, pueden ser recursos dedicados o no dedicados. Los recursos dedicados son aquellos que se designan para admitir únicamente usuarios del centro de datos en el que residen. Los recursos no dedicados son aquellos que admiten usuarios del centro de datos local y usuarios de otras ubicaciones. Debe decidir si los recursos serán dedicados o no dedicados, en función de lo que resulte mejor para su organización. Para obtener más información acerca de los recursos dedicados y no dedicados, consulte el tema del archivo de ayuda de Exchange Server 2007 "Configuraciones de elasticidad de sitio" en technet.microsoft.com/bb201662.asp. Tenga en cuenta también el uso de un nuevo tipo de quórum de conjuntos de nodos mayoritario (MNS). En Exchange Server 2007, CCR usa el quórum de MNS con testigo del recurso compartido de archivos (FSW) en lugar del nodo tradicional de votantes, como puede observar en la figura 3.

En la figura 4, un entorno de CCR más SCR que está diseñado teniendo en cuenta la elasticidad ofrece varios niveles de redundancia para los buzones y servicios hospedados en el servidor EXCLUS1, con lo que se protege estos buzones de errores catastróficos de pequeña a gran escala.

Figura 4** Servidores de buzones independientes que usan SCR para replicar grupos de almacenamiento entre ellos **(Hacer clic en la imagen para ampliarla)

Las pequeñas y medianas organizaciones también pueden beneficiarse de SCR. Por ejemplo, como se muestra en la figura 4, una organización puede implementar dos servidores de buzones independientes (EXMBX1 Y EXMBX2) y usar SCR para replicar algunos o todos los grupos de almacenamiento de un servidor de buzones al otro.

En este ejemplo, tanto EXMBX1 como EXMBX2 son servidores de producción con cinco grupos de almacenamiento activos. Cada grupo de almacenamiento es un origen de SCR para un destino de SCR correspondiente en el otro servidor. En caso de que se produzca un error de almacenamiento o algún otro evento en el que un grupo de almacenamiento activo configurado como origen de SCR no esté disponible, la copia del destino de SCR puede activarse rápidamente usando unas cuantas tareas administrativas en el Shell de administración de Exchange. Con Microsoft® Office Outlook® 2007 y las características de portabilidad de bases de datos y detección automática de Exchange 2007, el tiempo de inactividad en caso de que se produzca una pérdida de grupo de almacenamiento activo (o, en su caso, una pérdida de varios grupos de almacenamiento activos) podría suponer unos pocos minutos.

Orígenes y destinos de SCR

Al igual que con LCR y CCR, SCR también usa el concepto de copias activas y pasivas de un grupo de almacenamiento, pero se refiere a ellos como orígenes y destinos de SCR, respectivamente. No obstante, los orígenes y destinos de SCR son copias de grupos de almacenamiento. (Los grupos de almacenamiento de recuperación no pueden habilitarse para SCR.)

El punto de partida para SCR (el origen de SCR) es cualquier grupo de almacenamiento de un servidor de buzones independiente o de un servidor de buzones de correo en clúster situado en un solo clúster de copia o entorno de CCR. Es importante tener en cuenta que, aunque el origen de SCR puede ser un servidor de buzones de correo en clúster, la propia SCR es una solución en clúster y no requiere el servicio de clúster de Windows. El extremo de SCR (el destino de SCR) puede ser o bien un servidor de buzones independiente o bien un nodo en un clúster de conmutación por error, donde la función del buzón está instalada pero no se ha configurado en el clúster ningún servidor de buzones de correo en clúster.

Relaciones de origen y de destino

Cada grupo de almacenamiento de origen de SCR puede tener un número ilimitado de destinos de SCR. Por ejemplo, un origen podría tener un destino que resida en el mismo centro de datos como origen y un segundo destino en un centro de datos diferente. Sin embargo, Microsoft recomienda no usar más de cuatro destinos por origen. Si decide usar más de cuatro destinos, debe valorar la posible repercusión sobre el servidor del origen de SCR en términos de memoria, CPU y recursos de disco, y hacer planes según corresponda. Todos los equipos del destino de SCR pueden tener varios servidores de origen. Service Pack 1 para Exchange 2007 debe estar ejecutándose en los equipos de origen y de destino. El sistema operativo debe ser compatible con Service Pack 1 para Exchange 2007 (por ejemplo, Windows Server® 2008 o Windows Server 2003 SP2). Sin embargo, independientemente del sistema operativo que use, SCR no dispone de compatibilidad entre sistemas operativos y requiere que el sistema operativo en el origen de SCR coincida con el sistema operativo de todos los destinos de SCR para ese origen. Así pues, si el origen de SCR ejecuta Windows Server 2003, todos los destinos de SCR para ese origen también deben ejecutar Windows Server 2003.

SCR está disponible en Exchange 2007 Standard Edition. Si se usa un servidor de buzones de correo en clúster situado en un entorno de SCC o de CCR como origen de SCR, será necesario Exchange 2007 Enterprise Edition. Cada destino de SCR admite un máximo de 50 instancias (50 grupos de almacenamiento replicados) al usar la Enterprise Edition y un máximo de 5 instancias al usar la Standard Edition.

Los destinos de SCR también tienen requisitos que deben cumplirse. En primer lugar, los equipos del origen y destino deben estar en el mismo dominio de Active Directory, aunque no hace falta que estén en el mismo sitio de Active Directory. Además, las rutas del archivo de registro y de la base de datos situados en el origen y todos sus destinos deben coincidir para cada grupo de almacenamiento que se replica con SCR. Por último, cuando un nodo o un servidor están configurados como destino de SCR, no se puede habilitar LCR para ningún grupo de almacenamiento en el equipo del destino de SCR ni se pueden agregar servidores de buzones de correo en clúster al clúster de conmutación por error en espera.

Comparación de SCR con CCR y LCR

SCR (como se muestra en la figura 5) usa el mismo trasvase de registros y la misma tecnología de relectura que LCR y CCR para ofrecer nuevas configuraciones y opciones de implementación. Al igual que con LCR y CCR, los grupos de almacenamiento habilitados para SCR no pueden contener más de una base de datos. Además, SCR no se puede usar para una base de datos de carpetas públicas si existe más de una base de datos de carpetas públicas en la organización de Exchange.

Figura 5** SCR está trasvasando registros a otro servidor o a un nodo pasivo en un clúster de conmutación por error **

Una diferencia clave con SCR es que admite varios destinos por grupo de almacenamiento, mientras que tanto LCR como CCR sólo admiten un único destino (la copia pasiva). Otra diferencia clave es que, a diferencia de CCR y LCR, no se pueden realizar copias de seguridad de una copia de SCR. Al usar la SCR, se actualizan los encabezados de la base de datos para destinos de SCR y los archivos de registro se truncan cuando las copias de seguridad admitidas se llevan a cabo en el grupo de almacenamiento del origen de SCR (o, en el caso de CCR y LCR, cuando las copias de seguridad se llevan a cabo en las copias activas o pasivas del grupo de almacenamiento del origen de SCR).

Al igual que con LCR y CCR, el trasvase de registros con SCR es continuo y usa un modelo de extracción. Tan pronto como un archivo de registro nuevo se haya cerrado y nombrado con el número de archivo de registro de secuencia de nueva generación, el servicio de replicación de Microsoft Exchange que se ejecuta en el equipo del destino de SCR extrae los archivos de registro de transacciones cerradas del equipo del origen de SCR, los inspecciona y los valida y, a continuación, los desplaza a su carpeta del archivo de registro del grupo de almacenamiento de contrapunto en el equipo del destino de SCR.

Tiempo de posposición de relectura

Después de que los archivos de registro se copien al equipo del destino de SCR, SCR hace algo distinto de LCR y CCR. En lugar de releer inmediatamente los archivos de registro en la copia de la base de datos, SCR aplica un retraso integrado de relectura de 50 archivos de registro y 24 horas. SCR también le permite especificar un retraso más allá de estos retrasos integrados. El retraso de la actividad de relectura es útil en muy diversos escenarios. Por ejemplo, en caso de daño lógico de una base de datos activa, un retraso podría evitar el daño lógico de la base de datos del objetivo de SCR.

El retraso de relectura controlado por el administrador se establece mediante un parámetro denominado ReplayLagTime, que dicta la cantidad de tiempo que debe esperar el servicio de replicación de Exchange antes de releer archivos de registro que ya se han copiado al equipo del destino de SCR. El formato es Días.Horas:Minutos:Segundos, y el valor predeterminado son 24 horas. La configuración máxima permitida para este valor es de siete días. La configuración mínima permitida es de cero segundos, y si se establece este valor en cero segundos, se elimina de forma eficaz cualquier retraso en la actividad de relectura del registro por encima del retraso predeterminado de 50 archivos de registro.

Además de ReplayLagTime, Exchange dispone de un retraso integrado codificado de 50 archivos de registro, independientemente del valor de ReplayLagTime. Para determinar cuándo debe releerse un archivo de registro, Exchange usa el valor más grande de los ReplayLagTime o x archivos de registro, donde x = 50. Esto supone una medida de seguridad adicional contra la necesidad de repropagar un grupo de almacenamiento en situaciones en que un origen de SCR que usa la replicación continua (por ejemplo, un servidor de buzones de correo en clúster en un entorno de CCR) experimente una conmutación por error y uno o más grupos de almacenamiento deban ponerse en línea mediante el cmdlet Restore-StorageGroupCopy. (Propagación es el proceso de usar las API de copia de seguridad de transmisión ESE (motor de almacenamiento extensible) para hacer una copia en línea de la base de datos origen de SCR en el equipo del destino de SCR.) Al retrasar la actividad de relectura en los destinos de SCR, cuando se produce una conmutación por error con pérdida de información, se reducirán las probabilidades de tener que repropagar las copias de SCR porque la naturaleza de la pérdida de datos en el origen de SCR sitúa las dos copias más cerca en el tiempo.

Tiempo de retraso de truncamiento

En la versión RTM de Exchange 2007, se aplican reglas en un entorno de replicación continua para que no se elimine un archivo de registro a menos que se haya realizado una copia de seguridad del mismo y se haya releído en la copia de la base de datos. Al usar la SCR, esta regla se modifica. SCR (que introduce el concepto de varias copias de la base de datos) permite que los archivos de registro se trunquen en el equipo del origen de SCR tan pronto como los inspeccionen todos los equipos del destino de SCR. El truncamiento de registros en el servidor del origen de SCR no espera hasta que se hayan releído todos los registros en todos los destinos de SCR porque las copias de los destinos de SCR se pueden configurar con grandes tiempos de posposición de relectura de registros.

También puede agregar un retraso adicional al truncamiento de registros con un parámetro nuevo llamado TruncationLagTime, que especifica el intervalo de tiempo que debe esperar el servicio de replicación de Exchange (con el formato Días.Horas:Minutos:Segundos) antes de truncar archivos de registro que se han copiado al equipo del destino de SCR y se han releído en la copia de la base de datos. El período de tiempo empieza en el momento en que se hayan releído correctamente los archivos de registro en la copia de la base de datos. La configuración máxima permitida para este valor es de siete días, mientras que el mínimo es de cero segundos, aunque cero segundos elimina de forma eficaz cualquier retraso en la actividad del truncamiento de registros.

En un entorno de SCR, se ejecuta cada tres minutos un subproceso en segundo plano para determinar si debe truncarse algún archivo de registro. Si la secuencia de la generación de archivos de registro está por debajo del punto de control de archivos de registro para el grupo de almacenamiento, y el archivo de registro es anterior a ReplayLagTime + TruncationLagTime, se truncará un archivo de registro en el destino de SCR.

En un entorno de LCR o de CCR ampliado con SCR, se truncará un archivo de registro en el destino SCR si se cumplen los siguientes cuatro criterios: se ha realizado copia de seguridad del archivo de registro, la secuencia de la generación de archivo de registro está por debajo del punto de control de archivos de registro para el grupo de almacenamiento, la copia pasiva del grupo de almacenamiento está en un estado que permite que se trunque el archivo de registro y todos los destinos de SCR han inspeccionado el archivo de registro.

Habilitación y administración de SCR

SCR se habilita mediante el cmdlet Enable-StorageGroupCopy en el Shell de administración de Exchange, que se ha actualizado en SP1 con algunos parámetros nuevos. Como se describe más arriba, ReplayLagTime y TruncationLagTime pueden proporcionarle el control de parte del comportamiento de los destinos de SCR. SeedingPostponed es otro parámetro que se puede usar para omitir la propagación inicial del destino de SCR. El aplazamiento de la propagación es útil en varias situaciones. Por ejemplo, digamos que la base de datos del grupo de almacenamiento que se está habilitando para SCR es de 100 GB. Quizás no le interese que atraviesen la red 100 GB de datos durante tiempos de producción máxima. El parámetro SeedingPostponed le ofrece la opción de habilitar la SCR inmediatamente y realizar una tarea de propagación más tarde. Cuando esté listo, puede propagar manualmente el destino de SCR que usa el cmdlet Update-StorageGroupCopy.

Pese a que los parámetros mencionados son opcionales, existe un parámetro de Enable-StorageGroupCopy que es obligatorio para SCR: StandbyMachine. Éste especifica el nombre del equipo que contendrá el destino de SCR. El valor de este parámetro se establece como parte del valor para el atributo msExchStandbyCopyMachines del grupo de almacenamiento que se habilita para SCR. El atributo msExchStandbyCopyMachines es una cadena Unicode multivalor que se agrega al esquema de Active Directory cuando Exchange 2007 SP1 se introduce en la organización de Exchange, que es uno de los motivos por los que SP1 requiere una actualización de esquema para Active Directory.

El parámetro StandbyMachine es básico para SCR, y se han actualizado varios cmdlets en SP1 de modo que usen este parámetro para habilitar y administrar destinos de SCR. Los cmdlets actualizados se describen en la figura 6.

Figure 6 Cmdlets que usan el parámetro Stand­by­Machine

Activación de destinos de SCR

SCR ofrece una o más copias recientes de los datos, que pueden usarse en caso de que los datos originales se pierdan o pasen a ser inutilizables. El proceso de realizar una copia del destino de SCR y restablecerlo como base de datos de producción se conoce como activación. La activación se produce como parte del proceso de recuperación, que tomará la forma de portabilidad de bases de datos o una de las dos opciones de recuperación de la instalación (/m:RecoverServer para recuperar un servidor independiente o bien /RecoverCMS para recuperar un servidor de buzones de correo en clúster).

Cómo se puede usar la SCR

Veamos cómo una compañía ficticia podría usar SCR y la portabilidad de bases de datos para recuperarse de un error de base de datos de buzones de correo. Tras detectar que la base de datos de producción está dañada, el administrador activa la base de datos de destino de SCR mediante la portabilidad de bases de datos.

La organización ha implementado Exchange 2007 con SP1 y ha decidido aprovechar SCR para ofrecer una copia de un grupo de almacenamiento de un servidor remoto de buzones de correo. Los servidores de buzones de origen y destino están en el mismo sitio de Active Directory y están configurados para usar servidores DNS integrados en Active Directory. El intervalo de replicación de Active Directory está configurado en 15 minutos.

Habilitación de SCR y recuperación de contenido almacenado

SCR está configurada para que los archivos de registro de transacciones se repliquen para un solo grupo de almacenamiento, SG1, que contiene una sola base de datos, MBX1. Las rutas de acceso para los archivos de grupo de almacenamiento y archivo de base de datos son C:\SG1 y C:\SG1\MBX1.EDB. En este caso, EXMBX1 es el origen de SCR y EXMBX2 es el destino de SCR. Se configuró como se observa aquí:

Enable-StorageGroupCopy EXMBX1\SG1 
-StandbyMachine EXMBX2

Después de habilitar SCR, se comprobó el mantenimiento y el estado de SCR para SG1 con el cmdlet Get-StorageGroupCopyStatus:

Get-StorageGroupCopyStatus EXMBX1\SG1 
-StandbyMachine EXMBX2

Para ahorrar tiempo durante el proceso de activación del destino de SCR, se preconfigura EXMBX2 con un grupo de almacenamiento, SG1PORT, y la base de datos, MBX1PORT, que se usará como parte de las operaciones de portabilidad de bases de datos. SG1PORT y MBX1PORT están separados del grupo de almacenamiento del destino de SCR y de los archivos de base de datos. Por lo tanto, las rutas de acceso de SG1PORT y MBX1PORT están configuradas con una ruta de acceso temporal que no entra en conflicto con las rutas de acceso del destino de SCR. SG1PORT y MBX1PORT sólo se usarán como objetos de portabilidad de bases de datos; el grupo de almacenamiento y los archivos de base de datos para SG1PORT no son necesarios. Debido a esto, el administrador desmonta MBX1PORT y elimina todos los archivos del grupo de almacenamiento. El grupo de almacenamiento y los objetos de base de datos permanecen en Active Directory porque se usarán más adelante para la portabilidad de bases de datos durante el proceso de la recuperación.

Activación y recuperación

Una entrada en el registro de eventos de aplicación indica que la base de datos de origen de SCR está dañada físicamente. Puesto que SCR se habilitó para SG1, se toma la decisión de realizar una activación manual de la base de datos del destino de SCR para SG1 y usar la portabilidad de bases de datos para restaurar la disponibilidad de datos. La activación de la copia del destino de SCR empieza con el desmontaje de MBX1 en SG1 mediante el siguiente cmdlet:

Dismount-Database EXMBX1\SG1\MBX1

A continuación, la base de datos de destino de SCR se vuelve viable para el montaje y se cambiará el inicio de los buzones situados originalmente en MBX1 a MBX1PORT.

El proceso de deshabilitar SCR y hacer que la base de datos del destino de SCR sea viable para el montaje implica ejecutar el cmdlet Restore-StorageGroupCopy. Esta tarea marca la base de datos de grupos de almacenamiento como montable y ofrece un informe sobre la pérdida de datos, si la hubiese, que se producirá a partir del montaje de la base de datos en el grupo de almacenamiento. También comprueba que todos los archivos de registro generados por la copia activa del grupo de almacenamiento están presentes en la ubicación del archivo de grupo de almacenamiento de la copia pasiva. Si falta alguno de los archivos de registro, la operación también tratará de copiarlos. El siguiente cmdlet se usa para hacer que la base de datos del destino de SCR sea viable para el montaje:

Restore-StorageGroupCopy EXMBX1\SG1 
-StandbyMachine EXMBX2

En este ejemplo, los archivos de registro del grupo de almacenamiento del origen de SCR están disponibles para copiar. Si estos archivos no están disponibles (por ejemplo, porque el equipo del origen de SCR no funciona), el parámetro Force debe agregarse a la tarea Restore-StorageGroupCopy. De lo contrario, Restore-StorageGroupCopy siempre intentará conectarse al origen de SCR para copiar cualquier archivo de registro que falte, y si el origen de SCR no está disponible, la tarea Restore-StorageGroupCopy producirá un error y la base de datos no será viable para el montaje. Al agregar el parámetro Force, se indica a la tarea Restore-StorageGroupCopy que los archivos de código fuente no están disponibles, en cuyo caso se omite el intento de conexión y procede a hacer que la base de datos del destino de SCR sea viable para el montaje.

Tras completar el comando de Restore-StorageGroupCopy, el administrador debe comprobar que la base de datos está en un estado de cierre correcto. Si la base de datos está en estado de cierre con errores (consulte technet.microsoft.com/aa996757.aspx), debe procurarse un cierre correcto. Si el prefijo de archivo de registro para el grupo de almacenamiento (por ejemplo, E00 o E01) es el mismo para el origen de SCR (EXMBX1\SG1) y el grupo de almacenamiento en el destino de SCR (SG1PORT) que se usará para la portabilidad de bases de datos (EXMBX2\SG1PORT), no será necesario ejecutar Eseutil en modo de recuperación y la operación final de montaje de la base de datos provocará el estado de cierre correcto de la base de datos después de que se hayan releído todos los archivos de registro replicados. Si la base de datos no tiene un estado de cierre correcto, deben ejecutarse las utilidades de la base de datos de Exchange Server (Eseutil) el modo de recuperación (Eseutil/R) respecto a la base de datos.

Una vez que la base de datos está en un estado de cierre correcto, podrá ejecutar dos comandos que actualicen Active Directory con nuevas ubicaciones para los archivos de grupo de almacenamiento y el archivo de base de datos. Estos comandos cambian las rutas de acceso para SG1PORT y MBX1 de sus rutas de acceso originales a las rutas de acceso para el grupo de almacenamiento y la base de datos (PORT SG1 y MBX1PORT) almacenados por etapas:

Move-StorageGroupPath EXMBX2\SG1PORT 
-SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT 
-EdbFilePath C:\SG1\MBX1PORT.EDB 
–ConfigurationOnly

Es necesario incluir el parámetro –ConfigurationOnly en los comandos anteriores para que sólo se actualice la configuración de opciones para estos objetos en Active Directory. No se desplaza ningún dato ni archivo, y tampoco es necesario porque SCR ya ha replicado los datos a C:\SG1 en EXMBX2.

El siguiente paso es configurar la base de datos (MBX1PORT) para que se le permita sobrescribirse durante una operación de restauración. Esto se puede realizar seleccionando la casilla de verificación de la opción "Una restauración puede sobrescribir esta base de datos" en las propiedades de objeto de base de datos de la Consola de administración de Exchange o mediante el siguiente comando en el Shell de administración de Exchange:

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT 
-AllowFileRestore:$true

Cuando haya configurado la base de datos para que se le permita sobrescribirse, el siguiente paso es montar la base de datos con el comando siguiente:

Mount-Database EXMBX2\SG1PORT\MBX1PORT

Después de montar la base de datos, debe cambiarse el inicio de los buzones cuyo inicio se había cambiado en la base de datos (SG1\MBX1) de SCR para que señalen a MBX1PORT en EXMBX2. Ejecute el cmdlet Get-Mailbox y canalice el resultado al cmdlet Move-Mailbox. Durante este proceso, es importante que el Operador de sistema de Exchange y los buzones del sistema no se incluyan en el resultado del cmdlet Get-Mailbox que se canaliza al cmdlet Move-Mailbox. No es necesario, ni se debe, cambiar el inicio de esos objetos de buzón. El siguiente comando se ejecuta para cambiar el inicio de todos buzones de usuario y excluir los buzones del sistema:

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|
ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly 
-TargetDatabase EXMBX2\SG1PORT\MBX1PORT

En este momento, ya es posible el acceso de cliente a MBX1PORT. Sin embargo, el hecho de que los usuarios puedan realmente tener acceso a sus buzones después de que se hayan desplazado de EXMBX1\SG1\MBX1 a EXMBX2\SG1PORT\MBX1PORT depende de la latencia de replicación de Active Directory; es decir, en función del número de servidores de directorio, es posible que la actualización tarde un tiempo en propagarse por el entorno. Además, los métodos del acceso de cliente también influyen. Los clientes de mensajería que usan Outlook 2007 y clientes que no son Outlook tendrán acceso al buzón del usuario después de actualizar con las nuevas rutas los servidores de directorio usados por el servidor del acceso de cliente del usuario. Los clientes de mensajería que usan Outlook 2003 y versiones anteriores necesitarán que el perfil de mensajería del escritorio del usuario se actualice con el nuevo nombre de servidor.

Pasos finales

Después de que los clientes tengan acceso a sus buzones y datos de buzones, el paso final consiste en establecer la redundancia volviendo a habilitar SCR. Esto se consigue quitando los grupos de almacenamiento y archivos de base de datos restantes de EXMBX1. Después de quitar los archivos, se pueden desplazar las rutas de acceso de EXMBX1\SG1\MBX1 a una ubicación temporal y EXMBX1 puede convertirse en un destino de SCR de EXMBX2.

Scott Schnoll es uno de los principales autores técnicos del Equipo de Exchange Server de Microsoft, por lo que ha redactado contenido para Exchange Server 2007. Antes de incorporarse a Microsoft, Scott escribió Microsoft Exchange Server 2003 Distilled (Addison-Wesley Professional, 2004) y fue el principal autor de Exchange 2000 Server: The Complete Reference (McGraw-Hill/OsborneMedia, 2001).

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.