Compartir a través de

Administración de grupos de disponibilidad de bases de datos en Exchange Server

  • Artículo

Un grupo de disponibilidad de base de datos (DAG) es un conjunto de hasta 16 servidores de buzones de Exchange que proporcionan recuperación automática a nivel de base de datos de un error de base de datos, servidor o red. Los DAG usan replicación continua y un subconjunto de tecnologías de clústeres de conmutación por error de Windows para ofrecer alta disponibilidad y resistencia en los sitios. Los servidores de buzones de correo de un DAG se supervisan mutuamente para detectar errores. Cuando se agrega un servidor de buzón de correo a un DAG, ese servidor funciona con los demás servidores del DAG para proporcionar recuperación automática a nivel de base de datos a partir de errores de base de datos.

Cuando crea un DAG por primera vez, al principio está vacío. Al agregar el primer servidor a un DAG, se crea automáticamente un clúster de conmutación por error para el DAG. Además, se inicia la infraestructura que supervisa los servidores en busca de errores en la red o el servidor. A continuación, el mecanismo de latido del clúster de conmutación por error y la base de datos de clúster se usan para realizar un seguimiento y administrar información sobre el DAG que puede cambiar rápidamente, como el estado de montaje de la base de datos, el estado de replicación y la ubicación del último montaje.

Cómo crear grupos de disponibilidad de base de datos

Un DAG se puede crear mediante el Asistente para nuevo grupo de disponibilidad de base de datos en el Centro de administración de Exchange (EAC) o ejecutando el cmdlet New-DatabaseAvailabilityGroup en el Shell de administración de Exchange. Al crear un DAG, se proporciona un nombre para el DAG y la configuración opcional del directorio testigo y del servidor testigo. Además, puede asignar una o varias direcciones IP al DAG, ya sea usando direcciones IP estáticas o permitiendo que se asignen direcciones IP de forma automática al DAG mediante el Protocolo de configuración dinámica de host (DHCP). Puede asignar manualmente direcciones IP al DAG mediante el parámetro DatabaseAvailabilityGroupIpAddresses . Si omite este parámetro, el DAG intenta obtener una dirección IP usando el servidor DHCP en la red.

Si va a crear un DAG que contendrá servidores de buzones de correo que ejecutan Windows Server 2012 R2, también tiene la opción de crear un DAG sin un punto de acceso administrativo del clúster. En ese caso, el clúster no tendrá un objeto de nombre de clúster (CNO) en Active Directory y el grupo de recursos principal del clúster no contendrá un recurso de nombre de red ni un recurso de dirección IP.

Para obtener instrucciones detalladas acerca de cómo crear un grupo de disponibilidad de base de datos, consulte Crear un grupo de disponibilidad de base de datos.

Al crear un DAG, se crea un objeto vacío que representa el DAG con el nombre especificado y una clase de objeto msExchMDBAvailabilityGroup en Active Directory.

Los DAG usan un subconjunto de tecnologías de agrupación en clústeres de conmutación por error de Windows en Windows Server 2008 R2 o posterior, como el latido del clúster, las redes de clúster y la base de datos de clúster (para almacenar datos que cambian o pueden cambiar rápidamente, como los cambios de estado de la base de datos de activo a pasivo o inverso, o de montados a desmontados o inversos). Por lo tanto, puede crear DAG solo en servidores de buzones de Exchange instalados en versiones compatibles de Windows que incluyan clústeres de conmutación por error de Windows.

Nota:

El error en el clúster creado y utilizado por el DAG debe ser dedicado a DAG. El clúster no se puede usar para ninguna otra solución de alta disponibilidad ni para cualquier otro fin. Por ejemplo, el error en el clúster no se puede usar para organizar por clústeres otras aplicaciones o servicios. No es compatible el uso de un error en el clúster subyacente de DAG para fines que no son el DAG.

Servidor testigo de DAG y directorio testigo

Al crear un DAG, debe especificar un nombre para el DAG que no tenga más de 15 caracteres que sea único en el bosque de Active Directory. Además, cada DAG se configura con un servidor testigo y un directorio testigo. El servidor testigo y su directorio solo se usan cuando hay un número par de miembros en el DAG y solo con fines de cuórum. No es necesario crear un directorio testigo por adelantado. Exchange crea automáticamente y protege el directorio en el servidor testigo. El directorio de testigos no debe usarse para ningún propósito que no sea para el servidor testigo dag.

Nota:

En la topología de creación de reflejo de la base de datos, puede tener un tercer servidor denominado "testigo". El servidor testigo permite la conmutación automática por error de la entidad de seguridad al servidor reflejado o viceversa. A diferencia de los servidores principal y reflejado, el servidor testigo no sirve a la base de datos. El rol del testigo es comprobar si un servidor asociado determinado está en funcionamiento. La compatibilidad con la conmutación automática por error es la única función para el servidor testigo e identifica qué servidor contiene la copia principal y qué servidor contiene la copia reflejada de la base de datos.

Los requisitos para el servidor testigo son los siguientes:

  • El servidor testigo no puede ser miembro del DAG.

  • El servidor testigo debe estar en el mismo bosque de Active Directory que el DAG.

  • El servidor testigo debe ejecutar Windows Server 2008 o posterior.

  • Un servidor simple puede servir de testigo para varios DAG. Sin embargo, cada DAG requiere su propio directorio testigo.

Independientemente del servidor que se use como servidor testigo, si firewall de Windows está habilitado en el servidor testigo previsto, debe habilitar la excepción firewall de Windows para el uso compartido de archivos e impresoras. El servidor testigo usa el puerto SMB 445.

Importante

Si el servidor testigo que especifique no es un servidor de Exchange 2010 o posterior, debe agregar el grupo de seguridad universal (USG) del Subsistema de confianza de Exchange al grupo de administradores local en el servidor testigo antes de crear el DAG. Estos permisos de seguridad son necesarios para asegurar que Exchange pueda crear un directorio y compartirlo en el servidor testigo, según sea preciso.

