Supervisión de la alta disponibilidad y la resistencia de sitios
Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Última modificación del tema: 2015-03-09
Asegurarse de que los servidores funcionan de forma confiable y que las copias de base de datos están en buen estado son los objetivos clave para las operaciones diarias de mensajería. Para contribuir a garantizar la disponibilidad y confiabilidad de su organización de Microsoft Exchange Server 2010, deberá supervisar activamente el hardware, el sistema operativo de Windows y los servicios de Exchange 2010. La supervisión proactiva combinada con un mantenimiento preventivo le puede ayudar a identificar errores potenciales antes de que se produzca un problema grave que interfiera con el funcionamiento de la organización de Exchange.
La supervisión de la organización de Exchange implica la comprobación regular de problemas relacionados con servicios o datos. La supervisión suele incluir un sistema de notificaciones que envía advertencias cuando se producen problemas. Windows Server 2008 y Exchange 2010 incluyen algunas herramientas y servicios que le ayudan a garantizar que la organización de Exchange funciona sin problemas. Las principales ventajas respecto a la supervisión diaria son:
Se cumplen los requisitos de los acuerdos de nivel de servicio (SLA).
Se puede garantizar que las tareas administrativas específicas se completan correctamente (por ejemplo, las operaciones diarias de copia de seguridad)
Se detectan y resuelven los problemas (por ejemplo, problemas que pueden afectar al servicio de mensajería o a la disponibilidad de datos)
Dentro de una organización de Exchange 2010, se deben formalizar los procedimientos, las funciones y las responsabilidades implicadas en las operaciones. Es importante comprender la relación entre el uso de prácticas y procedimientos eficaces y el buen estado de una infraestructura. Los procesos y procedimientos operativos completos y bien documentados ayudan a garantizar que todos los componentes del entorno de una organización de los que depende Exchange se administren de un modo eficaz y eficiente.
Exchange 2010 incluye varias herramientas, scripts y características integrados que se pueden usar como parte de la supervisión proactiva regular cuando se configura Exchange para alta disponibilidad y resistencia de sitios. Los cmdlets de supervisión principales para la alta disponibilidad y la resistencia de sitios son Get-MailboxDatabaseCopyStatus y Test-ReplicationHealth. Además de disponer de cmdlets que realizan funciones de supervisión e informan sobre el estado, Exchange 2010 también incorpora una nueva secuencia de registro de eventos que permite aprovechar las capacidades del canal Crimson de Windows Server, así como scripts integrados que recopilan y analizan datos de dichos canales de eventos.
Puede usar la información de este tema para supervisar el estado de mantenimiento de las copias de la base de datos de buzones para grupos de disponibilidad de base de datos (DAG).
Contenido
Cmdlet Get-MailboxDatabaseCopyStatus
Cmdlet Test-ReplicationHealth
Registro de eventos de canal Crimson
Script CollectOverMetrics.ps1
Script de CollectReplicationMetrics.ps1
Script CheckDatabaseRedundancy.ps1
Cmdlet Get-MailboxDatabaseCopyStatus
Puede usar el cmdlet Get-MailboxDatabaseCopyStatus para ver información de estado de las copias de bases de datos de buzones. Este cmdlet permite ver información sobre todas las copias de una base de datos determinada, información sobre una copia específica de una base de datos en un servidor determinado o información sobre todas las copias de bases de datos de un servidor. La tabla siguiente describe los posibles valores del estado de una copia de base de datos de buzones de correo.
Estado de copia de base de datos
| Estado de copia de base de datos | Descripción |
|---|---|
Failed |
La copia de una base de datos de buzones de correo muestra el estado Failed (Error) porque no está suspendida, ni puede copiar o reproducir archivos de registro. Mientras su estado sea Failed y no esté suspendida, el sistema comprobará periódicamente si se ha resuelto el problema que hizo que el estado de la copia cambiara a Failed. Una vez que el sistema ha detectado que el problema se ha resuelto, y ha descartado otros problemas, el estado de la copia cambiará automáticamente a Healthy (Correcta). |
Inicialización |
La copia de base de datos se está propagando, el índice de contenido de la copia de base de datos de buzones se está propagando o ambos elementos se están propagando. Una vez completada correctamente la propagación, el estado de copia cambiará a Initializing (Inicializando). |
SeedingSource |
La copia de base de datos de buzón se está usando como origen de una operación de inicialización de copia de base de datos. |
Suspended |
La copia de base de datos de buzones de correo está en estado Suspended (Suspendida) porque un administrador ha suspendido de forma manual la copia de base de datos mediante la ejecución del cmdlet Suspend-MailboxDatabaseCopy. |
Healthy |
La copia de base de datos de buzones de correo está copiando y reproduciendo archivos de registro correctamente, o bien ha conseguido copiar y reproducir todos los archivos de registro disponibles. |
ServiceDown |
El servicio de replicación de Microsoft Exchange no está disponible o se está ejecutando en el servidor que hospeda la copia de base de datos de buzones. |
Initializing |
La copia de base de datos de buzones de correo estará en el estado de inicialización cuando se cree una copia de base de datos, cuando el servicio de replicación de Microsoft Exchange se esté iniciando o acabe de ser iniciado y durante las transiciones de los estados Suspended, ServiceDown, Failed, Seeding, SinglePageRestore, LostWrite o Disconnected a otro estado. Mientras permanece en este estado, el sistema verifica que la base de datos y la secuencia de registro sean coherentes. En la mayoría de los casos, el estado de la copia permanecerá en el estado Initializing durante unos 15 segundos, pero en general, no debería permanecer en dicho estado por más de 30 segundos. |
Resynchronizing |
La copia de base de datos de buzones y los archivos de registro correspondientes se están comparando con la copia activa de la base de datos para comprobar si existen divergencias entre las dos copias. El estado de la copia permanecerá así hasta que se detecte y resuelvan las divergencias. |
Mounted |
La copia activa está en línea y acepta conexiones de clientes. Solo la copia activa de la copia de base de datos de buzones puede tener el estado Mounted (montada). |
Dismounted |
La copia activa está sin conexión y no acepta conexiones de clientes. Solo la copia activa de la copia de base de datos de buzones puede tener el estado Dismounted (desmontada). |
Mounting |
La copia activa se está conectando y aún no acepta conexiones de clientes. Solo la copia activa de la copia de base de datos de buzones puede tener el estado Mounting (montando). |
Dismounting |
La copia activa se está desconectando y está cerrando las conexiones de clientes. Solo la copia activa de la copia de base de datos de buzones puede tener el estado Dismounting (desmontando). |
DisconnectedAndHealthy |
La copia de base de datos de buzones ya no está conectada a la copia de base de datos activa, y tenía el estado Healthy (correcta) cuando se perdió la conexión. Este estado define cómo está la copia de base de datos con respecto a la conectividad con su copia de origen. Puede notificarse durante los errores de red de DAG entre la copia de origen y la copia de base de datos de destino. |
DisconnectedAndResynchronizing |
La copia de base de datos de buzones ya no está conectada a la copia de base de datos activa, y tenía el estado Resynchronizing (volviendo a sincronizar) cuando se perdió la conexión. Este estado define cómo está la copia de base de datos con respecto a la conectividad con su copia de origen. Puede notificarse durante los errores de red de DAG entre la copia de origen y la copia de base de datos de destino. |
FailedAndSuspended |
El sistema establece los estados Failed (error) y Suspended (suspendida) simultáneamente porque se ha detectado un error y porque la resolución del error requiere la intervención expresa de un administrador. Un ejemplo sería cuando el sistema detecta divergencias irrecuperables entre la base de datos de buzones de correo activa y la copia de base de datos. A diferencia del estado Failed (error), el sistema no comprobará periódicamente si se ha resuelto el problema para recuperarse de forma automática. En su lugar, debe intervenir un administrador para resolver la causa subyacente del error antes de que la copia de base de datos pueda pasar al estado Healthy (correcta). |
SinglePageRestore |
Este estado indica que se está llevando a cabo una operación de restauración de página única en la copia de base de datos de buzones. |
El cmdlet Get-MailboxDatabaseCopyStatus también incluye un parámetro denominado ConnectionStatus, que devuelve datos sobre las redes de replicación en uso. Si usa este parámetro, se rellenarán dos campos de salida adicionales, IncomingLogCopyingNetwork y SeedingNetwork en el resultado de la tarea.
Ejemplos de Get-MailboxDatabaseCopyStatus
Los ejemplos siguientes usan el cmdlet Get-MailboxDatabaseCopyStatus. Cada ejemplo envía los resultados al cmdlet Format-List para que los muestre en formato de lista.
En este ejemplo se devuelve información de estado para todas las copias de la base de datos DB2.
Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List
En este ejemplo se devuelve el estado de todas las copias de base de datos del servidor de buzones MBX2.
Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List
En este ejemplo se devuelve el estado de todas las copias de base de datos del servidor de buzones local.
Get-MailboxDatabaseCopyStatus -Local | Format-List
En este ejemplo se devuelve el estado, el envío de registros y la información de redes de propagación de la base de datos DB3 del servidor de buzones MBX1.
Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List
Para obtener más información acerca del cmdlet Get-MailboxDatabaseCopyStatus, consulte Get-MailboxDatabaseCopyStatus.
Cmdlet Get-MailboxDatabaseCopyStatus
Cmdlet Test-ReplicationHealth
Puede usar el cmdlet Test-ReplicationHealth para ver información de estado de la replicación continua de copias de bases de datos de buzones. Use el cmdlet para comprobar todos los aspectos del estado de replicación y reproducción con el fin de proporcionar una descripción general completa de un servidor de buzones de correo concreto de un grupo de disponibilidad de base de datos (DAG).
El cmdlet Test-ReplicationHealth está diseñado para realizar una supervisión proactiva de la replicación continua y de la canalización de replicación continua, la disponibilidad de Active Manager, el estado y el mantenimiento del servicio de clúster subyacente, así como de los componentes de quórum y de red. Se puede ejecutar de forma local o remota en cualquier servidor de buzones de un grupo de disponibilidad de base de datos. El cmdlet Test-ReplicationHealth realiza las pruebas que se enumeran en la tabla siguiente.
Pruebas del cmdlet Test-ReplicationHealth
| Nombre de la prueba | Descripción |
|---|---|
ClusterService |
Verifica que el servicio de clúster se está ejecutando y está accesible en el miembro DAG especificado; y, si no se ha especificado ningún miembro DAG, en el servidor local. |
ReplayService |
Verifica que el servicio de replicación de Microsoft Exchange se está ejecutando y está accesible en el miembro DAG especificado; y, si no se ha especificado ningún miembro DAG, en el servidor local. |
ActiveManager |
Verifica que la instancia de Active Manager que se está ejecutando en el miembro DAG especificado (y si no se ha especificado un miembro DAG, en el servidor local) tiene asignado un rol válido (principal, secundario o independiente). |
TasksRpcListener |
Verifica que el servidor de llamada a procedimiento remoto (RPC) para tareas se está ejecutando y está accesible en el miembro DAG especificado; y, si no se ha especificado ningún miembro DAG, en el servidor local. |
TcpListener |
Verifica que el proceso de escucha de copias de registros TCP se está ejecutando y está accesible en el miembro DAG especificado; y, si no se ha especificado ningún miembro DAG, en el servidor local. |
DagMembersUp |
Verifica que todos los miembros DAG están disponibles, ejecutándose y accesibles. |
ClusterNetwork |
Verifica que todas las redes administradas por clúster del miembro DAG especificado (y si no se ha especificado ninguno, del servidor local) están disponibles. |
QuorumGroup |
Verifica que el grupo de clústeres (grupo de quórum) predeterminado está en buen estado y conectado. |
FileShareQuorum |
Verifica que el servidor testigo, el directorio testigo y el recurso compartido configurados para el grupo de disponibilidad de base de datos (DAG) están accesibles. |
DBCopySuspended |
Comprueba si hay alguna copia de base de datos de buzones de correo en el estado Suspended (suspendida) en el miembro DAG especificado; y, si no se ha especificado ningún miembro DAG, en el servidor local. |
DBCopyFailed |
Comprueba si hay alguna copia de base de datos de buzones de correo en el estado Failed (error) en el miembro DAG especificado; y, si no se ha especificado ningún miembro DAG, en el servidor local. |
DBInitializing |
Comprueba si hay alguna copia de base de datos de buzones de correo en el estado Initializing (inicializando) en el miembro DAG especificado; y, si no se ha especificado ningún miembro DAG, en el servidor local. |
DBDisconnected |
Comprueba si hay alguna copia de base de datos de buzones de correo en el estado Disconnected (desconectada) en el miembro DAG especificado; y, si no se ha especificado ningún miembro DAG, en el servidor local. |
DBLogCopyKeepingUp |
Verifica que el proceso de copia de registros e inspección de las copias pasivas de base de datos en el miembro DAG especificado (y si no se ha especificado ninguno, en el servidor local) consigue mantener la actividad de generación de registros en la copia activa. |
DBLogReplayKeepingUp |
Verifica que la actividad de reproducción de las copias pasivas de base de datos en el miembro DAG especificado (y si no se ha especificado ninguno, en el servidor local) consigue mantener la actividad de copia de registros y de inspección. |
Ejemplo de Test-ReplicationHealth
En este ejemplo se usa el cmdlet Test-ReplicationHealth para comprobar el mantenimiento de replicación del servidor de buzones de correo MBX1.
Test-ReplicationHealth -Identity MBX1
Cmdlet Get-MailboxDatabaseCopyStatus
Registro de eventos de canal Crimson
Windows Server 2008 incluye dos categorías de registros de eventos: Registros de Windows y registros de aplicaciones y servicios. La categoría de registros de Windows incluye los registros de eventos disponibles en versiones anteriores de Windows: Registros de eventos de aplicaciones, seguridad y sistema. También incluye dos nuevos registros: Setup y ForwardedEvents. Los registros de Windows tienen como objetivo almacenar eventos de aplicaciones heredadas y eventos que se aplican a todo el sistema.
Los registros de aplicaciones y servicios son una nueva categoría de registros de eventos. Estos registros almacenan eventos de una única aplicación o de un único componente, en lugar de eventos que pueden tener incidencia en todo el sistema. A esta nueva categoría de registros de eventos se alude como a un canal Crimson de aplicaciones.
La categoría de los registros de aplicaciones y servicios incluye cuatro subtipos: Registros administrativos, operativos, analíticos y de depuración. Los eventos de los registros administrativos son especialmente interesantes si el motivo por el que lleva un registro de eventos es para solucionar problemas. Los eventos en el registro administrativo deben proporcionar ayuda sobre cómo responder a los eventos. Los eventos del registro operativo también son útiles, pero quizá sea necesario un conocimiento más profundo. Los registros administrativos y de depuración no son especialmente sencillos para el usuario. Los registros analíticos (que aparecen ocultos o deshabilitados de manera predeterminada) almacenan eventos que hacen un seguimiento de un problema, y suele haber un número elevado de eventos registrado. Los registros de depuración son utilizados por los desarrolladores para depurar aplicaciones.
Exchange 2010 registra eventos en los canales Crimson del área de registros de aplicaciones y servicios. Puede ver estos canales si sigue los pasos que se detallan a continuación:
Abra el Visor de eventos:
En el árbol de la consola, vaya a Registros de aplicaciones y servicios > Microsoft > Exchange.
En Exchange, seleccione un canal Crimson: HighAvailability o MailboxDatabaseFailureItems.
El canal HighAvailability contiene eventos relacionados con el inicio y apagado del servicio de replicación de Microsoft Exchange, y los diferentes componentes que se ejecutan en el servicio de replicación de Microsoft Exchange, como Active Manager, una API de replicación sincrónica de otros fabricantes, el servidor RPC de tareas, el proceso de escucha TCP y el escritor del servicio de instantáneas de volumen (VSS). El canal HighAvailability también es utilizado por Active Manager para registrar eventos relacionados con la supervisión de funciones de Active Manager y eventos de acción de base de datos, como la operación de montaje de base de datos y la truncación de registros, y también para registrar eventos relacionados con el clúster subyacente del grupo de disponibilidad de bases de datos.
El canal MailboxDatabaseFailureItems se usa para registrar eventos asociados con errores que afectan a una base de datos de buzones de correo replicada.
Cmdlet Get-MailboxDatabaseCopyStatus
Script CollectOverMetrics.ps1
Exchange 2010 incluye un script denominado CollectOverMetrics.ps1, que puede encontrar en la carpeta Scripts. CollectOverMetrics.ps1 lee los registros de eventos de los miembros del DAG para recopilar información sobre las operaciones de base de datos (como montajes, movimientos y conmutación por error de bases de datos) durante un período de tiempo específico. Para cada operación, el script registra la información siguiente:
Identidad de la base de datos
La hora a la que ha comenzado y finalizado la operación
Los servidores en los que se había montado la base de datos al inicio y al final de la operación
La razón de la operación
Si la operación se ha completado correctamente o si ha dado error y, en tal caso, se incluyen los detalles del error.
Este script escriba la información en archivos .csv con una operación por fila. Escribe un archivo .csv por separado para cada DAG.
El script admite parámetros que permiten personalizar el comportamiento y los resultados del mismo. Por ejemplo, los resultados se pueden restringir a un subconjunto especificado mediante el parámetro Database o ReportFilter. Solamente se incluirán en el informe HTML de resumen las operaciones que coincidan con estos filtros. En la tabla siguiente se muestran los parámetros disponibles:
Parámetros del script CollectOverMetrics.ps1
| Parámetro | Descripción |
|---|---|
DatabaseAvailabilityGroup |
Especifica el nombre del grupo de disponibilidad de base de datos (DAG) de la que se va a recopilar la métrica. Si se omite este parámetro, se usará el DAG del que es miembro el servidor local. Se pueden usar caracteres comodín para recopilar información y notificar sobre varios DAG. |
Database |
Proporciona una lista de bases de datos para las que debe generarse el informe. Se admiten caracteres comodín, por ejemplo, |
StartTime |
Especifica la duración del período de tiempo sobre el que se debe realizar el informe. El script solamente recopila los eventos registrados durante dicho período. Por consiguiente, es posible que el script recopile registros de operaciones parciales (por ejemplo, solamente el final de una operación al inicio del período, o viceversa). Si no se especifica ningún valor para StartTime ni EndTime, el script registrará de forma predeterminada las últimas 24 horas. Si solamente se especifica un parámetro, el período será de 24 horas y empezará o finalizará a la hora especificada. |
EndTime |
Especifica la duración del período de tiempo sobre el que se debe realizar el informe. El script solamente recopila los eventos registrados durante dicho período. Por consiguiente, es posible que el script recopile registros de operaciones parciales (por ejemplo, solamente el final de una operación al inicio del período, o viceversa). Si no se especifica ningún valor para StartTime ni EndTime, el script registrará de forma predeterminada las últimas 24 horas. Si solamente se especifica un parámetro, el período será de 24 horas y empezará o finalizará a la hora especificada. |
ReportPath |
Especifica la carpeta usada para almacenar los resultados de procesamiento de eventos. Si se omite este parámetro, se usará la carpeta Scripts. Si se especifica, el script selecciona una lista de archivos .csv generada mediante el script y los usa como datos de origen para generar un informe HTML de resumen. El informe es el mismo que se genera con la opción -GenerateHtmlReport. Los archivos pueden generarse en varios grupos de disponibilidad de base de datos a distintas horas, o incluso con horas que se solapen, y el script unificará todos los datos. |
GenerateHtmlReport |
Especifica que el script recopile toda la información que ha registrado, agrupe los datos por tipo de operación y genere un archivo HTML que incluye estadísticas para cada uno de los grupos. El informe incluye el número total de operaciones de cada grupo, el número de operaciones que han dado error y estadísticas sobre el tiempo que se ha tardado en cada grupo. Asimismo, contiene un desglose de los distintos tipos de errores devueltos en las operaciones erróneas. |
ShowHtmlReport |
Especifica que el informe generado en HTML debe mostrarse en un explorador web una vez generado. |
SummariseCSVFiles |
Especifica que el script lea los datos de los archivos .csv existentes que se hayan generado anteriormente mediante el script. A continuación, estos datos se usan para generar un informen de resumen similar al informe que genera el parámetro GenerateHtmlReport. |
ActionType |
Especifica el tipo de acciones operativas que el script debe recopilar. Los valores de este parámetro son |
ActionTrigger |
Especifica las operaciones administrativas que debe recopilar el script. Los valores de este parámetro son |
RawOutput |
Especifica que el script debe escribir los resultados que deberían haberse escrito en los archivos .csv directamente en el flujo de salida, como sucedería con write-output. A continuación, esta información puede transferirse a otros comandos. |
IncludedExtendedEvents |
Especifica que el script debe recopilar los eventos que proporcionan datos de diagnóstico del tiempo tardado en montar las bases de datos. Esta fase puede llevar mucho tiempo si el registro de eventos de la aplicación en los servidores es demasiado grande. |
MergeCSVFiles |
Especifica que el script debe tomar todos los archivos .csv que contengan datos sobre cada operación y unificarlos en un solo archivo .csv. |
ReportFilter |
Especifica que se debe aplicar un filtro a las operaciones usando los campos tal y como aparecen en los archivos .csv. Este parámetro usa el mismo formato que una operación |
Ejemplos de CollectOverMetrics.ps1
En el ejemplo siguiente se recopila la métrica de todas las bases de datos que coinciden con DB* (la búsqueda incluye un carácter comodín) en un DAG denominado DAG1. Una vez recopilada la métrica, se genera y muestra un informe HTML.
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport
En los ejemplos siguientes se describen distintos métodos para filtrar el informe HTML de resumen. En el primero se usa el parámetro Database que toma una lista de nombres de bases de datos. El informe de resumen solamente contiene datos sobre estas bases de datos. En los dos ejemplos siguientes se usa la opción ReportFilter. En el último ejemplo se filtran todas las bases de datos predeterminadas.
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }
Cmdlet Get-MailboxDatabaseCopyStatus
Script de CollectReplicationMetrics.ps1
CollectReplicationMetrics.ps1 es otro script de métrica de estado incluido en Exchange 2010. Este script es un método activo de supervisión, porque recopila la métrica en tiempo real, mientras se ejecuta el script. CollectReplicationMetrics.ps1 recopila datos de contadores de rendimiento relacionados con la replicación de base de datos. El script reúne datos de varios servidores de buzones, escribe los datos de cada servidor en un archivo .csv y, a continuación, realiza un informe con varias estadísticas sobre todos los datos (por ejemplo, la cantidad de tiempo durante el cual cada copia estuvo en estado de error o suspendida, la longitud media de cola de copia o de reproducción, o la cantidad de tiempo durante el cual las copias no han cumplido los criterios de conmutación por error).
Puede especificar los servidores individualmente o bien especificar DAG enteros. Puede ejecutar el script para primero recopilar los datos y, a continuación, general el informe, o bien ejecutarlo para solamente reunir los datos o solamente generar el informe sobre los datos que ya se hayan recopilado. Puede especificar la frecuencia a la que debe realizarse el muestreo de los datos y la duración total para reunir los datos.
Los datos recopilados de cada servidor se escriben en un archivo llamado CounterData.<ServerName>.<TimeStamp>.csv. El informe de resumen se escribirá en un archivo denominado HaReplPerfReport.<DAGName>.<TimeStamp>.csv o HaReplPerfReport.<TimeStamp>.csv si no ejecutó el script con el parámetro DagName.
El script inicia trabajos de PowerShell para recopilar los datos de cada servidor. Estos trabajos se ejecutan durante todo el período en que se recopilan los datos. Si especifica una gran cantidad de servidores, puede que este proceso use una cantidad de memoria considerable. La fase final del proceso, cuando los datos se procesan en un informe de resumen, también puede llevar bastante tiempo si se trata de grandes cantidades de datos. Es posible ejecutar la fase de recopilación en un equipo y, a continuación, copiar los datos en otro lugar para su procesamiento.
El script CollectReplicationMetrics.ps1 admite parámetros que permiten personalizar el comportamiento y los resultados del mismo. En la tabla siguiente se muestran los parámetros disponibles:
Parámetros del script CollectReplicationMetrics.ps1
| Parámetro | Descripción |
|---|---|
DagName |
Especifica el nombre del grupo de disponibilidad de base de datos (DAG) de la que se va a recopilar la métrica. Si se omite este parámetro, se usará el DAG del que es miembro el servidor local. |
DatabaseNames |
Proporciona una lista de bases de datos para las que debe generarse el informe. Se admiten caracteres comodín, por ejemplo, |
ReportPath |
Especifica la carpeta usada para almacenar los resultados de procesamiento de eventos. Si se omite este parámetro, se usará la carpeta Scripts. |
Duration |
Especifica el tiempo que debe durar el proceso de recolección de datos. Los valores habituales son entre una y tres horas. Las duraciones más largas solamente deben usarse con intervalos largos entre cada ejemplo o una serie de trabajos más cortos realizados por tareas programadas. |
Frequency |
Especifica la frecuencia a la que debe recopilarse la métrica de datos. Los valores habituales son 30 segundos, un minuto o cinco minutos. Bajo circunstancias normales, los intervalos más breves no supondrán cambios significativos entre cada ejemplo. |
Servers |
Especifica la identidad de los servidores de los que se deben recopilar estadísticas. Puede especificar cualquier valor, incluidos caracteres comodín o GUID. |
SummariseFiles |
Especifica una lista de archivos .csv para generar un informe de resumen. Estos archivos se llaman CounterData.<CounterData>* y se generan mediante el script CollectReplicationMetrics.ps1. |
Mode |
Especifica las fases de procesamiento que ejecuta el script. Puede usar los siguientes valores:
|
MoveFilestoArchive |
Especifica que el script debe mover los archivos a una carpeta comprimida tras el procesamiento. |
LoadExchangeSnapin |
Especifica que el script debe cargar los comandos del Shell de Exchange. Este parámetro es útil cuando el script tiene que ejecutarse desde fuera del Shell de administración de Exchange, por ejemplo en una tarea programada. |
Ejemplo de CollectReplicationMetrics.ps1
En el ejemplo siguiente se reúnen los datos equivalentes a una hora de trabajo de todos los servidores que se encuentran en el DAG "DAG1", con un muestreo basado en intervalos de un minuto y, a continuación, se genera un informe de resumen. Asimismo, se usa el parámetro ReportPath, que hace que el script coloque todos los archivos en el directorio actual.
CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath
En el ejemplo siguiente se leen los datos de todos los archivos que coincidan con "CounterData*" y se genera un informe de resumen.
CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath
Cmdlet Get-MailboxDatabaseCopyStatus
Script CheckDatabaseRedundancy.ps1
Tal y como su nombre indica, la finalidad del script CheckDatabaseRedundancy.ps1 es supervisar la redundancia de las bases de datos de buzones replicadas corroborando que, por lo menos, haya dos copias actuales configuradas que sean correctas, así como avisarle cuando solamente exista una copia correcta de una base de datos replicada. En tal caso, tanto las copias activas como las pasivas se cuentan a la hora de determinar la redundancia.
Cuando se instala el rol de servidor Buzón de correo, Exchange configura automáticamente el script CheckDatabaseRedundancy.ps1 para ejecutar una tarea programada denominada Alerta de una copia de base de datos. De forma predeterminada, la tarea programada Alerta de una copia de base de datos está configurada para ejecutarse cada 60 minutos. Puede modificar este comportamiento y la configuración de la tarea programada en el Programador de tareas de Windows. El script está diseñado para comprobar en primer lugar la pertenencia a grupos de disponibilidad de base de datos (DAG), por lo que si el servidor de buzones no es miembro de un DAG, el script se elimina inmediatamente.
El script se puede también ejecutar interactivamente desde la carpeta de scripts. Al ejecutar el script de forma interactiva, debe especificar el nombre de una base de datos o el nombre de un miembro de un DAG. Para especificar una base de datos, debe usar el parámetro MailboxDatabaseName y para especificar un miembro de un DAG, el parámetro MailboxServerName. Cuando se ejecuta de forma interactiva en la consola, el script realiza la comprobación de redundancia una sola vez y muestra el valor de CurrentState (rojo o verde) en la pantalla.
Como otros scripts y cmdlets, CheckDatabaseRedundancy.ps1 también puede ejecutarse en modo de supervisión y generar eventos si se añade el parámetro MonitoringContext. La tarea programada creada por Exchange ejecuta el script en el modo de supervisión. Este modo permite además que el script se invoque mediante una solución de supervisión, como Microsoft System Center Operations Manager (SCOM). En el modo de supervisión, el script genera eventos de alerta roja y alerta verde en el registro de eventos de la aplicación del servidor local. Los eventos de alerta roja (Id. de evento 4113) solamente se generan si la base de datos ha estado en “rojo” durante 20 minutos más (en total, no necesariamente consecutivos) en la ejecución de una hora de duración del script, y los eventos de alerta verde (Id. de evento 4114) se generan cuando la base de datos ha estado en “verde” durante 10 minutos consecutivos. De forma predeterminada, cuando se genera un evento de alerta roja, continúa notificándose cada 15 minutos.
Asimismo, el script cuenta con algunas otras opciones útiles. Por ejemplo, puede agregar el parámetro ShowDetailedErrors para obtener más detalles sobre los errores que se produzcan y el parámetro Verbose para obtener información adicional sobre resolución de problemas. El script también incluye un parámetro SendSummaryMailTos, que puede usarse para enviar un informe de resumen por correo electrónico a una lista de direcciones de correo electrónico especificadas cuando el script haya acabado de ejecutarse. De esta forma, los administradores pueden echar un vistazo rápido a los informes por hora para ver si se ha producido algún problema de redundancia. Si usa la función de correo electrónico, deberá incluir el parámetro SummaryMailFrom siempre que use el parámetro SendSummaryMailTos.
Microsoft recomienda ejecutar este script con regularidad, como parte de las operaciones de supervisión habituales mediante la tarea programada automática o un sistema de supervisión como SCOM. Para garantizar que no existan largos períodos en los que la redundancia de base de datos esté en peligro, ejecute el script cada 60 minutos. El script incluye un parámetro llamado TerminateAfterDurationSecs, que si se establece en -1 o 0 al ejecutar el script, puede usarse para ejecutar el script durante un período de tiempo infinito.
Si no ejecuta una solución de supervisión como SCOM, se aconseja permitir a la tarea programada creada automáticamente automatizar y programar la ejecución del script.
Existen problemas conocidos en el Programador de tareas de Windows Server 2008 SP2 que pueden hacer que se bloquee si ha programado una tarea de larga duración. Estos problemas no existen en Windows Server 2008 R2; así que si es posible, ejecute el script desde Windows Server 2008 R2. Si no puede ejecutar el script desde Windows Server 2008 R2, y lo está ejecutando desde Windows Server 2008 SP2, se aconsejan dos modificaciones. En primer lugar, en lugar de ejecutar el script con la supresión transitoria integrada de 60 minutos, ejecútelo cada 5 minutos mediante los parámetros siguientes:
CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors
En segundo lugar, si es posible, use SCOM para definir el comportamiento de supresión transitoria (por ejemplo, si se registran 3 eventos de alerta roja en un período de 20 minutos, debe generarse una alerta, y si se registra un evento de alerta verde, debe cambiarse el valor de CurrentState a verde).
Si se modifica o elimina la tarea programada Alerta de una copia de base de datos, puede eliminarla y volver a programarla si ejecuta el comando siguiente:
schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY
Reemplace los parámetros del script anterior por los parámetros que quiera usar. En el script también se describen parámetros adicionales para el mismo.
Si usa la herramienta de línea de comandos schtasks para crear una tarea programada, la opción /TR tiene un límite de 261 caracteres. El ejemplo anterior supera dicho límite. Si los parámetros y las rutas de acceso que usa hacen que la opción /TR supere los 261 caracteres, cree manualmente la tarea programada mediante el applet del Programador de tareas en el menú Herramientas administrativas. También puede copiar y pegar el XML siguiente en el Bloc de notas, editarlo según sea pertinente, guardarlo como archivo XML e importarlo mediante el applet del Programador de tareas.
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2010-05-11T15:55:47</Date>
<Author>administrator</Author>
</RegistrationInfo>
<Triggers>
<TimeTrigger>
<Repetition>
<Interval>PT1H</Interval>
<StopAtDurationEnd>false</StopAtDurationEnd>
</Repetition>
<StartBoundary>2010-05-11T15:55:00</StartBoundary>
<Enabled>true</Enabled>
</TimeTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>SYSTEM</UserId>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>Powershell.exe</Command>
<Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
</Exec>
</Actions>
</Task>
Cmdlet Get-MailboxDatabaseCopyStatus
© 2010 Microsoft Corporation. Reservados todos los derechos.