ADM: Calendar repair assistant

Print Friendly, PDF & Email

Calendar Repair assistant (CRA) es una funcionalidad e Exchange 2010 que nos asegura que no haya incidencias con los items calendarios del buzón del usuario. Alguno de los errores que podrían darse son:

  • Items corruptos en el calendario
  • Items que desaparecen en el calendario
  • Horas erróneas en las citas de calendario
  • Items de calendario disponibles en Outlook pero no se sincroniza en el móvil
  • Reuniones aceptadas en el móvil que no se reflejan en Outlook o viceversa

Automáticamente Exchange chequea los calendarios y si hay problemas los arregla. La funcionalidad CRA no está habilitada por defecto

EL CAR no se puede administrar por EMC. Ya que el CAR corre en los Mailbox server, para ver los parámetros a configurar:

  • Get-mailboxServer | fl *calendar*


Vemos que por defecto CalendarRepairSchedule no tiene ningún valor, por lo que el Mailbox server NO va a chequear los ítems de calendario

Estos son los parámetros a configurar

  • CalendarRepairSchedule: controla cuando el CAR correrá. Por defecto no está configurado, por lo que CRA no se ejecutara el este servidor de mailbox. En el ejemplo el CRA correra el domingo de 19 a 22 horas
    • Set-MailboxServer MBX01 –CalendarRepairSchedule Sunday.19:00-Sunday.22:00

    Nos debemos de asegurar de configurarlo en todos servidores de mailbox

  • CalendarRepairMissingItemFixDisabled: si lo ponemos a TRUE significa que CAR no arreglara items de calendar perdidos. Por defecto si los arregla (false
    • Set-MailboxServer MBX01 -CalendarRepairMissingItemFixDisabled $false
  • CalendarRepairIntervalEndWindows: días en el futuro, en la que se tiene que volver a chequea un buzón
    • Set-MailboxServer MBX01 –CalendarRepairIntervalEndWindow 90
  • CalendarRepairWorkCycle: el tiempo en días (3 en el ejemplo) que tiene en servidor de buzón para chequear todos los calendarios de todos sus buzones y repáralo si se da el caso
    • Set-MailboxServer MBX01 -CalendarRepairWorkCycle 3.00:00:00
  • CalendarRepairWorkCycleCheckpoint: Cuando se refresca la cola de CRA
    • Set-MailboxServer MBX01 -CalendarRepairWorkCycleCheckpoint 1:00:00:00

 

El Calendar repair trabaja con un periodo de tiempo llamado “work cycle”. En este periodo de tiempo, el servidor de correo se tiene que asegurar que un buzón es chequeado una vez, por lo que si ponemos un ciclo de 7 días, el Mailbox server se asegura los buzones se ha chequeado una vez en este periodo de tiempo

En ese ejemplo, el servidor de correo tiene 3 dias para chequear los calendarios de los buzones, la cuoa la refresca diariamente, y tiene hasta 90 dias para volver a chequear otra vez todd

  • Set-MailboxServer –Identity MBXServer01 -CalendarRepairIntervalEndWindow 90
    -CalendarRepairMissingItemFixDisabled $false -CalendarRepairWorkCycle 3.00:00:00
    -CalendarRepairWorkCycleCheckpoint 1:00:00:00

Controlar buzones individuales

Aunque el CAR no está habilitado por defecto ya que CalendarRepairSchedule, todos los buzones de correo del servidor Mailbox si lo tiene habilitado, aunque no le funcionara, ya que a nivel de Mailbox server esta deshabilitado

El parámetro es CalendarRepairDisabled : False, el cual dice que es falso que este deshabilitado


Podemos excluir el cheque de calendario de buzones en concreto con

  • Get-mailbox –identity “username” | set-mailbox –calendarrepairdisabled $true

 

Calendar Repair Assistant Logging

Ya que CRA hace cambios en los buzones de los usuarios una buena idea es mandar a un archivo de log los calendarios reparados. El Calendar Repair logging está activado por defecto en cada Mailbox server


  • CalendarRepairlogEnabled: por defector habilita el log de las reparaciones de calendario
  • CalendarRepairLogSubjectLoggingEnabled: activado por defecto
  • CalendarRepairLogPath; el patch de los log de Calendar Repair assistant. Por defecto en la carpeta:


    \Program Files\Microsoft\Exchange Server\V14\Logging\Calendar Repair Assistant.

    Podría modificar la ruta fácilmente: Set-MailboxServer –Identity EXCH –CalendarRepairLogPath C:\CRA


  • CalendarRepairLogFileAgeLimit: los logs no son eliminados por defecto (00:00:00). Si el DRA a sido configurado configurado para volver a chequearse a los 90 dias (CalendarRepairIntervalEndWindows) lo ideal es poner como requerimiento que los logs se eliminen a los 90 dias, de esta fiorma no se solaparan unos logs con otros
    • Set-MailboxServer –Identity EXCH –CalendarRepairLogFileAgeLimit 30
  • CalendarRepairLogDirectorySizeLimit: Controla el tamaño del directorio que aloja los logs del CRA. Por defecto es ilimitado, si no queremos que crezca lo pidemos ajustar
    • Set-MailboxServer –Identity EXCH –CalendarRepairLogDirectorySizeLimit 1Gb

 

CRA en Accion

Primero para ver todo el proceso, vamos a generar un problema. Supongamos que el usuario Rob solicita una reunión al usuario Neil. Aunque Neil acepta la reunión (y por consiguiente se borra la solicitud de reunión) y además no le ha enviado una respuesta para que el otro lo sepa que ha aceptado


Asi que Neil después de de eliminar la solicitud de su calendario y n enviar ninguna actualización a Rob, el Calendar Repair Assistants corre contra todos los buzones del servidor de correo. Este es el Calendar repair Assistant log files generado por la incidencia, el cual Neil borro del calendario. El fichero es CRA2010053021-1.neil


Vemos que no hay nada relevante en el log y es porque los detalles de la Meeting reparada pertenecen en el log file asociado con el organizador de la reunión (Rob), y habíamos abierto el log de Neil (CRA2010053021-1.neil)

Por lo tanto la información que nos vale es el log asociado al buzon del organizador (rob). El fichero es CRA2010053021-1.rob


Vemos que hay 4 consistencias que se chequean: CanValidateOwnerCheck, ValidateStoreObjectCheck, UserExistsCheck y MeetingExistenceCheck.

Esta última es la que falla, por lo tanto, la inconsistencia es reportada como:

Could not find the matching meeting in attendee’s calendar“.

Una vez que el CRA ha corrido contra los buzones, el impacto en el de Neil (el cual borro la meeting del calendario) es que la solicitud de reunion ha sido re-creada


Le muestra una descripción clara de la incidencia con el ítem, y un consejo en lo que Neil necesita hacer para asegurarse que el ítem calendario no sea recreada de nuevo automaticamente. En el ejemplo, la meeting debe ser declinada para que Rob reciba una respuesta de declinación

Be the first to comment

Leave a Reply