Ni el servidor testigo ni el directorio testigo necesitan ser tolerantes a errores ni usar ningún tipo de redundancia o alta disponibilidad. No es necesario usar un servidor de archivos en clúster para el servidor testigo, ni emplear ninguna otra forma de resistencia para el servidor testigo. Existen varias razones para ello. Con DAG más grandes (por ejemplo, de seis miembros o más) deben producirse varios errores antes de que sea necesario un servidor testigo. Debido a que un DAG de seis miembros puede tolerar hasta dos errores de votante sin perder quórum, se tendrían que producir errores en tres votantes antes de que se necesite un servidor testigo para mantener el quórum. Además, si se produce un error que afecta el servidor testigo actual (por ejemplo, se pierde el servidor testigo debido a un error de hardware), se puede usar el cmdlet Set-DatabaseAvailabilityGroup para configurar un servidor testigo y un directorio testigo nuevos (en caso de tener quórum).

Nota:

También se puede usar el cmdlet Set-DatabaseAvailabilityGroup para configurar el servidor testigo y el directorio testigo en la ubicación original si el servidor testigo perdió su almacenamiento o si alguien cambió el directorio testigo o los permisos de los recursos compartidos.

Consideraciones de ubicación de servidores testigo

La colocación de un servidor testigo de DAG dependerá de los requisitos de su empresa y de las opciones disponibles para su organización. Exchange ahora incluye compatibilidad con nuevas opciones de configuración de DAG que no se recomiendan o no son posibles en Exchange 2010. Estas opciones incluyen el uso de una tercera ubicación, como un tercer centro de datos, una sucursal o una red virtual de Microsoft Azure.

La siguiente tabla muestra recomendaciones generales de colocación de servidores testigo para distintos escenarios de implementación.

Escenario de implementación Recomendaciones
Un solo DAG implementado en un solo centro de datos Ubicar el servidor testigo en el mismo centro de datos que los miembros de DAG.
Un solo DAG implementado en dos centros de datos; no hay ubicaciones adicionales disponibles Ubicar el servidor testigo en una red virtual de Microsoft Azure para habilitar la conmutación por error automática del centro de datos. O bien,

Ubicar el servidor testigo en el centro de datos principal.
Varios DAG implementados en un solo centro de datos Ubicar el servidor testigo en el mismo centro de datos que los miembros de DAG. Entre las opciones adicionales se incluyen:
  • Uso del mismo servidor testigo para varios DAG
  • Uso de un miembro de DAG para que actúe como servidor testigo para un DAG testigo
Varios DAG implementados en dos centros de datos Ubicar el servidor testigo en una red virtual de Microsoft Azure para habilitar la conmutación por error automática del centro de datos. O bien,

Ubicar el servidor testigo en el centro de datos considerado principal para cada DAG. Entre las opciones adicionales se incluyen:

  • Uso del mismo servidor testigo para varios DAG
  • Uso de un miembro de DAG para que actúe como servidor testigo para un DAG testigo
Uno o varios DAG implementados en más de dos centros de datos En esta configuración, el servidor testigo debe localizarse en el centro de datos donde desee que se encuentre la mayoría de votos por quórum.

Cuando se ha implementado un DAG en dos centros de datos, ahora puede usar una tercera ubicación para hospedar el servidor testigo. Si su organización tiene una tercera ubicación con una infraestructura de red aislada de errores de red que afectan a los dos centros de datos en los que se implementa el DAG, puede implementar el servidor testigo del DAG en esa tercera ubicación, configurando así el DAG con la capacidad de conmutar por error automáticamente las bases de datos en el otro centro de datos en respuesta a un evento de error de nivel de centro de datos. Si su organización solo tiene dos ubicaciones físicas, puede utilizar una red virtual de Microsoft Azure como una tercera ubicación para colocar el servidor testigo.

Especificación de un servidor testigo y un directorio testigo durante la creación de los DAG

Al crear un DAG, debe proporcionar un nombre para el DAG. Además, puede especificar un servidor testigo y un directorio testigo.

Al crear un DAG, están disponibles las siguientes combinaciones de opciones y comportamientos:

  • Solo puede especificar un nombre para el DAG y dejar en blanco los campos Servidor testigo y Directorio testigo . En este escenario, el asistente busca en el sitio de Active Directory local un servidor de acceso de cliente que no tenga instalado el servidor de buzones y crea automáticamente el directorio predeterminado (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) y el recurso compartido predeterminado (<DAGFQDN>) en ese servidor y usa ese servidor de acceso de cliente como servidor testigo. Por ejemplo, considere el servidor testigo CAS3 en el que se ha instalado el sistema operativo en la unidad C. Un DAG denominado DAG1 en el dominio contoso.com usaría un directorio testigo predeterminado de C:\DAGFileShareWitnesses\DAG1.contoso.com, que se compartiría como \CAS3\DAG1.contoso.com.

  • Puede especificar un nombre para el DAG, el servidor testigo que desea usar y el directorio que va a crear y compartir en el servidor testigo.

  • Puede especificar un nombre para el DAG y el servidor testigo que desea usar, y dejar en blanco el campo Directorio testigo. En este caso, el asistente creará el directorio predeterminado en el servidor testigo especificado.

  • Puede especificar un nombre para el DAG, dejar en blanco el campo Servidor testigo y especificar el directorio que va a crear y compartir en el servidor testigo. En este escenario, el asistente busca un servidor de acceso de cliente que no tenga instalado el servidor de buzones de correo y crea automáticamente el DAG especificado en dicho servidor, comparte el directorio y usa ese servidor de acceso de cliente como servidor testigo.

Cuando se forma un DAG, éste inicialmente usará el modelo de quórum Mayoría de nodo. Cuando se agrega el segundo servidor de buzones de correo al DAG, el quórum cambia automáticamente a un modelo de quórum Mayoría de recurso compartido de archivos y nodo. Al producirse este cambio, el clúster del DAG comienza a usar el servidor testigo para mantener el quórum. Si el directorio testigo no existe, Exchange lo crea y lo comparte de forma automática, y lo aprovisiona con permisos de control total para la cuenta del equipo de CNO para el DAG.

Nota:

No se admite el uso de un recurso compartido de archivos que forme parte de un espacio de nombres del Sistema de archivos distribuido (DFS).

