Error “Anti-Malware Engine Offline” en Deep Security Manager 9.5

Si te aparece este error en la consola del Deep Security Manager y esta solución no te funciona, prueba reiniciando la DSVA.

  1. Abre la consola de DSVA en el cliente de vSphere
  2. Presiona Alt+F2 para que aparezca el prompt de login
  3. Introduce el usuario dsva y su contraseña (por defecto es dsva)
  4. Ejecuta el comando sudo reboot (te va a pedir que introduzcas la contraseña nuevamente)

The WSMan client cannot process the request. Proxy is not supported under HTTP transport

Este error me estaba apareciendo al intentar abrir la consola de Exchange en mi nueva máquina de Windows 10.

Da casi vergüenza admitirlo, pero se me olvidó desactivar el proxy de WinHTTP después de desplegar la imágen 🙂

Solo hay que abrir una consola con permisos administrativos y ejecutar:

netsh winhttp reset proxy

Error Lync – 0x800B0110 The certificate is not valid for the requested usage

Este ha sido uno de los errores mas ráros que he visto desde que estoy trabajando en IT… Y mira que he visto cosas raras.

Estás el lunes por la mañana de lo más tranquilo en tu mesa cuando de repente empieza a decirte la gente que la federación del Lync no va, que no pueden hablar con gente de otras empresas. Abres tu cliente de Lync y efectivamente, todos los contactos externos aparecen con “Presencia Desconocida”.

Entras en el servidor de Edge y revisas el log…

error certificate usage

What? O_o

Vas al certificado en cuestión y efectivamente, el propósito Server Authentication (Proves your identity to a remote computer) ha desaparecido del certificado.

cert bad

Revisas otro servidor que tiene instalado el mismo certificado y el propósito si está

cert good

¿Eh? ¿Qué pasa aquí?

Se habrá corrompido el certificado de alguna forma. Lo eliminas y lo vuelves a importar. Nada, sigue fallando.

Sigues revisando el resto de los logs. No hay errores.

Te paras un momento a pensar. ¿Y si el problema está en la entidad certificadora? ¿Quién firmó este certificado?

Resulta que este certificado esta firmado por Symantec Class 3 Secure Server CA – G4, que a su vez está firmada por VeriSign Class 3 Public Primary Certification Authority – G5, que a su vez está firmada por VeriSign Class 3 Public Primary CA. (¿A que PKI mola?)

Empiezas a revisar cada uno de los certificados de la cadena y te fijas de que ninguno tiene el proposito de Server Authentication. Aquí pasó algo raro, muy raro.

cert chain bad

Revisas como está esto en el otro servidor.

cert chain good

El certificado está firmado por Symantec Class 3 Secure Server CA – G4, que a su vez está firmada por VeriSign. ¡AJÁ!

La CA Symantec Class 3 Secure Server CA – G4 está cross-signed (firmado cruzado) por varias CA, dentro de ellas VeriSign y VeriSign Class 3 Public Primary Certification Authority – G5. La CA VeriSign está habilitada para unos propósitos y la CA VeriSign Class 3 Public Primary CA (que es la que firma VeriSign Class 3 Public Primary Certification Authority – G5) está habilitada para otros y NO incluye Server Authentication. (¿A que PKI mola MUCHO?)

code signing

Pero… ¿Y cómo es que antes si funcionaba?

Existe algo llamado Automatic Root Certificates Update, es un componente de Windows que actualiza automáticamente el listado de certificados raíz de un equipo y sus propósitos. En los logs de Windows queda registrado bajo el source CAPI2

capi update

Como se puede ver en la imagen, durante la madrugada se actualizó el certificado de VeriSign Class 3 Public Primary CA y supongo que ahí fue cuando se le eliminó el propósito de Server Authentication.

Pero… ¿Y por qué en el otro servidor no falló?

Como puse arriba, la CA VeriSign Class 3 Public Primary Certification Authority – G5 tiene un firmado cruzado. En el servidor que seguía funcionando correctamente SI estaba instalado el certifcado de VeriSign por lo que el certificado de Lync Edge Services tenía un camino que validara su propósito de Server Autentication. En el servidor donde falló, el certificado de VeriSign no estaba instalado, por lo que el certificado final parecía inválido. El tema se resolvió instalando los certificados nuevos de Symantec en el servidor de Edge.

