Finally the help of IT is here

Blog de soluciones informaticas.

Detectar errores visor de sucesos desde Powershell

Posteado por Xavier Xaus Nadal on 13th mayo 2012

Buenas.

Hoy vamos poner algo de powershell.

Este artículo explica como recoger remotamente un evento del visor de sucesos de windows de un equipo o grupo de equipos desde una línea de comandos Powershell y además en Onliner, jeje como me gusta a mí..

Recordáis el artículo http://www.megacrack.es/2008/11/16/como-resolver-problema-con-jrnl_wrap_error-frs-event-id-13568-o-13561/ donde demostrábamos como solventar un error con la replicación de Active Directory del sysvol?, pues con este script podremos detectar remotamente este tipo de errores sin tener que esperar a que un usuario nos diga que su script no funciona por que no lo detecta, o que una política de dominio no se está aplicando por que no existe en algún site, etc..

Lo que vamos a hacer con este script es comprobar los últimos 2 días de logs del visor de eventos del “File Replication Service” como source “NtFrs” y como tipo de error “Error” y también forzaremos a que únicamente nos muestre los errores de tipo “13568” y que únicamente nos muestre el más nuevo para ajustarnos a las preferencias de detectar el error de replicación de active directory (Vosotros podréis poner lo que queráis como por ejemplo detectar si las bases de datos de Exchange se han apagado por culpa de que el log de transacciones se haya llenado) con los siguientes valores:

Type: Error

Event ID: 9518

Source: MSExchangeIS

Pero de momento lo que vamos a buscar nosotros son los problemas con el FRS y lo que buscamos es lo siguiente:

Type: Error

Event ID: 13568

Source: NtFrs

Lo haremos de esta forma:

get-eventlog -newest 1 -after (get-date).AddDays(-2) –computername <NombreEquipo> -logname "File Replication Service" -source "NtFrs" -entrytype "Error" | where{$_.EventId -eq ‘13568’} | select machinename,source | ftautosize

El resultado si detectara que ha habido un error en los últimos 2 días en el apartado File Replication Service con source NtFrs, de tipo Error y con el código de evento 13568 sería el siguiente:

MachineName Source

———–         ——

MegaDC1        NtFrs

A partir de ahí ya podremos solventar el problema  con el siguiente artículo por ejemplo: http://www.megacrack.es/2008/11/16/como-resolver-problema-con-jrnl_wrap_error-frs-event-id-13568-o-13561/

Pero si lo que queréis es detectar esto mismo en todos los domain controllers del dominio deberéis modificar –computername <NombreEquipo> por:

-computername (get-qadcomputer -searchroot "<dominio>Domain Controllers" –dudip | Select-Object -ExpandProperty Name)

Cuidado que esta última modificación que lo hará sobre todos los domain controllers que tengáis y tardará muchísimo, (Deberéis tener instaladas las herramientas de Quest Active Roles Management) pensad que lo hacemos remotamente y que no usamos hebras de procesos (Esto ya os lo mostrará otro de los miembros del blog que es más que experto en Powershell) A ver si se anima.. Albert!!!!!, te queremos leer en MegaCracks…

También podéis ejecutar el comando en cada servidor diariamente y que envíe un email con los resultados a una dirección de correo o lo envíe hacia un fichero que será recogido por un IIS y mostrado en una web como si de un monitor de eventos centralizado se tratara, o lo que vuestra imaginación os ofrezca… El mundo del powershell es impresionante, pero más lo es cuando lo unes con automatizaciones, monitores, webs, etc..

Si tenéis cualquier pregunta al respecto estaremos encantados de daros soporte desde los comentarios del bog.

Hasta la próxima.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posteado por Error, Exchange, PowerShell, powershell | No Comments »

Solventar problemas rendimiento Outlook y Exchange

Posteado por Xavier Xaus Nadal on 10th mayo 2012

Buenos días.

Desde hace algunos años que usuarios de Outlook con Exchange 2003 están sufriendo lentitud en sus sistemas, time out, errores, etc.. Cada día la cantidad de mails que recibimos es superior, el tamaño de los correos es superior y las capacidades de los servidores siguen siendo las mismas (tema crisis).

Pero caer en el error que el servidor de correo es el causante, es una forma incorrecta de asumir el problema.

Outlook 2003/2007/2010 como muchos otros sistemas de correo tiene sus limitaciones y sus buenas prácticas que deberíamos seguir a rajatabla y únicamente sin modificar el sistema Outlook del usuarios y sobretodo sin tener que invertir en nuevo hardware o incluso sin pensar en actualizar el sistema de correo a una versión reciente podríamos conseguir muy buenos resultados en cuanto a rendimiento del sistema de correo se refiere. (El usuario lo agradecerá.)

Uno de los grandes problemas y muy fáciles de solventar es el número de emails en cada carpeta en Outlook.

Este número de correos no debería superar nunca los 3000 correos (Parece mucho a simple vista, pero mirad vuestra bandeja de entrada o la carpeta elementos enviados (Cuantos tenéis???).

Con este simple cambio podremos ver una mejora sustancial en el rendimiento de nuestro Outlook y por ende en el feedback del usuario en cuanto al sistema de correo. Y aunque os parezca increíble también en la carga del servidor Exchange.

El contenido de cada carpeta se almacena en una tabla en el Information Store Database, a medida que aumenta el número de elementos en cada carpeta el mecanismo de almacenamiento extensible también llamado ESE que utiliza estructuras de datos de árboles B + para almacenar registros también aumenta y como el número de registros aumenta, el número de entradas / salidas de disco para almacenar nueva información también aumenta y decrementa el performance del sistema por completo.

Sigue leyendo MegaCrack »

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posteado por Exchange | No Comments »