Administrar grupos de disponibilidad de bases de datos

22/03/2021
34 minutos para leer

+8
Un grupo de disponibilidad de base de datos (DAG) es un conjunto de hasta 16
servidores de buzones de correo de Exchange que proporciona recuperación automática
a nivel de base de datos de una base de datos, servidor o falla de red. Los DAG
utilizan la replicación continua y un subconjunto de tecnologías de agrupación en
clústeres de conmutación por error de Windows para proporcionar alta disponibilidad
y resistencia del sitio. Los servidores de buzones de correo en un DAG se
monitorean entre sí para detectar fallas. Cuando se agrega un servidor de buzones
de correo a un DAG, ese servidor funciona con los otros servidores del DAG para
proporcionar una recuperación automática a nivel de base de datos de fallas en la
base de datos.

Cuando crea un DAG, inicialmente está vacío. Cuando agrega 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 monitorea los servidores para detectar
fallas en la red o en el servidor. El mecanismo de latido del clúster de
conmutación por error y la base de datos del clúster se utilizan para realizar un
seguimiento y administrar la información sobre el DAG que puede cambiar
rápidamente, como el estado de montaje de la base de datos, el estado de la
replicación y la última ubicación montada.

Creando DAG
Se puede crear un DAG mediante el asistente de 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, proporcione un nombre para el DAG y la configuración opcional del
servidor testigo y del directorio testigo. Además, puede asignar una o más
direcciones IP al DAG, ya sea utilizando direcciones IP estáticas o permitiendo que
se asignen automáticamente al DAG las direcciones IP necesarias mediante el
Protocolo de configuración dinámica de host (DHCP). Puede asignar direcciones IP
manualmente al DAG mediante el parámetro DatabaseAvailabilityGroupIpAddresses . Si
omite este parámetro, el DAG intenta obtener una dirección IP utilizando un
servidor DHCP en su red.

Si está creando 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 de 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 del núcleo del
clúster no contendrá un recurso de nombre de red o un recurso de dirección IP.

Para conocer los pasos detallados sobre cómo crear un DAG, consulte Crear un grupo
de disponibilidad de base de datos .

Cuando crea un DAG, se crea un objeto vacío que representa el DAG con el nombre que
especificó y una clase de objeto de msExchMDBAvailabilityGroup en Active Directory.

Los DAG utilizan 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 del clúster y la base de datos del 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 al revés, o de montado a desmontado
o al revés). Por lo tanto, puede crear DAG solo en servidores de buzones de correo
de Exchange instalados en versiones compatibles de Windows que incluyan clústeres
de conmutación por error de Windows.

Nota

El clúster de conmutación por error creado y utilizado por el DAG debe estar
dedicado al DAG. El clúster no se puede utilizar para ninguna otra solución de alta
disponibilidad ni para ningún otro propósito. Por ejemplo, el clúster de
conmutación por error no se puede utilizar para agrupar otras aplicaciones o
servicios. No se admite el uso de un clúster de conmutación por error subyacente de
un DAG para fines distintos del DAG.

Servidor testigo DAG y directorio testigo

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

Nota

En la topología de creación de reflejo de la base de datos, puede tener un tercer

servidor llamado testigo. El servidor testigo habilita la conmutación por error
automática del principal al servidor reflejado o viceversa. A diferencia de los
servidores principal y reflejado, el servidor testigo no sirve a la base de datos.
La función del testigo es verificar si un servidor asociado determinado está activo
y funcionando. La compatibilidad con la conmutación por error automática 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 solo servidor puede servir como testigo para varios DAG. Sin embargo, cada DAG
requiere su propio directorio de testigos.

Independientemente del servidor que se utilice como servidor testigo, si el

Firewall de Windows está habilitado en el servidor testigo previsto, debe habilitar
la excepción del Firewall de Windows para Compartir archivos e impresoras. El
servidor testigo utiliza el puerto SMB 445.

Importante

Si el servidor testigo que especifica 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 garantizar
que Exchange pueda crear un directorio y compartir en el servidor testigo según sea
necesario.
Ni el servidor testigo ni el directorio testigo deben ser tolerantes a errores ni
utilizar ninguna forma de redundancia o alta disponibilidad. No es necesario
utilizar un servidor de archivos en clúster para el servidor testigo ni emplear
ninguna otra forma de resistencia para el servidor testigo. Hay varias razones para
esto. Con DAG más grandes (por ejemplo, seis miembros o más), se requieren varios
errores antes de que se necesite el servidor testigo. Debido a que un DAG de seis
miembros puede tolerar hasta dos fallas de votantes sin perder el quórum, se
necesitarían hasta tres votantes que fallan antes de que se necesite el servidor
testigo para mantener el quórum. Además, si hay una falla que afecta su servidor
testigo actual (por ejemplo, pierde el servidor testigo debido a una falla de
hardware), puede usar Set-DatabaseAvailabilityGroup cmdlet para configurar un nuevo
servidor testigo y un directorio testigo (siempre que tenga quórum).