No quiero saber nada de PKI por un tiempo… 🙂

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

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.

OfficeScan 11 se queda a medio instalar

Hoy tuve un problema un poco extraño. Instalé el agente de OfficeScan en un equipo y la instalación finalizó correctamente. Sin embargo, al reiniciar el equipo no aparecian los iconos del OfficeScan en ninguna parte y al intentar desinstalarlo me aparecía el siguiente error:

“Unable to get uninstallation information (GUID). Uninstallation aborted”

En la web de Trend Micro se explica la razón del mensaje pero no se ofrece una solución.

Al final la solución era simplemente ejecutar el instalador del agente otra vez.

Si todos los problemas se solucionaran así de fácil…

Enterprise Vault con almacenamiento en EMC Centera va muy lento

Esta entrada, más que un articulo técnico es una demostración de por qué todos tenemos que ponernos de acuerdo en un departamento de TI. Operaciones, comunicaciones, helpdesk, todos tenemos que ser parte de un uno o de lo contrario pueden pasar cosas como estas.

Trabajar con entornos heredados es muy complicado, por lo general son entornos con tecnolgías muy antiguas, mal diseñadas, sin soporte y, peor aun, sin documentacion.

Nuestro entorno de Enterprise Vault iba muy bien hasta que un día, sin razón aparente, empezó a ir muy lento. Cuando digo lento me refiero a que la restauración de un elemento archivado tardaba entre un minuto y cinco minutos (y a veces daba timeout). Antes de esto la restauración tardaba unos 15 segundos, que no es muy rápido, pero parecía razonable.

Procedimos a la rutina de resolver problemas:

  • Revisar los logs de Enterprise Vault: no hay errores.
  • Revisar los logs de Windows: no hay errores
  • Revisar los logs de Centera: no hay errores. La tasa de I/O está casi en 0, por lo que no puede ser un problema de sobrecarga.
  • Llamar a soporte de Symantec: “Nosotros vemos todo OK, debe ser problema de EMC”.
  • Llamar a soporte de EMC: “Nosotros vemos todo OK, debe ser problema de Symantec”.

Llegados a este punto, solo quedaba irse a un rincón a llorar. ¿A quién llamamos? Por lo visto nadie sabe nada de estos sistemas.

Nos secamos las lagrimas y entramos en modo “por mis cojones que resuelvo esto”. No tiene sentido que todo vaya mal de un día al otro sin motivo alguno.

Afortunadamente, tengo algunos conocimientos de programación y sabía que en alguna parte se podía activar el debug log de la API de Centera.

Revisando el log vi que cuando el Enterprise Vault se conectaba a la Centera esta le entregaba un rango de direcciones IP diferente al que yo creía que tenía configurado en la Centera.

Revisamos la configuración de la Centera, aparece algo llamado NAT Externo con las direcciones en cuestión. Llamamos a EMC nuevamente “¿Pero esto que eeeesss? (En voz Mauricio Colmenero)”. Nos dicen que es algo que se configura cuando hay replicación entre dos Centera. Preguntamos a los dinosaurios del departamento “¿En algún momento se replicaba esto con otro site?” “Ahhh siiii, en el año 2010 esto se replicaba con el site de Mordor”.

Muy bien, ahora sabíamos mas o menos por donde iban los tiros. Sin embargo, si esto ya estaba configurado así ¿Por qué dejó de funcionar de repente?.

Hablamos con comunicaciones.

  • “Oye, ¿te suena este rango?”
  • “Si, lo configuramos la semana pasada para la wifi de los bosses”
  • “Pero… ¿No sabías que ya se estaba usando para otra cosa?”
  • “No, aquí en el inventario no estaba”

Maravilloso, maravilloso. El sistema ha estado fallando desde hace años, lo que pasaba es que el rango que se estaba utilizando para el fulano NAT no era enrutable. Ahora que era enrutable el Enterprise Vault tardaba mas en fallar, solo que lo hacía de forma silenciosa.

Llamamos nuevamente al técnico de EMC “¿Si no tenemos replicacion hace falta que el NAT esté configurado?” “Pues no, no hace falta”. Desactivamos, guardamos y ¡voila! Ahora el Enterprise Vault va como un cohete y los elementos se restauran en un par de segundos (más rapido que antes de la incidencia).