Si Firewall de Windows está habilitado en el servidor testigo antes de crear el DAG, es posible que bloquee la creación. Exchange usa Instrumental de administración de Windows (WMI) para crear el directorio y el recurso compartido de archivos en el servidor testigo. Si Firewall de Windows está habilitado en el servidor testigo y no hay excepciones de firewall configuradas para WMI, el cmdlet New-DatabaseAvailabilityGroup se cierra con un error. Si especifica un servidor testigo, pero no un directorio de testigos, recibirá el siguiente mensaje de error:

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

Si especifica un servidor testigo y un directorio de testigos, recibirá el siguiente mensaje de advertencia:

Unable to access file shares on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

Si Firewall de Windows está habilitado en el servidor testigo después de crear el DAG pero antes de agregar los servidores, es posible que bloquee las acciones de agregar o quitar miembros del DAG. Si Firewall de Windows está habilitado en el servidor testigo y no hay ninguna excepción de firewall configurada para WMI, el cmdlet Add-DatabaseAvailabilityGroupServer muestra el siguiente mensaje de advertencia:

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Para resolver los errores y advertencias anteriores, realice uno de los pasos siguientes:

  • Cree manualmente el directorio testigo y el recurso compartido en el servidor testigo, y asigne el CNO para el control completo de DAG para el directorio y el recurso compartido.

  • Habilite la excepción de WMI en Firewall de Windows.

  • Deshabilite Firewall de Windows.

Pertenencia de DAG

Una vez creado un DAG, puede agregar o quitar servidores del DAG mediante el Asistente para administrar grupos de disponibilidad de base de datos en el EAC o los cmdlets Add-DatabaseAvailabilityGroupServer o Remove-DatabaseAvailabilityGroupServer en el Shell de administración de Exchange. Para obtener instrucciones detalladas sobre cómo administrar la pertenencia a un DAG, vea Administración de la pertenencia a grupos de disponibilidad de base de datos.

Nota:

Cada servidor de buzones de correo que pertenezca a un DAG también es un nodo en el clúster subyacente usado por el DAG. Como resultado, en cualquier momento, un servidor de buzones de correo solo puede ser miembro de un DAG.

Si el servidor de buzones de correo que se agrega al DAG no tiene instalado un componente de clúster de conmutación por error, el método usado para agregar el servidor (por ejemplo, el cmdlet Add-DatabaseAvailabilityGroupServer o el Asistente para administrar grupos de disponibilidad de base de datos) instala la característica de clúster de conmutación por error.

Cuando se agrega el primer servidor de buzones de correo a un DAG, se producen los siguientes eventos:

  • Se instala el componente de clúster de conmutación por error de Windows, si aún no se había instalado.

  • Se crea un clúster de conmutación por error usando el nombre del DAG. Este error en el clúster es usado exclusivamente por el DAG, y el clúster debe estar dedicado al DAG. No se admite el uso del clúster para cualquier otro fin.

  • Un CNO se crea en el contenedor de equipos predeterminado.

  • El nombre y la dirección IP del DAG se registran como Host (A) en Sistema de nombres de dominio (DNS).

  • El servidor se agrega al objeto del DAG en Active Directory.

  • La base de datos del clúster se actualiza con información sobre las bases de datos montadas en el servidor agregado.

En un entorno grande o de varios sitios, en especial en los que el DAG se extiende a varios sitios de Active Directory, debe esperar hasta que se complete la replicación de Active Directory en el objeto DAG que contiene el primer miembro del DAG. Si este objeto de Active Directory no se replica en todo el entorno, agregar el segundo servidor puede hacer que se cree un nuevo clúster (y un nuevo CNO) para el DAG. Esta creación se debe a que el objeto DAG aparece vacío desde la perspectiva del segundo miembro que se va a agregar, lo que hace que el cmdlet Add-DatabaseAvailabilityGroupServer cree un clúster y un CNO para el DAG, aunque estos objetos ya existen. Para comprobar que el objeto DAG que contiene el primer servidor DAG se haya replicado, use el cmdlet Get-DatabaseAvailabilityGroup en el segundo servidor que se agrega a fin de comprobar si el primer servidor que se agregó figura como miembro del DAG.

Cuando se agregan los servidores segundo y posterior al DAG, se producen los siguientes eventos:

  • El servidor se une al clúster de conmutación por error de Windows del DAG.

  • El modelo de quórum se ajusta automáticamente:

    • El modelo de quórum Mayoría de nodos se usa para los DAG que tienen una cantidad impar de miembros.

    • El modelo de quórum Mayoría de recurso compartido de archivos y nodo se usa para los DAG que tienen una cantidad par de miembros.

  • De ser necesario, Exchange crea automáticamente el directorio testigo y el recurso compartido.

  • El servidor se agrega al objeto del DAG en Active Directory.

  • La base de datos del clúster se actualiza con información acerca de las bases de datos montadas.

Nota:

El cambio de modelo de quórum debe producirse automáticamente. Sin embargo, si el modelo de cuórum no cambia automáticamente al modelo adecuado, puede ejecutar el cmdlet Set-DatabaseAvailabilityGroup con solo el parámetro Identity para corregir en la configuración de cuórum del DAG.

Preconfiguración del objeto de nombre de clúster para un grupo de disponibilidad de base de datos

El CNO es una cuenta de equipo que se crea en Active Directory y se asocia con el recurso Nombre del clúster. El recurso Nombre del clúster está asociado al CNO, que es un objeto habilitado para Kerberos que actúa como la identidad del clúster y proporciona el contexto de seguridad del clúster. La formación del clúster subyacente del DAG y del CNO de ese clúster se realiza cuando se agrega el primer miembro al DAG. PowerShell remoto se comunica con el servicio de replicación de Microsoft Exchange en el servidor de buzones de correo que se agrega cuando se agrega el primer servidor al DAG. El servicio de replicación de Microsoft Exchange instala la característica de clúster de conmutación por error (si aún no está instalada) y comienza el proceso de creación del clúster. El servicio de replicación de Microsoft Exchange se ejecuta bajo el contexto de seguridad LOCAL SYSTEM y es en este contexto de seguridad donde se realiza la creación del clúster.