Nota

También 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
compartió los permisos.

Consideraciones sobre la ubicación del servidor testigo

La ubicación del servidor testigo de un DAG dependerá de los requisitos de su
negocio y de las opciones disponibles para su organización. Exchange ahora incluye
soporte para 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 enumera las recomendaciones generales de ubicación del servidor

testigo para diferentes escenarios de implementación.

CONSIDERACIONES SOBRE LA UBICACIÓN DEL SERVIDOR TESTIGO

Escenario de implementación Recomendaciones
Un solo DAG implementado en un solo centro de datos Ubique el servidor testigo en
el mismo centro de datos que los miembros del DAG
DAG único implementado en dos centros de datos; no hay ubicaciones adicionales
disponibles Ubique el servidor testigo en una red virtual de Microsoft Azure para
habilitar la conmutación por error automática del centro de datos, o
ubique el servidor testigo en el centro de datos principal
Múltiples DAG implementados en un solo centro de datos Ubique el servidor
testigo en el mismo centro de datos que los miembros del DAG. Las opciones
adicionales incluyen:
• Usar el mismo servidor testigo para varios DAG
• Usar un miembro del DAG para actuar como servidor testigo para un DAG diferente
Múltiples DAG implementados en dos centros de datos Ubique el servidor testigo en
una red virtual de Microsoft Azure para habilitar la conmutación por error
automática del centro de datos, o
busque el servidor testigo en el centro de datos que se considera principal para
cada DAG. Las opciones adicionales incluyen:
• Usar el mismo servidor testigo para varios DAG
• Usar un miembro del DAG para actuar como servidor testigo para un DAG diferente
DAG únicos o múltiples implementados en más de dos centros de datos En esta
configuración, el servidor testigo debe estar ubicado en el centro de datos donde
desea que exista la mayoría de los votos del quórum.
Cuando se ha implementado un DAG en dos centros de datos, ahora puede utilizar una
tercera ubicación para alojar el servidor testigo. Si su organización tiene una
tercera ubicación con una infraestructura de red que está aislada de las fallas de
red que afectan los dos centros de datos en los que se implementa su DAG, entonces
puede implementar el servidor testigo del DAG en esa tercera ubicación,
configurando así su DAG con la capacidad automáticamente las bases de datos de
conmutación por error al otro centro de datos en respuesta a un evento de falla a
nivel del centro de datos. Si su organización solo tiene dos ubicaciones físicas,
puede usar una red virtual de Microsoft Azure como tercera ubicación para colocar
su servidor testigo.

Especificar un servidor testigo y un directorio testigo durante la creación del DAG

Al crear un DAG, debe proporcionar un nombre para el DAG. Opcionalmente, también
puede especificar un servidor testigo y un directorio testigo.

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

comportamientos:

Puede especificar solo 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 de correo y crea automáticamente el directorio predeterminado
(% SystemDrive%: \ DAGFileShareWitness \ < DAGFQDN >) y el recurso compartido
predeterminado ( < DAGFQDN >) en ese servidor y utiliza ese servidor de acceso de
cliente como servidor testigo. Por ejemplo, considere el servidor testigo CAS3 en
el que se instaló el sistema operativo en la unidad C.Un DAG llamado DAG1 en el
dominio contoso.com usaría un directorio testigo predeterminado de C: \
DAGFileShareWitness \ DAG1.contoso.com, que compartirse como \ CAS3 \
DAG1.contoso.com.

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

Puede especificar un nombre para el DAG y el servidor testigo que desea usar y
dejar el campo del directorio de testigos en blanco. En este escenario, el
asistente crea el directorio predeterminado en el servidor testigo especificado.

Puede especificar un nombre para el DAG, dejar el campo del servidor testigo en
blanco y especificar el directorio que desea 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 ese servidor, comparte el directorio y usa ese servidor de acceso
de cliente como servidor testigo.

Cuando se forma un DAG, inicialmente usa el modelo de quórum Mayoría de nodo.

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

Nota

No se admite el uso de un recurso compartido de archivos que forma parte de un

espacio de nombres del Sistema de archivos distribuido (DFS).

Si el Firewall de Windows está habilitado en el servidor testigo antes de que se

cree el DAG, puede bloquear la creación del DAG. 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 genera un error. Si especifica un servidor testigo,
pero no un directorio testigo, 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 testigo, 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 el Firewall de Windows está habilitado en el servidor testigo después de que se

crea el DAG pero antes de que se agreguen los servidores, puede bloquear la adición
o eliminación de miembros del DAG. Si Firewall de Windows está habilitado en el
servidor testigo y no hay excepciones de firewall configuradas 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 el error y las advertencias anteriores, realice una de las siguientes
acciones:

Cree manualmente el directorio testigo y comparta en el servidor testigo, y asigne

el CNO para el control total del DAG para el directorio y el recurso compartido.

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

Deshabilite el Firewall de Windows.

