Consola de administración de SCCM 2012 R2 muy lenta

Desde que instalamos el SCCM la verdad es que el performance había sido bastante pobre, pero como ya el consultor nos había dicho que era un sistema muy pesado no le hicimos mucho caso. Sin embargo, ahora que estamos usando mas este sistema decidimos investigar más a fondo el problema porque trabajar más un usuario al mismo tiempo en el SCCM era imposible.

En el Resource Monitor de Windows no veíamos ningún proceso que estuviese consumiendo mucho disco, ni un fichero que tuviese demasiado uso, pero en los gráficos de uso de disco de vSphere era claro que había “algo” que estaba acaparando el uso de disco.

Investigando un poco por la red nos encontramos con esta entrada que nos dió una pista.

Efectivamente, en cuanto excluímos el directorio de logs del SCCM (%PROGRAMFILES%\Microsoft Configuration Manager\Logs\SMSProv.log) del escaneo en tiempo real del antivirus vimos un salto en el performance impresionante. Observa el gráfico de performance de vSphere donde se ve claramente la diferencia. De picos de 50 MB/s a menos de un par de megas en un par de segundos.

captura uso disco

Supongo que en el Resource Monitor no veíamos nada porque usamos Deep Security y el escaneo de virus no se hace en el host, sino en una segunda máquina que es la que tiene el antivirus instalado.

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.

Algunas GPO son “destructivas”

Vaya título, ¿No?

Esto es simplemente un recordatorio/advertencia para nuevos y no tan nuevos administradores de Windows.

SIEMPRE tenemos que tener en cuenta qué es lo que hace una GPO y a quíen se aplica, y probarla muy bien antes de pasarla a producción, porque sino podemos pasar un mal rato. Sobre todo si no tenemos un control de configuración actualizado 😉

Veamos un ejemplo y el motivo del título de este post:

Eres el administrador del dominio contoso.com (jeje) y tienes 20 servidores en la OU Servidores. Cada uno de estos servidores se utiliza para un software en particular y cada software se ejecuta con su propia cuenta de servicio.

Para que una cuenta de AD pueda iniciar sesión como servicio se le deben dar privilegios de Logon as service utilizando secpol.msc o gpedit.msc (esto ya estaba hecho para cada uno de estos 20 servidores).

Debido a necesidades de negocio tienes que agregar un servidor adicional para otro software que también se va a ejecutar con una cuenta de servicio. Como acabas de aprender sobre GPO, decides hacer una GPO para asignar los privilegios de iniciar sesión como servicio a la cuenta del software en cuestión y aplicarla a la OU de Servidores y así te evitas configurar el servidor localmente.

Excelente, ¿No?

Pues no, muy mal, te acabas de cargar la configuración de los otros 20 servidores y seguramente en un par de horas tendrás a media empresa quejándose de que las aplicaciones no funcionan. ¡Mas te vale que sepas que cuenta de servicio tenía privilegios de iniciar sesión como servicio en cúal servidor!

¿Qué ha salido mal? Resulta que algunas políticas de grupo son “destructivas”, con esto quiero decir que reemplazan lo que ya estaba configurado. No hacen un concatenado o “merge” de las opciones configuradas y por eso debes saber muy bien lo que estas hacen antes de pasarlas a producción.

Otros casos en los que tienes que tener mucho cuidado de no sobreescribir cosas que ya estaban definidas:

  • Definiendo grupos de seguridad locales -> Puedes quitarle permisos a usuarios que ya estaban definidos. Es mejor que uses GPP.
  • Excepciones del proxy configuradas en Internet Explorer -> Puedes dejar sin acceso a sistemas web a muchos usuarios

¿Cómo se pudo haber evitado lo de arriba? La solución más sencilla sería crear un grupo de Cuentas de servicio y agregar todas las cuentas de servicio definidas en cada uno de los servidores y DESPUES configurar la GPO, dándole permisos de Logon as service a este grupo.

Así que ya sabes, ojito con las GPO que defines.