Precaución

Si sus miembros de DAG se ejecutan en Windows Server 2012, debe ensayar previamente el CNO antes de agregar el primer serviros al DAG. Si los miembros del DAG ejecutan Windows Server 2012 R2 y crea un DAG sin un punto de acceso administrativo de clúster, no se creará un CNO y no es necesario crear un CNO para el DAG.

Se puede preconfigurar y aprovisionar el CNO en entornos en los que la creación de la cuenta de equipo está restringida o en los que las cuentas de equipo se crean en un contenedor distinto del contenedor de equipos predeterminado. Cree y deshabilite una cuenta de equipo para el CNO y, a continuación, realice uno de los pasos siguientes:

  • Asignar el control total de la cuenta de equipo a la cuenta de equipo del primer servidor del buzón de correo que se agrega al DAG.

  • Asignar el control total sobre la cuenta de equipo al grupo de seguridad universal del subsistema de confianza de Exchange.

La asignación del control total sobre la cuenta de equipo a la cuenta de equipo del primer servidor de buzones de correo que agrega al DAG garantiza que el contexto de seguridad LOCAL SYSTEM podrá administrar la cuenta de equipo preconfigurada. Como alternativa, se puede usar la asignación de control total sobre la cuenta de equipo al grupo de seguridad del subsistema de confianza de Exchange porque el grupo del subsistema de confianza de Exchange contiene las cuentas de equipo de todos los servidores de Exchange del dominio.

Para obtener instrucciones detalladas acerca de cómo preconfigurar y aprovisionar el CNO para un DAG, vea Preconfiguración del objeto de nombre de clúster para un grupo de disponibilidad de base de datos.

Cómo eliminar servidores de un DAG

Los servidores de buzones de correo se pueden quitar de un DAG mediante el Asistente para administrar grupos de disponibilidad de base de datos en el EAC o el cmdlet Remove-DatabaseAvailabilityGroupServer en el Shell de administración de Exchange. Antes de que sea posible quitar el servidor de buzones de correo de un DAG, se deben quitar del servidor todas las bases de datos de buzones de correo replicadas. Si intenta quitar de un DAG un servidor de buzones de correo con bases de datos de buzones de correo replicadas, se produce un error en la tarea.

Existen escenarios en los que, antes de realizar determinadas operaciones, se debe quitar un servidor de buzones de correo de un DAG. Entre estos escenarios se incluyen lo siguientes:

  • Realización de una operación de recuperación del servidor: si se pierde un servidor de buzón que es miembro de un DAG, o si se produce un error y no se puede recuperar y necesita su reemplazo, puede realizar una operación de recuperación del servidor mediante el modificador Setup /m:RecoverServer . Sin embargo, para poder realizar la operación de recuperación, primero debe quitar el servidor del DAG mediante el cmdlet Remove-DatabaseAvailabilityGroupServer con el parámetro ConfigurationOnly .

  • Quitar el grupo de disponibilidad de base de datos: puede haber situaciones en las que tenga que quitar un DAG (por ejemplo, al deshabilitar el modo de replicación de terceros). Si necesita eliminar un DAG, primero, deberá quitar todos los servidores del DAG. Si intenta quitar un DAG que contiene algún miembro, se produce un error en la tarea.

Cómo configurar las propiedades del DAG

Una vez agregados los servidores al DAG, puede usar el EAC o el Shell de administración de Exchange para configurar las propiedades de un DAG, incluidos el servidor testigo y el directorio de testigos que usa el DAG, y las direcciones IP asignadas al DAG.

Las propiedades configurables incluyen las siguientes:

  • Servidor testigo: nombre del servidor que desea hospedar para el testigo del recurso compartido de archivos. Se recomienda especificar un servidor de acceso de cliente como servidor testigo. Esta nomenclatura permite al sistema configurar, proteger y usar automáticamente el recurso compartido, según sea necesario, y permite que el administrador de mensajería tenga en cuenta la disponibilidad del servidor testigo.

  • Directorio testigo: el nombre de un directorio que se usará para almacenar datos de testigos del recurso compartido de archivos. El sistema creará automáticamente este directorio en el servidor testigo especificado.

  • Direcciones IP del grupo de disponibilidad de base de datos: se deben asignar una o varias direcciones IP al DAG, a menos que los miembros del DAG ejecuten Windows Server 2012 R2 y cree un DAG sin una dirección IP. De lo contrario, las direcciones IP del DAG se pueden configurar mediante direcciones IP estáticas asignadas de forma manual o se pueden asignar al DAG de forma automática mediante un servidor DHCP de la organización.

El Shell de administración de Exchange permite configurar las propiedades de DAG que no están disponibles en el EAC, como las direcciones IP de DAG; configuración de cifrado y compresión de red; detección de red; el puerto TCP utilizado para la replicación; y la configuración del directorio testigo y del servidor testigo alternativo; y para habilitar el modo de coordinación de activación del centro de datos.

Para obtener instrucciones detalladas sobre cómo configurar las propiedades de un DAG, vea Configurar las propiedades del grupo de disponibilidad de base de datos.

Cifrado de red de DAG

Los DAG admiten el uso de cifrado mediante el aprovechamiento de las capacidades de cifrado del sistema operativo de Windows Server. Los DAG utilizan la autenticación Kerberos entre servidores de Exchange. Las API EncryptMessage y DecryptMessage del proveedor de compatibilidad para seguridad (SSP) Microsoft Kerberos manejan el cifrado del tráfico de red del DAG. El SSP de Microsoft Kerberos admite varios algoritmos de cifrado. (Para obtener la lista completa, consulte la sección 3.1.5.2, "Tipos de cifrado" de extensiones de protocolo Kerberos). El protocolo de enlace de autenticación Kerberos selecciona el protocolo de cifrado más seguro admitido en la lista: normalmente Estándar de cifrado avanzado (AES) de 256 bits, potencialmente con un código de autenticación de mensajes basado en hash SHA (HMAC) para mantener la integridad de los datos. Para obtener más información, vea HMAC.