Membresía DAG
Una vez creado un DAG, puede agregar o quitar servidores del DAG mediante el
asistente Administrar grupo de disponibilidad de base de datos en el centro de
administración de Exchange (EAC), o mediante los cmdlets Add-
DatabaseAvailabilityGroupServer o Remove-DatabaseAvailabilityGroupServer en el
Shell de administración de Exchange . Para conocer los pasos detallados sobre cómo
administrar la membresía del DAG, consulte Administrar la membresía del grupo de
disponibilidad de la base de datos .

Nota

Cada servidor de buzones de correo que es miembro de un DAG también es un nodo en

el clúster subyacente utilizado por el DAG. Como resultado, en cualquier momento,
un servidor de buzones de correo puede ser miembro de un solo DAG.

Si el servidor de buzones de correo que se agrega a un DAG no tiene instalado el

componente de agrupación en clústeres de conmutación por error, el método utilizado
para agregar el servidor (por ejemplo, el cmdlet Add-
DatabaseAvailabilityGroupServer o el asistente Administrar grupo de disponibilidad
de base de datos) instala la función de agrupación en clústeres de conmutación por
error.

Cuando se agrega el primer servidor de buzones de correo a un DAG, ocurre lo

siguiente:
El componente de agrupación en clústeres de conmutación por error de Windows está
instalado, si aún no lo está.

Se crea un clúster de conmutación por error con el nombre del DAG. Este clúster de
conmutación por error lo usa exclusivamente el DAG y el clúster debe estar dedicado
al DAG. No se admite el uso del clúster para ningún otro propósito.

Se crea un CNO en el contenedor de equipos predeterminado.

El nombre y la dirección IP del DAG se registran como un registro de Host (A) en el

Sistema de nombres de dominio (DNS).

El servidor se agrega al objeto 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 de sitios grandes o múltiples, especialmente aquellos en los que el

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

Cuando el segundo servidor y los siguientes se agregan al DAG, ocurre lo siguiente:

El servidor está unido al clúster de conmutación por error de Windows para el DAG.

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

Se utiliza un modelo de quórum de mayoría de nodos para los DAG con un número impar
de miembros.

Se utiliza un modelo de quórum Mayoría de recurso compartido de archivos y nodos

para los DAG con un número par de miembros.

Exchange crea automáticamente el directorio de testigos y el recurso compartido

cuando es necesario.

El servidor se agrega al objeto DAG en Active Directory.

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

Nota

El cambio del modelo de quórum debería ocurrir automáticamente. Sin embargo, si el

modelo de quórum no cambia automáticamente al modelo adecuado, puede ejecutar el
cmdlet Set-DatabaseAvailabilityGroup solo con el parámetro Identity para corregir
la configuración del quórum para el DAG.

Preparar previamente el objeto de nombre de clúster para un DAG

El CNO es una cuenta de computadora creada en Active Directory y asociada con el
recurso Nombre del clúster. El recurso Nombre del clúster está vinculado 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 grupo subyacente
del DAG y el CNO para ese grupo se realiza cuando el primer miembro se agrega al
DAG. Cuando se agrega el primer servidor al DAG, PowerShell remoto se pone en
contacto con el servicio de replicación de Microsoft Exchange en el servidor de
buzones de correo que se agrega. El servicio de replicación de Microsoft Exchange
instala la función de agrupación en clústeres 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 en el contexto de seguridad del
SISTEMA LOCAL, y '

Precaución

Si los miembros de su DAG ejecutan Windows Server 2012, debe preparar previamente
el CNO antes de agregar el primer servidor al DAG. Si los miembros de su 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 que cree un CNO para el DAG.

En entornos donde la creación de cuentas de computadora está restringida, o donde

las cuentas de computadora se crean en un contenedor que no sea el contenedor de
computadoras predeterminado, puede preparar y aprovisionar el CNO. Usted crea y
deshabilita una cuenta de computadora para el CNO, y luego:

Asigne el control total de la cuenta de la computadora a la cuenta de la

computadora del primer servidor de buzones de correo que está agregando al DAG.

Asigne el control total de la cuenta de la computadora al USG del subsistema de

confianza de Exchange.

Asignar el control total de la cuenta de la computadora a la cuenta de la

computadora del primer servidor de buzones de correo que está agregando al DAG
garantiza que el contexto de seguridad del SISTEMA LOCAL podrá administrar la
cuenta de la computadora preconfigurada. En su lugar, se puede asignar el control
total de la cuenta de la computadora al USG del subsistema de confianza de Exchange
porque el USG del subsistema de confianza de Exchange contiene las cuentas de
máquina de todos los servidores de Exchange en el dominio.

Para conocer los pasos detallados sobre cómo preparar previamente y aprovisionar el
CNO para un DAG, consulte Preparar el objeto de nombre de clúster para un grupo de
disponibilidad de base de datos .

Eliminar servidores de un DAG