En conclusión, todo mal:

  • Un sistema heredado sin documentación, que falla desde hace años, pero nadie dice nada porque va “razonablemente bien”
  • Una aplicación que no muestra errores cuando los hay
  • Se elimina una replicación entre sistemas y no se borran las configuraciones necesarias
  • Un rango de IP en produccion que no estaba inventariado
  • Una parte del departamento hace un cambio y el resto no se entera
  • Los técnicos de los fabricantes no hace un troubleshooting completo

Así que ya sabéis, hay que comunicarse bien entre los demas miembros del departamento de TI. No podemos ser islas porque esto no da mas que problemas.

Máquina del dominio no se registra en DNS cuando se conecta por VPN

Esta incidencia nos hizo dar muchas vueltas a algunos del departamento por varios días hasta que encontramos el origen del problema.

Una máquina específica no se estaba registrando en el DNS cuando se conectaba por VPN y ese era el único síntoma. ¿Registro de eventos de Windows? Nada. ¿Log de errores del cliente de VPN? Nada. ¿Log de eventos del servidor DNS? Nada.

Una captura con el Wireshark nos mostró que la máquina simplemente no estaba enviando la solicitud de registro en el DNS. Esto suele suceder cuando la interfaz tiene desmarcada la siguiente opción:

error dns 1

El problema en este caso es que la interfaz de VPN estaba oculta de la interfaz de Windows, por lo que no sabíamos si era esto. Sin embargo, aunque la interfaz estuviese oculta esta opción se debía estar registrando en alguna parte. La pregunta era ¿En dónde?

Como muchas cosas de Windows, esto se estaba almacenando en el registro. Específicamente en la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces
Una vez allí tuvimos que buscar el GUID correspondiente a la interfaz de VPN. Y ahí estaban las dos entradas que nos estaban amargando la vida:

  • RegistrationEnabled en 0
  • DisableDynamicUpdate en 1

¿Por qué estaba esto así? Ni idea, supongo que el instalador del cliente de VPN cambio esto por alguna razón.
Para resolver el problema simplemente tuvimos que cambiar estas dos entradas a:

  • RegistrationEnabled a 1
  • DisableDynamicUpdate a 0

Y reiniciar los servicios DNS Client y DHCP Client.

Referencia

Error 1603 al instalar Splunk Universal Forwarder

Hoy estuve desplegando una nueva versión del Universal Forwarder a través de SCCM y en algunos clientes estuvo fallando sin razón aparente. Al intentar instalar manualmente también fallaba sin dar detalles de por qué.

Después de activar los logs en modo verbose del instalador de Windows (parámetro /l*v) y no encontrar nada, decidí intentar la instalación de una versión intermedia entre la que estaba instalada y la que quería actualizar. Ahí encontre la pista que necesitaba, el instalador fallaba indicando que la versión que estaba intentando instalar era anterior a la que ya estaba instalada.

Sin embargo, cuando fui a agregar y quitar programas vi que la versión que aparecía era la antigua, lo que me llevo a pensar de que se trataba de algún tipo de corrupción en la base de datos de Windows Installer.

Efectivamente, cuando abrí el registro y fui a la clave correspondiente a la versión que estaba intentando instalar ahí estaba ya registrada.

error windows installer

Para solucionarlo hice lo siguiente:

  • Backup del registro
  • Detuve el servicio de Windows Installer
  • Eliminé la clave completa de {9C30ADEC-5D48-4600-A990-01B78AABF33C}
  • Inicié el servicio de Windows Installer
  • Ejecute el instalador nuevamente

Una vez hecho esto la instalación se hizo sin problemas.

Supongo que esta solución es aplicable para otros instaladores que fallen de la misma forma.

Windows Update/SCCM falla con error 8007000E

Esta fue bastante vergonzosa…

Después de estar buscando por media hora por que fallaba con el error 8007000E el escaneo de parches en un servidor, me di cuenta de que estaba introduciendo mal el código del error en Google y estaba poniendo 80007000E en vez de 8007000E.

En fin, cosas que pasan cuando tienes una semana muy larga.

Si te aparece este error cuando estás instalando instalar parches revisa el consumo de memoria de tu equipo. En mi caso era un servidor con un 1GB de memoria que fallaba cada vez que intentaba hacer el escaneo. Amplié la memoria a 2GB y santo remedio 🙂

Referencia