Windows 7 SP1 virgen no se actualiza y la CPU se queda al 100%

Si instalas un Windows 7 SP1 desde cero y ves que al ejecutar Windows Update no se actualiza nada y la CPU se queda al 100% no estas solo.

El origen del problema no lo se, pero supongo que algo tendrá que ver con que el catalogo de Windows Update es cada vez más grande y el cliente que viene de paquete en el Windows 7 SP1 no está preparado para esto.

La solución es bastante sencilla y consiste simplemente en instalar el siguiente parche:

Windows Update Client for Windows 7 and Windows Server 2008 R2: October 2015

Después de que lo instales reinicia el equipo e intenta buscar actualizaciones nuevamente.

Logs de Webmarshal II

Esta es una pequeña adición a la entrada anterior referente al WebMarshal.

Navegando un poco por la base de datos de los logs encontré este procedimiento almacenado que es el que ejecuta la consola de reporting de Marhsal.

exec MRC_URLBrowsingByUser @TimeZone=N'60;10;5;1;03:00:00;120;3;5;1;02:00:00;',@Debug=0,@StartDate='2015-07-01 00:00:00',@EndDate='2015-08-01 00:00:00',@UserPattern=N'%fulano de tal%'

Sólo hay que cambiar los parámetros StartDate, EndDate y UserPattern por lo que nosotros querramos. El parámetro TimeZone supongo que varía para cada país pero este que pongo es válido para el uso horario “Hora central europea”.

Al ejecutar el procedimiento nos saldrá una lista de toda la actividad de navegación de un usuario determinado.

¡Auxilio! ¡Los logs del Exchange están fuera de control!

Lunes, 9 AM. Estás en tu puesto tranquilo revisando los correos que la gente te envió el viernes a última hora. Todo normal hasta que de repente entra en tu buzón un correo parecido a este:

Alerta (media) – Disco de logs DBLOG01 en MBX01 al 80%

Te pones a revisar los tamaños de loz buzones y no ves nada raro. Lanzas un backup de la base de datos intentando truncar los logs y esperas ansiosamente a que finalice.

10 minutos después.

Alerta (importante) – Disco de logs DBLOG01 en MBX01 al 90%

Sigues buscando, no aparece un buzón culpable. Empiezas a ponerte nervioso esperando a que finalce el backup.

5 minutos después.

Alerta (crítica) – Disco de logs DBLOG01 en MBX01 al 95%

Ahora estás sudando, el backup va por el 90%.

5 minutos depués.

Disco al 4% … 3% … 2%… Finaliza el backup y el disco de logs vuelve al 10% para luego seguir creciendo nuevamente. Llega al 50% y de repente deja de crecer. Te quedas más tranquilo, pero te queda por dentro la insatisfacción de no saber que causó el problema.

¿Te ha pasado algo parecido?

A mi sí, varias veces hasta que descubrí ExMon. El Exchange Server User Monitor es una herramienta de Microsoft que te permite ver que recursos del Exchange Information Store (el motor de base de datos) está utilizando cada usuario.

La forma de utilizarlo es muy sencillo:

  1. Descarga e instala el ExMon en un servidor de bases de datos de Exchange. La instalacón es darle a siguiente, básicamente.
  2. Ve a la carpeta de instalación del Exmon (%programfiles(x86)%\Exchange User Monitor) y haz doble clic sobre ExMon.reg, esto agregará al registro las claves que hacen falta para habilitar las trazas.
  3. Crea una carpeta para almacenar las trazas. C:\Temp, por ejemplo.
  4. Crea una definición de traza utilizando logman. Esto se hace ejecutando el siguiente comando: logman create trace Exmon_Trace -p {2EACCEDF-8648-453e-9250-27F0069F71D2} -nb 3 25 -bs 3 -o c:\Temp\