Los servidores de buzones de correo se pueden quitar de un DAG mediante el
asistente Administrar grupo 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 un servidor de buzones de correo pueda eliminarse de un DAG,
todas las bases de datos de buzones de correo replicadas primero deben eliminarse
del servidor. Si intenta eliminar un servidor de buzones de correo con bases de
datos de buzones de correo replicadas de un DAG, la tarea falla.

Hay escenarios en los que debe eliminar un servidor de buzones de correo de un DAG
antes de realizar determinadas operaciones. Estos escenarios incluyen:

Realización de una operación de recuperación del servidor : si un servidor de

buzones de correo que es miembro de un DAG se pierde, o falla por cualquier otro
motivo y es irrecuperable y necesita ser reemplazado, puede realizar una operación
de recuperación del servidor mediante el conmutador Setup / m: RecoverServer . Sin
embargo, antes de 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 .

Eliminación del grupo de disponibilidad de la base de datos : puede haber

situaciones en las que necesite eliminar un DAG (por ejemplo, al deshabilitar el
modo de replicación de terceros). Si necesita eliminar un DAG, primero debe
eliminar todos los servidores del DAG. Si intenta eliminar un DAG que contiene
miembros, la tarea falla.

Configurar las propiedades de DAG

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

Las propiedades configurables incluyen:

Servidor testigo : el nombre del servidor en el que desea alojar el recurso

compartido de archivos para el testigo del recurso compartido de archivos. Le
recomendamos que especifique un servidor de acceso de cliente como servidor
testigo. Esto permite que el sistema configure, proteja y utilice automáticamente
el recurso compartido, según sea necesario, y permite al administrador de
mensajería conocer la disponibilidad del servidor testigo.

Directorio de testigos : el nombre de un directorio que se utilizará para almacenar

datos de testigos de archivos compartidos. El sistema creará automáticamente este
directorio en el servidor testigo especificado.

Direcciones IP del grupo de disponibilidad de la base de datos : se deben asignar

una o más direcciones IP al DAG, a menos que los miembros del DAG estén ejecutando
Windows Server 2012 R2 y usted esté creando un DAG sin una dirección IP. De lo
contrario, las direcciones IP del DAG se pueden configurar utilizando direcciones
IP estáticas asignadas manualmente, o se pueden asignar automáticamente al DAG
mediante un servidor DHCP en su organización.

El Shell de administración de Exchange le permite configurar las propiedades del

DAG que no están disponibles en el EAC, como las direcciones IP del DAG, la
configuración de cifrado y compresión de la red, el descubrimiento de la 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 Coordinación de
activación del centro de datos.

Para conocer los pasos detallados sobre cómo configurar las propiedades del DAG,
consulte Configurar las propiedades del grupo de disponibilidad de la base de datos
.

Cifrado de red DAG

Los DAG admiten el uso de cifrado aprovechando las capacidades de cifrado del
sistema operativo Windows Server. Los DAG utilizan la autenticación Kerberos entre
servidores de Exchange. Las API EncryptMessage y DecryptMessage del proveedor de
soporte de seguridad (SSP) de Microsoft Kerberos manejan el cifrado del tráfico de
red DAG. Microsoft Kerberos SSP admite varios algoritmos de cifrado. (Para obtener
la lista completa, consulte la sección 3.1.5.2, "Tipos de cifrado" de las
extensiones del protocolo Kerberos ). El protocolo de enlace de autenticación
Kerberos selecciona el protocolo de cifrado más fuerte 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, consulte HMAC .
El cifrado de red es una propiedad del DAG y no una red del DAG. Puede configurar
el cifrado de red DAG mediante el cmdlet Set-DatabaseAvailabilityGroup en el Shell
de administración de Exchange. Las posibles configuraciones de cifrado para las
comunicaciones de red DAG se muestran en la siguiente tabla.

CIFRADO DE RED DAG

Configuración Descripción
Discapacitado No se utiliza el cifrado de red.
Activado El cifrado de red se utiliza en todas las redes DAG para la replicación
y la siembra.
InterSubnetOnly El cifrado de red se usa en redes DAG cuando se replica en
diferentes subredes. Ésta es la configuración predeterminada.
Semilla El cifrado de red se utiliza en todas las redes DAG solo para la
siembra.
Compresión de red DAG
Los DAG admiten la compresión incorporada. Cuando la compresión está habilitada, la
comunicación de red DAG usa XPRESS, que es la implementación de Microsoft del
algoritmo LZ77. Este es el mismo tipo de compresión que se utiliza en muchos
protocolos de Microsoft, en particular, la compresión MAPI RPC entre Microsoft
Outlook y Exchange.

Al igual que con el cifrado de red, la compresión de red también es propiedad del
DAG y no de una red DAG. La compresión de red DAG se configura mediante el cmdlet
Set-DatabaseAvailabilityGroup en el Shell de administración de Exchange. Los
posibles ajustes de compresión para las comunicaciones de red DAG se muestran en la
siguiente tabla.

COMPRESIÓN DE RED DAG