El cifrado de red es una propiedad del DAG y no de la red dag. Puede configurar el cifrado de red dag mediante el cmdlet Set-DatabaseAvailabilityGroup en el Shell de administración de Exchange. La posible configuración de cifrado para las comunicaciones de red dag se muestra en la tabla siguiente:

Configuración Descripción
Deshabilitado No se usa cifrado de red.
Habilitado El cifrado de red se usa en todas las redes del DAG para replicación y propagación.
InterSubnetOnly El cifrado de red se usa en las redes del DAG al replicar en diferentes subredes. Esta configuración es la predeterminada.
SeedOnly El cifrado de red se usa en todas las redes del DAG solo para la propagación.

Compresión de red de DAG

Los DAG admiten compresión integrada. Cuando se habilita la compresión, la comunicación de redes del DAG usa XPRESS, que es la implementación del algoritmo LZ77 por parte de Microsoft. Esta compresión es el mismo tipo de compresión que se usa en muchos protocolos de Microsoft, en particular, la compresión RPC MAPI entre Microsoft Outlook y Exchange.

Al igual que con el cifrado de red, la compresión de red también es una propiedad del DAG y no de la red dag. Configure la compresión de red de DAG mediante el cmdlet Set-DatabaseAvailabilityGroup en el Shell de administración de Exchange. La posible configuración de compresión para las comunicaciones de red dag se muestra en la tabla siguiente:

Configuración Descripción
Deshabilitado No se usa compresión de red.
Habilitado La compresión de red se usa en todas las redes del DAG para replicación y propagación.
InterSubnetOnly La compresión de red se usa en las redes del DAG al replicar en diferentes subredes. Esta configuración es la predeterminada.
SeedOnly La compresión de red se usa en todas las redes del DAG solo para la propagación.

Redes de DAG

Una red del DAG es un conjunto de una o más subredes usadas para el tráfico de replicación o el tráfico MAPI. Cada DAG contiene un máximo de una red MAPI y cero más redes de replicación. En una única configuración de adaptador de red, la red se usa para el tráfico MAPI y de replicación. Aunque se admite un único adaptador de red y una ruta de acceso, se recomienda que cada DAG tenga un mínimo de dos redes DAG. En una configuración de dos redes, una red suele estar dedicada al tráfico de replicación y la otra se usa principalmente para el tráfico MAPI. También puede agregar adaptadores de red a cada miembro DAG y configurar redes DAG adicionales como redes de replicación.

Nota:

Cuando se usan varias redes de replicación, no hay forma de especificar una orden de precedencia para el uso de las redes. Exchange selecciona aleatoriamente una red de replicación del grupo de redes de replicación para usarla en el trasvase de registros.

En Exchange 2010, la configuración manual de las redes del DAG era necesaria en muchos escenario. De forma predeterminada, en versiones posteriores de Exchange, el sistema configura automáticamente las redes DAG. Antes de crear o modificar las redes del DAG, primero deberá habilitar el control manual de la red del DAG ejecutando el siguiente comando:

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

Después de habilitar la configuración de red de DAG manual, puede usar el cmdlet New-DatabaseAvailabilityGroupNetwork en el Shell de administración de Exchange para crear una red DAG. Para obtener instrucciones detalladas acerca de cómo crear una red de grupo de disponibilidad de base de datos, vea Creación de una red de grupos de disponibilidad de base de datos.

