Recientemente fue anunciado en el blog del equipo de producto de Exchange una nueva política de soporte para el caso de base de datos reparadas.
Si bien la recomendación siempre ha sido la de no dejar bases de datos reparadas en producción, dentro de esta nueva política se especifica que estas ya no estarían soportadas.
El proceso de reparación implica la ejecución del comando con el parámetro /p, en general seguido por una desfragmentación ( eseutil /d) y posteriormente la ejecución de isinteg (-fix) o a partir de Exchange 2010 los nuevos cmdlets New-MailboxRepairRequest / New-PublicFolderDatabaseRepairRequest dependiendo del tipo de base.
En resumen, si se cuenta con una base reparada se deben mover los buzones a una nueva base de datos para estar dentro de la nueva política de soporte.
Cómo saber si una base de datos de Exchange fue reparada?
Para ver si la base fue alguna vez reparada es posible ejecutar el comando " eseutil /mh" y dentro del encabezado ver el número de " Repair Count" ( requiere desmontar la base).
Si el Repair Count es mayor a 0 la base fue reparada:
eseutil /mh ruta:\base.edb
Dado que el /mh devuelve mucha información pueden auxiliarse con el comando findstr o por ejemplo "| more " para que devuelva la info por página.
Si se encuentran con un error de tipo 1032 (JET_errFileAccessDenied) seguramente sea porque la base se encuentra montada:
Error: Access to source database 'ruta a base' failed with Jet error -1032. Operation Terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use) after 0.0 seconds.
En este caso primero habría que desmontar la base de datos con el cmdlet Dismount-Database (en el proceso desconecta a los usuarios conectados a la base ):
Dismount-Database Base