Configuración Descripción
Discapacitado No se utiliza la compresión de red.
Activado La compresión de red se utiliza en todas las redes DAG para la
replicación y la siembra.
InterSubnetOnly La compresión de red se usa en redes DAG cuando se replica en
diferentes subredes. Ésta es la configuración predeterminada.
Semilla La compresión de red se utiliza en todas las redes DAG solo para la
inicialización.
Redes DAG
Una red DAG es una colección de una o más subredes que se utilizan para el tráfico
de replicación o el tráfico MAPI. Cada DAG contiene un máximo de una red MAPI y
cero o más redes de replicación. En una configuración de adaptador de red único, la
red se utiliza tanto para el tráfico MAPI como para el tráfico de replicación.
Aunque se admite un único adaptador de red y una ruta, recomendamos que cada DAG
tenga un mínimo de dos redes DAG. En una configuración de dos redes, una red
normalmente se dedica al tráfico de replicación y la otra red se utiliza
principalmente para el tráfico MAPI. También puede agregar adaptadores de red a
cada miembro de DAG y configurar redes de DAG adicionales como redes de
replicación.

Nota

Cuando se utilizan varias redes de replicación, no hay forma de especificar un

orden de precedencia para el uso de la red. Exchange selecciona aleatoriamente una
red de replicación del grupo de redes de replicación para usarla para el trasvase
de registros.

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

Potencia Shell

Dupdo
Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true
Una vez que haya habilitado la configuración de red DAG manual, puede usar el
cmdlet New-DatabaseAvailabilityGroupNetwork en el Shell de administración de
Exchange para crear una red DAG. Para conocer los pasos detallados sobre cómo crear
una red DAG, consulte Crear una red de grupo 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 del DAG. Para
conocer los pasos detallados sobre cómo configurar las propiedades de red del DAG,
consulte Configurar las propiedades de red del grupo de disponibilidad de la base
de datos . Cada red 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 la red : una descripción opcional para la red DAG de hasta 256
caracteres.

Subredes de red : una o más subredes ingresadas con un formato de dirección IP /

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 Protocolo de Internet versión 6
(IPv6) subredes).

Habilitar la replicación : en el EAC, seleccione la casilla de verificación para

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

Nota

La desactivación de la replicación para la red MAPI no garantiza que el sistema no

utilice la red MAPI para la replicación. Cuando todas las redes de replicación
configuradas están fuera de línea, fallaron o no están disponibles, y solo queda la
red MAPI (que está configurada como deshabilitada para la replicación), el sistema
usa la red MAPI para la replicación.

Las redes DAG iniciales (por ejemplo, MapiDagNetwork y ReplicationDagNetwork01)

creadas por el sistema se basan en las subredes enumeradas por el servicio de
Cluster Server. Cada miembro del DAG debe tener la misma cantidad de adaptadores de
red 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
direcciones IP en un miembro de DAG específico deben estar en una subred única.
Además, solo el adaptador utilizado para la red MAPI debe configurarse con una
puerta de enlace predeterminada. Las redes de replicación no deben configurarse 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 una red de
replicación). En la siguiente tabla se muestran ejemplos de ajustes de
configuración de dirección IP.
Ejemplo de configuración del adaptador de red

CUADRO 4
Adaptador de red de servidor Dirección IP / máscara de subred Puerta de enlace
predeterminada
EX1-MAPI 192.168.1.15/24 192.168.1.1
EX1-Replicación 10.0.0.15/24 No aplica
EX2-MAPI 192.168.1.16 192.168.1.1
EX2-Replicación 10.0.0.16 No aplica
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 DAG: MapiDagNetwork (192.168.1.0) y ReplicationDagNetwork01
(10.0.0.0). Estas redes se configurarán como se muestra en la siguiente tabla.

Configuración de red de DAG enumerada para un DAG de subred única

CUADRO 5
Nombre Subredes Interfaces Acceso MAPI habilitado Replicación habilitada
MapiDagNetwork 192.168.1.0/24 EX1 (192.168.1.15)
EX2 (192.168.1.16) Cierto Cierto
ReplicationDagNetwork01 10.0.0.0/24 EX1 (10.0.0.15)
EX2 (10.0.0.16) Falso Cierto
Para completar la configuración de ReplicationDagNetwork01 como la red de
replicación dedicada, desactive la replicación para MapiDagNetwork ejecutando el
siguiente comando.

Potencia Shell

Dupdo
Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\MapiDagNetwork
-ReplicationEnabled:$false
Una vez deshabilitada la replicación para MapiDagNetwork, el servicio de
replicación de Microsoft Exchange usa ReplicationDagNetwork01 para la replicación
continua. Si ReplicationDagNetwork01 experimenta una falla, el servicio de
replicación de Microsoft Exchange vuelve a usar MapiDagNetwork para la replicación
continua. Esto lo hace intencionalmente el sistema para mantener una alta
disponibilidad.

Redes DAG e implementaciones de subredes múltiples

