Python ignora el parámetro –proxy al intentar usar pip

No se tanto de Python como para ponerme a buscar en que parte del código está esto, pero si tienes un proxy configurado en Internet Explorer e intentas usar pip install python va a coger el párametro HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer e ignorar lo que pongas despues de –proxy.

Por ejemplo, si ejecutas pip install -–proxy=usuario:pass@proxy:8080, pero en Internet Explorer tienes configurado el proxy2:8000. Python va a ignorar el proxy:8080 e intentar salir por proxy2:8000.

Para resolver esto simplemente deshabilita el proxy de Internet Explorer mientras ejecutas pip install o algo que requiera otro proxy.

Exportar listado de permisos de buzones de Enterprise Vault

Aquí dejo una consulta de SQL muy útil que exporta todos los permisos asignados a todos los buzones dentro de Enterprise Vault.

El flujo de la consulta es más o menos este:

  1. Chequea si existe la función para convertir SID de texto a binary. Si existe la elimina.
  2. Crea la función para convertir SID de texto a binary
  3. Saca el listado de permisos
  4. Elimina la función creada en el paso 2

Viene genial para saber hacer auditoría de los buzones o para saber si hay que notificar a alguien antes de eliminar un buzón cualquiera.

La consulta la saqué de este video que por alguna razón el autor no la puso en los comentarios.

MDT 2013 para Lite-Touch no permite usar IP estática

Al iniciar un equipo con MDT 2013, si seleccionas la opción de configurar una IP estática te darás cuenta de que te aparece el siguiente error:

error mdt 1

Es un bug del MDT 2013 que aún no han solucionado. Por fortuna el workaround es muy sencillo. Solo tienes que pulsar F8 e introducir los siguientes comandos:


netsh interface ip set address "Ethernet" static IP MASCARA GATEWAY

netsh interface ip add dns "Ethernet" DNS

Una vez introducidos los comandos puedes continuar el despliegue o captura como siempre.

Referencia

Configuración de NXLog y Logstash para archivo Netlogon.log

En la entrada anterior explicaba cómo habilitar el debug log del servicio Netlogon para poder ver los enventos de logon usando NTLM en los controladores de dominio. Para analizar estos logs de forma más fácil podemos enviarlos a ELK usando NXLog.

NXLog es un forwarder de logs multiplataforma, no necesita Java y más liviano que el Logstash.

Los archivos de configuración del NXLog y Logstash para enviar los eventos de netlogon.log a ELK los puedes decargar desde aquí.

La instalación de ELK es bastante sencilla, yo usé la guía de Digital Ocean.

Habilitar logging de netlogon sólo para eventos de Logon

Si tienes habilitada la auditoría de eventos de logon en tus controladores de dominio probablemente te hayas dado cuenta de que solamente quedan registrados los eventos de Kerberos.

Si tienes un proxy en el que los usuarios se autentican con NTLM usando una cuenta de dominio verás que estos eventos no quedan registrados en el visor de eventos del controlador de dominio. Si embargo, sí quedarían en el propio proxy si este tiene habilitada la auditoría de eventos de logon.

Para poder ver estos inicios de sesión tienes que tener habilitado el debug logging en los controladores de dominio. Habilitar esto es muy fácil y lo indica claramente en este KB de Microsoft. El problema es que si sigues los pasos de este KB vas a ver en el log muchos más eventos de los que seguramente te interesan.

Si solamente quieres que se registren los eventos de Logon tienes que ejecutar el siguiente comando en todos tus controladores de dominio:

nltest /DBFlag:0x20000004

Después de que ejecutes ese comando vas a ver los registros de inicio de sesión en el archivo C:\Windows\Debug\netlogon.log. Este archivo lo puedes enviar a tu sistema de centralización de logs para un posterior analísis.

Para desactivar el registro de estos eventos basta con ejecutar el siguiente comando:

nltest /DBFlag:0x0

Exportar tracking log de Exchange a CSV

Aquí os dejo un script muy sencillo que exporta el tracking log de Exchange a formato CSV, que es mucho más facil de inspeccionar en Excel.

La diferencia de este script con otros es que los campos como Recipients y RecipientStatus están completamente expandidos. Si exportas el resultado de Get-MessageTrackingLog directamente a Export-Csv estos campos aparecen como System.String[].

Para ejecutarlo solo tenéis que cambiar los parámetros inicio y fin.

exportarTrackingLog

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é 🙁