Puede usar el cmdlet Set-DatabaseAvailabilityGroupNetwork en el Shell de administración de Exchange para configurar las propiedades de red de DAG. Para obtener instrucciones detalladas sobre cómo configurar las propiedades de una red de DAG, vea Configuración de propiedades de red de grupos de disponibilidad de base de datos. Cada red del DAG tiene parámetros obligatorios y opcionales para configurar:

  • Nombre de red: un nombre único para la red dag de hasta 128 caracteres.

  • Descripción de red: una descripción opcional para la red dag de hasta 256 caracteres.

  • Subredes de red: una o varias subredes escritas con un formato de IPAddress/Máscara de bits (por ejemplo, 192.168.1.0/24 para subredes de protocolo de Internet versión 4 (IPv4); 2001:DB8:0:C000::/64 para subredes de protocolo de Internet versión 6 (IPv6).

  • Habilitar replicación: en el EAC, active la casilla para dedicar la red dag al tráfico de replicación y para bloquear el tráfico MAPI. Desactive la casilla para evitar que la replicación use la red DAG y para habilitar el tráfico MAPI. En el Shell de administración de Exchange, use el parámetro ReplicationEnabled del cmdlet Set-DatabaseAvailabilityGroupNetwork para habilitar y deshabilitar la replicación.

Nota:

La deshabilitación de la replicación en la red MAPI no garantiza que el sistema no usará esa red MAPI para replicación. Cuando todas las redes configuradas para replicación se encuentran sin conexión, presentan errores o no se encuentran disponibles y solo existe una red MAPI (que no está configurada como habilitada para la replicación) el sistema usa esa red MAPI para la replicación.

Las redes de DAG iniciales (por ejemplo, MapiDagNetwork y ReplicationDagNetwork01) creadas por el sistema se basan en las subredes enumeradas por el Servicio de clúster. Cada miembro DAG debe tener la misma cantidad de adaptadores de redes y cada adaptador de red debe tener una dirección IPv4 (y opcionalmente, también una dirección IPv6) en una subred única. Varios miembros de DAG pueden tener direcciones IPv4 en la misma subred, pero cada adaptador de red y par de dirección de IP en un miembro DAG específico deben estar en una subred única. Además, solamente el adaptador usado para la red MAPI se debe configurar con la puerta de enlace predeterminada. Las redes de replicación no se deben configurar con una puerta de enlace predeterminada.

Por ejemplo, considere DAG1, un DAG de dos miembros donde cada miembro tiene dos adaptadores de red (uno dedicado para la red MAPI y el otro para la red de replicación). En la tabla siguiente se muestran los valores de configuración de direcciones IP de ejemplo:

Configuraciones del adaptador de red de ejemplo

Adaptador de red del servidor Dirección IP/máscara de subred Puerta de enlace predeterminada
EX1-MAPI 192.168.1.15/24 192.168.1.1
Replicación de EX1 10.0.0.15/24 No aplicable
EX2-MAPI 192.168.1.16 192.168.1.1
Replicación de EX2 10.0.0.16 No aplicable

En la siguiente configuración, hay dos subredes configuradas en el DAG: 192.168.1.0 y 10.0.0.0. Cuando se agregan EX1 y EX2 al DAG, se enumerarán dos subredes y se crearán dos redes de DAG: MapiDagNetwork (192.168.1.0) y ReplicationDagNetwork01 (10.0.0.0). Estas redes se configurarán, como se muestra en la tabla siguiente:

Configuraciones de red DAG enumeradas para un DAG de subred simple

Nombre Subredes Interfaces Acceso a MAPI habilitado Replicación habilitada
MapiDagNetwork 192.168.1.0/24 EX1 (192.168.1.15)
EX2 (192.168.1.16)		 True True
ReplicationDagNetwork01 10.0.0.0/24 EX1 (10.0.0.15)
EX2 (10.0.0.16)		 False True

Para completar la configuración de ReplicationDagNetwork01 como red de replicación dedicada, deshabilite la replicación para MapiDagNetwork mediante la ejecución del siguiente comando:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\MapiDagNetwork -ReplicationEnabled:$false

Después de deshabilitar la replicación para MapiDagNetwork, el servicio de replicación de Microsoft Exchange usa ReplicationDagNetwork01 para la replicación continua. Si se produce un error en ReplicationDagNetwork01, el servicio de replicación de Microsoft Exchange vuelve a usar MapiDagNetwork para la replicación continua. El sistema realiza intencionadamente la devolución a MapiDagNetwork para mantener la alta disponibilidad.

Implementaciones de varias subredes y redes de DAG

En el ejemplo anterior, aunque hay dos redes diferentes usadas por el DAG (192.168.1.0 y 10.0.0.0), el DAG se considera un DAG de subred simple ya que cada miembro utiliza la misma subred para formar la red MAPI. Cuando los miembros de DAG usan diferentes subredes para la red MAPI, el DAG es referido como un DAG de subredes múltiples. En un DAG de varias subredes, cada red de DAG tiene asociada automáticamente la subred adecuada.

Por ejemplo, considere DAG2, un DAG de dos miembros donde cada miembro tiene dos adaptadores de red (uno dedicado para la red MAPI y otro para una red de replicación) y cada miembro de DAG está ubicado en un sitio de Active Directory separado, con su red MAPI en una subred diferente. En la tabla siguiente se muestran los valores de configuración de direcciones IP de ejemplo:

Configuraciones del adaptador de red del ejemplo para un DAG en una subred múltiple

Adaptador de red del servidor Dirección IP/máscara de subred Puerta de enlace predeterminada
EX1-MAPI 192.168.0.15/24 192.168.0.1
Replicación de EX1 10.0.0.15/24 No aplicable
EX2-MAPI 192.168.1.15 192.168.1.1
Replicación de EX2 10.0.1.15 No aplicable

En la siguiente configuración, hay cuatro subredes configuradas en el DAG: 192.168.0.0, 192.168.1.0, 10.0.0.0, y 10.0.1.0. Cuando se agregan EX1 y EX2 al DAG, se enumerarán cuatro subredes pero solo se crearán dos redes de DAG: MapiDagNetwork (192.168.0.0, 192.168.1.0) y ReplicationDagNetwork01 (10.0.0.0, 10.0.1.0). Estas redes se configurarán como se muestra en la tabla siguiente:

Configuraciones de red DAG enumeradas para un DAG de subred múltiple

Nombre Subredes Interfaces Acceso a MAPI habilitado Replicación habilitada
MapiDagNetwork 192.168.0.0/24
192.168.1.0/24		 EX1 (192.168.0.15)
EX2 (192.168.1.15)		 True True
ReplicationDagNetwork01 10.0.0.0/24
10.0.1.0/24		 EX1 (10.0.0.15)
EX2 (10.0.1.15)		 False True

Redes del DAG y redes iSCSI

De forma predeterminada, los DAG encuentran todas las redes detectadas y configuradas para ser usadas según su clúster subyacente. Esta detección incluye la de cualquier red SCSI de Internet (iSCSI) en uso como resultado del uso del almacenamiento iSCSI para uno o varios miembros del DAG. Se recomienda que el almacenamiento iSCSI use redes y adaptadores de red dedicados. Estas redes no deben administrarse mediante el DAG o su clúster, ni usarse como redes DAG (MAPI o replicación). En su lugar, estas redes deben deshabilitarse manualmente para que el DAG pueda dedicarse al tráfico de almacenamiento iSCSI. Para deshabilitar la detección de las redes iSCSI y su uso como redes de DAG, configure el DAG para que omita cualquier red iSCSI actualmente detectada usando el cmdlet Set-DatabaseAvailabilityGroupNetwork, como se muestra en el ejemplo siguiente:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Este comando también deshabilitará el uso de la red por parte del clúster. Si bien las redes iSCSI continuarán apareciendo como redes de DAG, no se usarán para tráfico de replicación o MAPI después de la ejecución del comando anterior.

Cómo configurar los miembros de DAG

Los servidores del buzón de correo que son los miembros de un DAG tienen propiedades específicas para alta disponibilidad que se pueden configurar como se describe en las siguientes secciones:

Marcación automática de montaje de base de datos

El parámetro AutoDatabaseMountDial especifica el montaje de la base de datos automático después de la falla de la base de datos. Puede usar el cmdlet Set-MailboxServer para configurar el parámetro AutoDatabaseMountDial con cualquiera de los valores siguientes:

  • BestAvailability: si especifica este valor, la base de datos se monta automáticamente inmediatamente después de una conmutación por error si la longitud de la cola de copia es menor o igual que 12. La longitud de la cola de copia es el número de registros reconocidos por la copia pasiva que debe replicarse. Si la longitud de la cola de copia es superior a 12, las bases de datos no se montan automáticamente. Cuando la longitud de la cola de copia es menor o igual que 12, Exchange intenta replicar los registros restantes en la copia pasiva y monta la base de datos.

  • GoodAvailability: si especifica este valor, la base de datos se monta automáticamente inmediatamente después de una conmutación por error si la longitud de la cola de copia es menor o igual que seis. La longitud de la cola de copia es el número de registros que la copia pasiva reconoce que deben replicarse. Si la longitud de la cola de copia es superior a seis, la base de datos no se monta automáticamente. Cuando la longitud de la cola de copia es inferior o igual a 6, Exchange intentará replicar los registros restantes en la copia pasiva y montará la base de datos.

  • Lossless: si especifica este valor, la base de datos no se montará automáticamente hasta que todos los registros generados en la copia activa se hayan copiado en la copia pasiva. Esta configuración también causa el algoritmo de selección de copia del administrador activo para ordenar candidatos posibles para la activación basada en el valor de preferencia de activación de la copia de la base de datos y no en la longitud de la cola de la copia.

El valor predeterminado es GoodAvailability. Si especifica o BestAvailabilityGoodAvailabilityy todos los registros de la copia activa no se pueden copiar en la copia pasiva que se está activando, puede perder algunos datos del buzón. No obstante, la característica red de seguridad (habilitada de manera predeterminada) contribuye a proteger contra la pérdida de datos, al volver a enviar los mensajes en la cola de la red de seguridad.

Ejemplo: configuración de la marcación automática de montaje de base de datos

En el ejemplo siguiente se configura un servidor de buzones con una configuración AutoDatabaseMountDial de GoodAvailability.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Directiva de activación automática de la copia de la base de datos

El parámetro DatabaseCopyAutoActivationPolicy especifica el tipo de activación automática disponible para copias de bases de datos de buzones de correo en los servidores de buzones de correo seleccionados. Puede usar el cmdlet Set-MailboxServer para configurar el parámetro DatabaseCopyAutoActivationPolicy con cualquiera de los valores siguientes:

  • Blocked: si especifica este valor, las bases de datos no se pueden activar automáticamente en los servidores de buzones seleccionados.

  • IntrasiteOnly: si especifica este valor, se permite activar la copia de la base de datos en servidores del mismo sitio de Active Directory. Esta activación evita la conmutación por error o la activación entre sitios. Esta propiedad es para ingresar copias de bases de datos del buzón (por ejemplo: una copia pasiva se transforma en una copia activa). Las bases de datos no pueden activarse en este servidor de buzones de correo para copias de bases de datos que están activas en otro sitio de Active Directory.

  • Unrestricted: si especifica este valor, no hay restricciones especiales en la activación de copias de base de datos de buzones en los servidores de buzones seleccionados.

Ejemplo: configuración de la directiva de activación automática de la copia de base de datos

En el ejemplo siguiente se configura un servidor de buzones con una configuración DatabaseCopyAutoActivationPolicy de Blocked.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Bases de datos activas máximas

El parámetro MaximumActiveDatabases (también usado con el cmdlet Set-MailboxServer) especifica el número de bases de datos que se puede montar en este servidor de buzones de correo. Puede configurar los servidores del buzón de correo para cumplir con los requisitos de implementación al asegurar que un servidor de correo de voz individual no se sobrecargue.

El parámetro MaximumActiveDatabases se configura con un valor numérico de número entero. Cuando se alcanza el número máximo, las copias de la base de datos en el servidor no se activarán si se produce un error o cambio. Si las copias ya están activas en un servidor, este no permite montar bases de datos.

Ejemplo: configuración de las bases de datos activas máximas

En el ejemplo siguiente se configura un servidor de buzones de correo para admitir un máximo de 20 bases de datos activas:

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Cómo realizar el mantenimiento en los miembros de DAG

Antes de realizar cualquier mantenimiento de software o hardware en un miembro de DAG, primero debe colocar el miembro de DAG en modo de mantenimiento. Los scripts siguientes se proporcionan con Exchange Server para ayudar con los procedimientos de mantenimiento de DAG:

  • StartDagServerMaintenance.ps1: ayuda a mover todas las bases de datos activas del servidor. También mueve todas las funcionalidades de soporte del DAG críticas, como el rol Primary Active Manager (PAM) y no permite que vuelvan al servidor hasta que se ha finalizado el mantenimiento.

  • StopDagServerMaintenance.ps1: ayuda a sacar al miembro del DAG del modo de mantenimiento y convertirlo en un destino activo para todas las bases de datos y toda la funcionalidad crítica de soporte técnico de DAG.

Ambos scripts anteriores aceptan el parámetro ServerName (que puede ser el nombre de host o el nombre de dominio completo (FQDN) del miembro dag) y los parámetros WhatIf . Ambos scripts se pueden ejecutar de forma local o remota. El servidor en el que se ejecutan los scripts debe tener instalada la herramienta Administración del clúster de conmutación por error (RSAT-Clustering).

Nota:

El script deRedistributeActiveDatabases.ps1 también está disponible, lo que ayuda a montar bases de datos de buzones de correo en miembros específicos del DAG, como se indica en el número de preferencias de activación de cada base de datos. Sin embargo, en Exchange 2016 CU2 o posterior, la nueva propiedad DAG denominada PreferenceMoveFrequency equilibra automáticamente las copias de base de datos en un DAG. Por lo tanto, solo tendrá que usar RedistributeActiveDatabases.ps1 script si ha deshabilitado esta funcionalidad o si desea equilibrar manualmente las copias de la base de datos.

El script deStartDagServerMaintenance.ps1 realiza las tareas siguientes:

  • Establece el valor del parámetro DatabaseCopyAutoActivationPolicy en el miembro BlockedDAG en , lo que impide que se activen copias de base de datos en el servidor.

  • Pausa el nodo en el clúster, el cual evita que el noto sea o se convierta en PAM.

  • Mueve todas las bases de datos activas alojadas actualmente en el miembro de DAG a otros miembros de DAG.

  • Si el miembro de DAG posee actualmente el grupo de clúster predeterminado, el script mueve el grupo de clúster predeterminado (y por lo tanto el rol PAM) a otro miembro de DAG.

Si cualquiera de las anteriores tareas falla, el script deshace todas las operaciones, excepto los movimientos correctos de la base de datos.

Para iniciar los procedimientos de mantenimiento en un miembro de DAG, incluidos el vaciado de las colas de transporte y la suspensión de la conectividad de cliente, realice las siguientes tareas:

  1. Para vaciar las colas de transporte, ejecute el siguiente comando:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. Para iniciar la purga de las colas de transporte, ejecute el siguiente comando:

    Restart-Service MSExchangeTransport

  3. Para comenzar el proceso de purgar todas las llamadas de mensajería unificada (solo en Exchange 2016), ejecute el siguiente comando:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. Para acceder a los scripts de mantenimiento de DAG, ejecute el siguiente comando:

    CD $ExScripts

  5. Para ejecutar el script StartDagServerMaintenance.ps1 , ejecute el siguiente comando:

    .\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode

    Para el valor del parámetro MoveComment , puede hacer cualquier notación que desee. En el ejemplo anterior se usa "Maintenance".

    Nota:

    Este script puede tardar algún tiempo en ejecutarse y, durante este tiempo, es posible que no vea ninguna actividad en la pantalla.

  6. Para redirigir los mensajes pendientes de entrega en las colas locales al servidor exchange especificado por el parámetro Target, ejecute el siguiente comando:

    Redirect-Message -Server <ServerName> -Target <Server FQDN>

  7. Para colocar el servidor en modo de mantenimiento, ejecute el siguiente comando:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

Para comprobar que un servidor está listo para mantenimiento, realice las siguientes tareas:

  1. Para comprobar que el servidor se ha colocado en modo de mantenimiento, confirme que solo Monitoring y RecoveryActionsEnabled se encuentran en un estado activo al ejecutar el siguiente comando:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

  2. Para comprobar que el servidor no hospeda ninguna copia de base de datos activa, ejecute el siguiente comando:

    Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy

  3. Para comprobar que el nodo del clúster está en pausa, ejecute el siguiente comando:

    Get-ClusterNode <ServerName> | Format-List

  4. Para comprobar que todas las colas de transporte se han vaciado, ejecute el siguiente comando:

    Get-Queue

Una vez completado el mantenimiento y el miembro dag está listo para volver al servicio, el script deStopDagServerMaintenance.ps1 ayuda a sacar al miembro dag del modo de mantenimiento y ponerlo de nuevo en producción. El script deStopDagServerMaintenance.ps1 realiza las tareas siguientes:

  • Reanuda el nodo en el clúster, el cual habilita la funcionalidad del clúster completo para el miembro de DAG.

  • Establece el valor del parámetro DatabaseCopyAutoActivationPolicy en el miembro UnrestrictedDAG en .

  • Ejecuta el cdmlet Resume-MailboxDatabaseCopy para cada copia de la base de datos alojada en el miembro de DAG.

Cuando esté listo para restaurar el miembro de DAG al estado de producción completo, incluida la reanudación de las colas de transporte y la conectividad de cliente, realice las siguientes tareas:

  1. Para configurar el servidor para que esté en modo fuera de mantenimiento y listo para aceptar conexiones de cliente, ejecute el siguiente comando:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

  2. Para permitir que el servidor acepte llamadas de mensajería unificada (solo en Exchange 2016), ejecute el siguiente comando:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  3. Para acceder a los scripts de mantenimiento de DAG, ejecute el siguiente comando:

    CD $ExScripts

  4. Para ejecutar el script StopDagServerMaintenance.ps1 , ejecute el siguiente comando:

    .\StopDagServerMaintenance.ps1 -serverName <ServerName>

  5. Para permitir que las colas de transporte reanuden la aceptación y el procesamiento de mensajes, ejecute el siguiente comando:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  6. Para reanudar la actividad de transporte, ejecute el siguiente comando:

    Restart-Service MSExchangeTransport

Para comprobar que un servidor está listo para su uso en producción, realice las siguientes tareas:

  1. Para comprobar que el servidor no está en modo de mantenimiento, ejecute el siguiente comando:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

Si va a instalar una actualización de Exchange y se produce un error en el proceso de actualización, puede dejar algunos componentes del servidor en un estado inactivo, que se mostrará en la salida del cmdlet anterior Get-ServerComponentState . Para resolver este problema, ejecute los siguientes comandos:

  1. Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

  2. Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

  3. Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

Cómo apagar los miembros de DAG

La solución de alta disponibilidad de Exchange se integra con el proceso de apagado de Windows. Si un administrador o una aplicación inician el apagado de un servidor de Windows en un DAG con una base de datos montada que se replica en uno o más miembros del DAG, el sistema intentará activar otra copia de la base de datos montada antes de permitir que se complete el proceso de apagado.

Sin embargo, este nuevo comportamiento no garantiza que todas las bases de datos del servidor que se cierran experimenten una lossless activación. Por lo tanto, es mejor realizar una conmutación de servidor antes de apagar un servidor miembro de un grupo de disponibilidad de base de datos.

Instalación de actualizaciones en miembros DAG

La instalación de actualizaciones de Exchange en un servidor que es miembro de un DAG es un proceso relativamente sencillo. Al instalar una actualización en un servidor que es miembro de un DAG, se detienen varios servicios durante la instalación, incluidos todos los servicios de Exchange y el servicio de clúster. El proceso general para aplicar actualizaciones a un DAG es el siguiente:

  1. Siga los pasos descritos arriba para poner el miembro de DAG en modo de mantenimiento.

  2. Instale el paquete.

  3. Use los pasos descritos arriba para sacar al miembro de DAG del modo de mantenimiento y volver a ponerlo en la producción.

  4. Opcionalmente, use el script RedistributeActiveDatabases.ps1 para reequilibrar las copias de la base de datos activa en el DAG.

Para obtener más información sobre las últimas actualizaciones de Exchange, consulte Exchange Server números de compilación y fechas de lanzamiento.

Nota:

Siempre debe ejecutar todos los miembros del DAG en la misma versión del servidor exchange (incluidas las actualizaciones acumulativas y de seguridad). Realice una "actualización gradual" de todos los miembros del DAG y no ejecute un DAG con miembros en una versión de Exchange diferente durante un período de tiempo prolongado.