En el ejemplo anterior, aunque hay dos subredes diferentes en uso por el DAG
(192.168.1.0 y 10.0.0.0), el DAG se considera un DAG de subred única porque cada
miembro usa la misma subred para formar la red MAPI. Cuando los miembros de DAG
utilizan subredes diferentes para la red MAPI, el DAG se denomina DAG de subredes
múltiples . En un DAG de varias subredes, las subredes adecuadas se asocian
automáticamente con cada red de DAG.

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

Ejemplo de configuración de adaptador de red para un DAG de varias subredes

REDES DAG E IMPLEMENTACIONES DE SUBREDES MÚLTIPLES

Adaptador de red de servidor Dirección IP / máscara de subred Puerta de enlace
predeterminada
EX1-MAPI 192.168.0.15/24 192.168.0.1
EX1-Replicación 10.0.0.15/24 No aplica
EX2-MAPI 192.168.1.15 192.168.1.1
EX2-Replicación 10.0.1.15 No aplica
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 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 siguiente tabla.

Configuración de red de DAG enumerada para un DAG de varias subredes

TABLA 7
Nombre Subredes Interfaces Acceso 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) Cierto Cierto
ReplicationDagNetwork01 10.0.0.0/24
10.0.1.0/24 EX1 (10.0.0.15)
EX2 (10.0.1.15) Falso Cierto
Redes DAG y redes iSCSI
De forma predeterminada, los DAG realizan el descubrimiento de todas las redes
detectadas y configuradas para que las utilice el clúster subyacente. Esto incluye
cualquier red SCSI de Internet (iSCSI) en uso como resultado del uso de
almacenamiento iSCSI para uno o más miembros de DAG. Como práctica recomendada, el
almacenamiento iSCSI debe utilizar redes dedicadas y adaptadores de red. Estas
redes no deben ser administradas por el DAG o su clúster, ni deben usarse como
redes DAG (MAPI o replicación). En cambio, el DAG debe inhabilitar manualmente
estas redes para que puedan dedicarse al tráfico de almacenamiento iSCSI. Para
evitar que las redes iSCSI se detecten y utilicen como redes DAG, configure el DAG
para ignorar las redes iSCSI detectadas actualmente mediante el cmdlet Set-
DatabaseAvailabilityGroupNetwork , como se muestra en este ejemplo:

Potencia Shell

Dupdo
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02
-ReplicationEnabled:$false -IgnoreNetwork:$true
Este comando también deshabilitará la red para que la utilice el clúster. Aunque
las redes iSCSI seguirán apareciendo como redes DAG, no se utilizarán para el
tráfico MAPI o de replicación después de ejecutar el comando anterior.

Configuración de miembros de DAG

Los servidores de buzones de correo que son miembros de un DAG tienen algunas
propiedades específicas de alta disponibilidad que deben configurarse como se
describe en las siguientes secciones:

Dial de montaje de base de datos automático

Política de activación automática de copia de base de datos

Máximo de bases de datos activas

Dial de montaje de base de datos automático

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

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 a 12. La longitud de la cola de copia es el
número de registros reconocidos por la copia pasiva que necesita ser replicada. Si
la longitud de la cola de copia es superior a 12, la base de datos no se monta
automáticamente. Cuando la longitud de la cola de copia es menor o igual a 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 a seis. 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 seis, la base de datos no se monta
automáticamente. Cuando la longitud de la cola de copia es menor o igual a seis,
Exchange intenta replicar los registros restantes en la copia pasiva y monta la
base de datos.

Lossless: Si especifica este valor, la base de datos no se monta automáticamente

hasta que todos los registros generados en la copia activa se hayan copiado en la
copia pasiva. Esta configuración también hace que el algoritmo de selección de la
mejor copia de Active Manager clasifique los candidatos potenciales para la
activación según el valor de preferencia de activación de la copia de la base de
datos y no la longitud de la cola de copia.

El valor predeterminado es GoodAvailability. Si especifica BestAvailabilityo

GoodAvailability, y todos los registros de la copia activa no se pueden copiar a la
copia pasiva que se está activando, es posible que pierda algunos datos del buzón.
Sin embargo, la función de red de seguridad (que está habilitada de manera
predeterminada) ayuda a proteger contra la mayoría de las pérdidas de datos al
volver a enviar los mensajes que están en la cola de la red de seguridad.

Ejemplo: configurar el dial de montaje de base de datos automático

El siguiente ejemplo configura un servidor de buzones de correo con una
configuración de AutoDatabaseMountDial de GoodAvailability.

Potencia Shell

Dupdo
Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability
Política de activación automática de copia de base de datos
El parámetro DatabaseCopyAutoActivationPolicy especifica el tipo de activación
automática disponible para las copias de la base 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 siguientes valores:

Blocked: Si especifica este valor, las bases de datos no se pueden activar

automáticamente en los servidores de buzones de correo seleccionados.

IntrasiteOnly: Si especifica este valor, la copia de la base de datos puede