Una vez que tenemos la traza definida podemos ejecutarla cuando queramos para visualizar qué usuarios o buzones son los que está consumiendo recursos. Por ejemplo, continuando con el escenario de arriba, una vez que te llega el aviso de que se están generando muchos logs puedes iniciar la traza con el comando logman start exmon_trace. Esto iniciará la traza e irá almacenando los resultados en un archivo exmon_XXXXXX.etl, donde XXXXX es un correlativo automático que se incrementa cada vez que inicias una traza. Para visualizar los resultados de la traza puedes ejecutar %programfiles(x86)%\Exchange User Monitor\ExMon.exe c:\temp\exmon_XXXXX.etl, esto te abrirá la interfaz gráfica del ExMon:

ExMon

Aquí puedes visualizar todo tipo de datos relacionados con el motor de base de datos de Exchange. En este caso en particular nos interesa la última columna Log Bytes. Si ordenas por esa columna puedes ver cuál es el usuario/buzón en concreto que está generando logs de forma descontrolada. Si cierras el ExMon y lo vuelves a abrir con el comando de arriba puedes ver los datos de la traza actualizados. Si el mismo buzón sigue apareciendo de primero al ordenar por Log Bytes ya tienes tu culpable 🙂

Ahora solo te falta saber POR QUÉ está generando tantos logs. Según mi experiencia:

  • Si está generando logs y el tamaño del buzón está creciendo es porque el usuario está moviendo muchos elementos grandes a su buzón o está recibiendo muchos correos con adjuntos (poco probable).
  • Si está generando logs y el tamaño del buzón no cambia:
    • El OST del Outlook está corrupto.
    • El usuario tiene un dispositivo con ActiveSync que no está funcionando bien. Ver el caso de iOS 6.1.

Para finalizar, no te olvides de parar la traza cuando termines de hacer el troubleshooting: logman stop exmon_trace

PD: el ExMon también se puede abrir ejecutando el programa desde la carpeta de instalación, esto te crea automaticamente una traza que se elimina al cerrar el programa sin tener que pasar por el LogMan. El problema es que la interfaz gráfica se cuelga tan frecuentemente que para mi no es útil.

Referencia

Encontrar rutas largas con PowerShell

¿Te ha pasado que intentas copiar documentos de una ubicación a otra y Windows no te deja porque las rutas son muy largas?

Esto se debe a una limitación de 256 caractéres en la API de Windows que algunos programas usan para copiar archivos de una ubicación a otra. (Aquí hay una explicación más completa)

Un “oneliner” muy sencillo para encontrar estas rutas es el siguiente:

cmd /c dir /s /b |? {$_.length -gt 260}

Este código no es mío, pero la verdad no recuerdo de dónde lo saqué 🙁

Logs de navegación de WebMarshal

Los productos de Trustwave van bastante bien para lo que valen. En nuestro caso tenemos el WebMarshal y la verdad es que no nos da problemas (tampoco le pedimos mucho).

Sin embargo, algo que tienen realmente malo estos productos es la parte de reporting.

Queríamos sacar un listado de todas las páginas que había visitado un usuario en particular un día cualquiera y el reporte que te ofrece el producto deja bastante que desear. Así que nos fuimos un poco por las tripas y sacamos esta sencilla consulta en SQL que nos dió lo que necesitabamos:

select

df.StartTime

,domain.ServerName

,df.UrlObject

,df.FileName

from

SessionLog session

inner join DomainLog domain on session.Id = domain.SessionLogId

inner join DomainFileLog df on df.DomainLogId = domain.Id

where

session.UserGuid = 'AB4GHCB-AC96-4190-9E35-6CA45C82E190'

and session.StartTime > '2015-11-03'

and domain.StartTime > '2015-10-28'

and df.StartTime > '2015-10-28'

order by

df.StartTime

El valor de UserGuid se saca de la tabla User

Desactivar OfficeScan desde la línea de comandos

Por alguna extraña razón, esto está bastante escondido en la documentación oficial del OfficeScan.

Para desactivar (unload) el cliente desde la línea de comandos solo hay que ejecutar el siguiente comando:

