| Oscar さんのプロフィールOscar Soto Casali Consul...フォトブログリスト |  ツール  ヘルプ |
|
2月25日 Interesantes Blogs sobre Office Communication Server 2007 y Libro Resource Kit de OCS 2007Estimados, los invito a revisar los blogs de los grupos de productos de Microsoft respecto a Office Communication Server 2007 Blog del team de Office Communicator 2007 http://communicatorteam.com/default.aspx Blog del team de Office Communication Server 2007 http://communicationsserverteam.com/default.aspx En ambos pueden encontrar archivos de configuración y scripts en PowerShell, además de archivos de plantillas de visio 2007 para la creación de diagramas de OCS 2007. También les cuento que a fines de enero, Microsoft Press liberó el libro del Resource Kit de OCS 2007 http://www.microsoft.com/MSPress/books/10482.aspx Saludos 2月24日 Salvemos un perrito.... MATAR ANIMALES NO ES ARTE!!!!!!!!!!!Estimados: Transcribo un correo que me envió mi sobrina, estudiante de 5 año de veterinaria relativa a la "obra de arte" del "artista" mencionado abajo. Personalmente NO estoy de acuerdo con matar animales como una "Obra de Arte" y aprovechando el poder de internet invito a los que quieran a unirse a la causa de que este artista no sea recibido en la bienal de arte mencionada. Sorprendentemente ya hay mas de 400.000 firmas. Saludos En el año 2007, Guillermo Vargas Habacuc, un supuesto artista, cogió a 2月3日 Insufficient system resources En Exchange 2007El Rol de Hub Transport Exchange 2007 viene preconfigurado para dejar de recibir correo cuando el espacio en disco en el cual residen las colas de SMTP alcanza un valor de espacio disponible menor a igual a 4GB. En el caso de mi empresa, tengo configurado este valor en 1GB (Disco pequeño en una máquina virtual), Todo esto gracias a la función de Back Pressure de Exchange http://technet.microsoft.com/en-us/library/bb201658(EXCHG.80).aspx
En este caso el problema estaba generado por la falta de espacio disponible en el disco de las colas de exchange (menos de 1GB), provocado por la existencia de demasiados archivos de LOG de Exchange (8 GB, para una base de 2GB), producto de no hacer respaldos de Exchange desde hace 6 meses :-( Para solucionar este problema hay dos alternativas: 1) La sugerida: Respaldar las bases de datos de Exchange, ya que el respaldo eliminará los archivos de log. Pero para esta solución se requiere tener espacio disponible :-), que en este caso no hay. 2) La NO sugerida: Eliminar los archivos de LOG para poder tener espacio y seguir recibiendo mail. Ok, usaremos la alternativa 2, que es del estilo "NO LO HAGAN EN SU CASA" (En este caso en la EMPRESA). Bueno pero lo haremos en esta ocasión. Ahora ¿cómo sabemos que archivos borrar y no provocar un problema mayor?. Para esto, hay que recordar que Exchange utiliza los archivos de Log de base de datos, en caso requerir una Restauración de la base, para reaplicar los logs hacia la base de datos, este proceso es producto de un proceso de Recovery, que se produce cuando se inicia el proceso de Information Store o se monta la base de datos después de una restauración. En este caso, la base de datos se encuentra en buen estado, pero necesitamos saber que archivos de LOG borrar. Para eso se requiere ejecutar el comando ESEUTIL /MH para leer la cabecera de la base de datos de forma de revisar cuál es el último archivo de log útil. Para ejecutar este comando se requiere desmontar la base de datos, para esto ejecutamos el siguiente comando del shell de Exchange: - Dismount-database –id “Server\mailbox database”, donde Server es el nombre del servidor de correo. Luego analizamos la cabecera - Eseutil /mh “mailbox database.edb” para chequear logs aplicados Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 08.01 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... File Type: Database Operation completed successfully in 0.109 seconds. NOTA: Para reducir el tamaño de este post corté una parte del reporte. Entonces ahora revisamos la lista de archivos de logs en el directorio de LOG (puede estar en el mismo disco o en otro) y podemos borrar los log anteriores al mencionado en LAST DETACH (Es recomendable MOVER los archivos de LOG hacia otra ubicación en lugar de borrarlos, hasta que estemos seguros de que la base de datos ha montado correctamente) En este caso se eliminaron todos los archivos anteriores a E0000001CCE.LOG Luego se monta la base de datos - Mount-database –id “Server\mailbox database”, donde Server es el nombre del servidor de correo y verificamos el registro MSExchangeISMaibox Event ID 9523 que indica que la base se ha montado correctamente.
Una vez comprobado que la base de datos ha subido correctamente podemos proceder a borrar los archivos de LOG que habíamos movido en los pasos anteriores. Hecho este paso se libera realmente el espacio en disco y el rol de HUB Transport comenzará a recibir correo nuevamente (No es necesario reiniciar ningún servicio) y veremos que el Evento 15005 de MSExchangeTransport indica que Back Resource Pressure ha vuelto a un estado normal
Luego respaldamos la base de datos como un paso obligatorio, ya que en caso de caída del server o daño de la base de datos, no tendríamos LOGS para aplicar. Finalmente, a modo de resúmen, estos son los pasos realizados: - Dismount-database –id “e2k764\mailbox database” - Eseutil /mh “mailbox database.edb” para chequear logs aplicados - Borrar logs - mount-database –id “e2k764\mailbox database” Saludos |
|
|