activarse en los servidores del mismo sitio de Active Directory. Esto evita la
conmutación por error o la activación entre sitios. Esta propiedad es para copias
de bases de datos de buzones de correo entrantes (por ejemplo, una copia pasiva se
convierte en una copia activa). Las bases de datos no se pueden activar en este
servidor de buzones de correo para las copias de bases de datos que están activas
en otro sitio de Active Directory.

Unrestricted: Si especifica este valor, no existen restricciones especiales para

activar copias de la base de datos de buzones de correo en los servidores de
buzones de correo seleccionados.
Ejemplo: configuración de la política de activación automática de copia de base de
datos
El siguiente ejemplo configura un servidor de buzones de correo con un valor de
DatabaseCopyAutoActivationPolicy de Blocked.

Potencia Shell

Dupdo
Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked
Máximo de bases de datos activas
El parámetro MaximumActiveDatabases (que también se usa con el cmdlet Set-
MailboxServer ) especifica el número de bases de datos que se pueden montar en un
servidor de buzones de correo. Puede configurar los servidores de buzones de correo
para que cumplan sus requisitos de implementación asegurándose de que un servidor
de buzones de correo 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 una conmutación por error o una conmutación.
Si las copias ya están activas en un servidor, el servidor no permitirá que se
monten las bases de datos.

Ejemplo: configurar el máximo de bases de datos activas

El siguiente ejemplo configura un servidor de buzones de correo para admitir un
máximo de 20 bases de datos activas.

Potencia Shell

Dupdo
Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20
Realización de mantenimiento en miembros de DAG
Antes de realizar cualquier tipo de mantenimiento de software o hardware en un
miembro de DAG, primero debe poner el miembro de DAG en modo de mantenimiento. Los
siguientes scripts 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

fuera del servidor. También mueve todas las funciones críticas de soporte de DAG,
como la función de administrador activo principal (PAM), y evita que regresen al
servidor antes de que se complete el mantenimiento.

StopDagServerMaintenance.ps1 : ayuda a sacar al miembro del DAG del modo de

mantenimiento y convertirlo en un objetivo activo para todas las bases de datos y
todas las funciones críticas de soporte del 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 el parámetro
WhatIf . Ambos scripts se pueden ejecutar de forma local o remota. El servidor en
el que se ejecutan los scripts debe tener instaladas las herramientas de
administración de clústeres de conmutación por error de Windows (RSAT-Clustering).

Nota

El RedistributeActiveDatabases.ps1 guión también es elección, que ayuda con el

montaje de las bases de datos de buzones a miembros específicos del DAG como
inidicated por el número de activación de preferencia en cada base de datos. Sin
embargo, en Exchange 2016 CU2 o posterior, la nueva propiedad de DAG denominada
PreferenceMoveFrequency equilibra automáticamente las copias de la base de datos en
un DAG. Por lo tanto, solo necesitará usar RedistributeActiveDatabases.ps1 si ha
deshabilitado esta funcionalidad o si desea balancear las copias de la base de
datos manualmente.

El script StartDagServerMaintenance.ps1 realiza las siguientes tareas:

Establece el valor del parámetro DatabaseCopyAutoActivationPolicy en el miembro DAG

en Blocked, lo que evita que se activen las copias de la base de datos en el
servidor.

Pausa el nodo en el clúster, lo que evita que el nodo sea y se convierta en el 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, la

secuencia de comandos mueve el grupo de clúster predeterminado (y, por lo tanto, la
función de PAM) a otro miembro de DAG.

Si alguna de las tareas anteriores falla, el script deshace todas las operaciones,
excepto los movimientos de base de datos exitosos.

Para comenzar los procedimientos de mantenimiento en un miembro de DAG, incluido el

vaciado de las colas de transporte y la suspensión de la conectividad del cliente,
realice las siguientes tareas:

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

Potencia Shell

Dupdo
Set-ServerComponentState <ServerName> -Component HubTransport -State Draining
-Requester Maintenance
Para iniciar el vaciado de las colas de transporte, ejecute el siguiente comando:

Potencia Shell

Dupdo
Restart-Service MSExchangeTransport
Para comenzar el proceso de drenaje de todas las llamadas de mensajería unificada
(solo en Exchange 2016), ejecute el siguiente comando:

Potencia Shell

Dupdo
Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining
-Requester Maintenance
Para acceder a los scripts de mantenimiento de DAG, ejecute el siguiente comando:

Potencia Shell

Dupdo
CD $ExScripts
Para ejecutar el script StartDagServerMaintenance.ps1, ejecute el siguiente
comando:

Potencia Shell

Dupdo
.\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance
-PauseClusterNode
Para el valor del parámetro MoveComment , puede realizar la notación que desee. El
ejemplo anterior usa "Mantenimiento".

Nota

Esta secuencia de comandos puede tardar un tiempo en ejecutarse y, durante este

tiempo, es posible que no vea ninguna actividad en la pantalla.

Para redirigir los mensajes pendientes de entrega en las colas locales al servidor
Exchange especificado por el parámetro Target, ejecute

Potencia Shell