C:\Program Files (x86)\Trend Micro\OfficeScan Client>PccNTMon.exe -n PasswordDeUnload

Referencia

Error 610 al intentar activar Deep Security Virtual Appliance

Hoy estaba desplegando un nuevo host de ESXi y al intentar activarle su correspondiente DSVA (Deep Security Virtual Appliance) me estaba arrojando el siguiente error:

610 (Unable to update host configuration.)

En los logs de Deep Security no vi nada y en los de vShield tampoco. Buscando en la web me encontré con algo parecido pero aplicado al antivirus de Kaspersky, así que supuse que el problema estaba en el vShield ya que el antivirus estaba funcionando perfectamente en el resto del los hosts.

Al final, un reinicio rápido del appliance de vShield me resolvió el problema.

Buscar por nombre de virus en logs de OfficeScan

Por alguna razón que desconozco, la pregunta “¿Cuántas de mis máquinas detectaron este malware?” es imposible de responder a través de la consola de OfficeScan.

Sin embargo, hay una solución muy sencilla. Simplemente abrimos el SQL Server Management Studio (SSMS), lo apuntamos a la base de datos de OfficeScan y ejecutamos la siguiente consulta, cambiando MIVIRUS por el nombre del malware según aparece en la consola:


select
info.COMP_NAME
,log.*
from
TBL_VIRUS_LOG log
inner join TBL_CLIENT_INFO info on log.UID = info.UID
where
log.VIRUSNAME like 'MIVIRUS'
order by
info.COMP_NAME

Eventos con origen “bowser” en el registro de eventos de Windows

Si alguna vez estas revisando el registro de eventos de Windows y vez entradas con el origen bowser no te asustes, ni es un virus, ni es un typo de los desarrolladores de windows, ni nada raro.

Simplemente es algo que quedó en el código de Windows desde los días de NT 3.1. Bowser es “la parte del modo kernel del servicio Computer browser”.

La historia completa está aquí

TIL 🙂

Exportar y eliminar OU vacías en Active Directory

Tenemos una implementación de FIM (Forefront Identity Manager) que siempre está haciendo cosas raras.

La última de estas es que debido a un cambio en el ERP fueron creadas cientos de OU vacias en el Active Directory 🙂

Maravilloso…

Afortunadamente, con PowerShell y ActiveRoles fue muy fácil saber cuáles fueron estas OU. Aquí os dejo el script:


$OUS = Get-QADObject -Type organizationalunit -SizeLimit 0

$output = @()

foreach($OU in $OUS) {
$Children = Get-QADObject -SearchRoot $OU -LdapFilter “(!(objectClass=organizationalUnit))” -SizeLimit 1 -WarningAction SilentlyContinue | Measure-Object
$outputObj = “” | select OU,CanonicalName,HasChildren,Level
$outputObj.OU = $OU.Name
$outputObj.CanonicalName = $OU.CanonicalName

if ($Children.Count -ne 0) {
$outputObj.HasChildren = “Yes”
}
else {
$outputObj.HasChildren = “No”
}

$outputObj.Level = $OU.CanonicalName.Split(“/”).Count
$output += $outputObj
}

$output | export-csv -notypeinformation -encoding utf8 -delimiter “;” EmptyOUs.csv

Este nos va a exportar un CSV que luego podemos abrir en Excel. En este se muestra la OU, el nombre canónico de la OU, si tiene hijos que no sean otras OU vacías y el nivel de la OU (siendo la raíz del dominio el nivel 0).

Una vez que tenegamos identificadas las OU vacías, podemos exportar el listado de los nombres canónicos de las OU a borrar y borrarlas con el siguiente comando:

LA SIGUIENTE LINEA ES PELIGROSA, ASEGURATE DE TENER UN BACKUP DEL AD ACTUALIZADO ANTES DE EJECUTARLA

get-content -encoding utf8 MiLista.txt | Remove-QADObject -DeleteTree -Force -Confirm:$false