Dupdo
Redirect-Message -Server <ServerName> -Target <Server FQDN>
Para poner el servidor en modo de mantenimiento, ejecute:

Potencia Shell

Dupdo
Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive
-Requester Maintenance
Para verificar que un servidor está listo para el mantenimiento, realice las
siguientes tareas:

Para verificar que el servidor se haya puesto en modo de mantenimiento, confirme

que solo Monitoringy RecoveryActionsEnabledestén en estado Activo cuando ejecute el
siguiente comando:

Potencia Shell

Dupdo
Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize
Para verificar que el servidor no aloja ninguna copia activa de la base de datos,
ejecute:

Potencia Shell

Dupdo
Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy
Para verificar que el nodo del clúster esté en pausa, ejecute:

Potencia Shell

Dupdo
Get-ClusterNode <ServerName> | Format-List
Para verificar que se hayan vaciado todas las colas de transporte, ejecute:

Potencia Shell

Dupdo
Get-Queue
Una vez que se completa el mantenimiento y el miembro del DAG está listo para
volver al servicio, el script StopDagServerMaintenance.ps1 ayuda a sacar al miembro
del DAG del modo de mantenimiento y volverlo a poner en producción. El script
StopDagServerMaintenance.ps1 realiza las siguientes tareas:
Reanuda el nodo en el clúster, lo que habilita la funcionalidad completa del
clúster para el miembro del DAG.

Establece el valor del parámetro DatabaseCopyAutoActivationPolicy en el miembro DAG

en Unrestricted.

Ejecuta el cmdlet Resume-MailboxDatabaseCopy para cada copia de base de datos

alojada en el miembro de DAG.

When you're ready to restore the DAG member to full production status, including
resuming the transport queues and client connectivity, perform the following tasks:

To configure the server as out of maintenance mode and ready to accept client
connections, run:

PowerShell

Copy
Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active
-Requester Maintenance
To allow the server to accept Unified Messaging calls (in Exchange 2016 only), run:

PowerShell

Copy
Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active
-Requester Maintenance
To access the DAG maintenance scripts, run the following command:

PowerShell

Copy
CD $ExScripts
To execute the StopDagServerMaintenance.ps1 script, run:

PowerShell

Copy
.\StopDagServerMaintenance.ps1 -serverName <ServerName>
To enable the transport queues to resume accepting and processing messages, run:

PowerShell

Copy
Set-ServerComponentState <ServerName> -Component HubTransport -State Active
-Requester Maintenance
To resume transport activity, run:

PowerShell

Copy
Restart-Service MSExchangeTransport
To verify that a server is ready for production use, perform the following tasks:

To verify the server is not in maintenance mode, run

PowerShell

Copy
Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize
If you're installing an Exchange update, and the update process fails, it can leave
some server components in an inactive state, which will be displayed in the output
of the above Get-ServerComponentState cmdlet. To resolve this, run the following
commands:

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

-Requester Functional

Set-ServerComponentState <ServerName> -Component Monitoring -State Active

-Requester Functional

Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State

Active -Requester Functional

Shutting down DAG members

Exchange high availability solution is integrated with the Windows shutdown
process. If an administrator or application initiates a shutdown of a Windows
server in a DAG that has a mounted database that's replicated to one or more DAG
members, the system attempts to activate another copy of the mounted database prior
to allowing the shutdown process to complete.

However, this new behavior doesn't guarantee that all of the databases on the
server being shut down will experience a lossless activation. As a result, it's a
best practice to perform a server switchover prior to shutting down a server that's
a member of a DAG.

Installing updates on DAG members

Installing Exchange updates on a server that's a member of a DAG is a relatively
straightforward process. When you install an update on a server that's a member of
a DAG, several services are stopped during the installation, including all Exchange
services and the Cluster service. The general process for applying updates to a DAG
member is as follows:

Use the steps described above to put the DAG member in maintenance mode.

Install the update.

Use the steps described above to take the DAG member out of maintenance mode and
put it back into production.

Optionally, use the RedistributeActiveDatabases.ps1 script to rebalance the active

database copies across the DAG.

For more information about the latest Exchange updates, see Exchange Server build
numbers and release dates.

Recommended content
Exchange 2013 storage configuration options: Exchange 2013 Help
Mount-Database (ExchangePowerShell)
Debe tener asignados permisos antes de poder ejecutar este cmdlet. Aunque este tema
enumera todos los parámetros del cmdlet, es posible que no tenga acceso a algunos
parámetros si no están incluidos en los permisos que se le asignaron. Para
encontrar los permisos necesarios para ejecutar cualquier cmdlet o parámetro en su
organización, consulte Buscar los permisos necesarios para ejecutar cualquier
cmdlet de Exchange.

Administrar bases de datos de buzones de correo en Exchange Server

Resumen: aprenda a realizar tareas de configuración relacionadas con la
administración de las bases de datos de su buzón en Exchange Server.

Ingrese su clave de producto de Exchange Server

Resumen: aprenda a ingresar la clave de producto después de instalar Exchange 2016
o Exchange 2019.