¡Cuidado con los parches de Office 2013 en SCCM 2012 R2!

Hoy tuve un pequeño momento “WTF Microsoft?!” cuando me puse a descargar los parches de Office 2013 en SCCM 2012 R2.

Resulta que no importa la configuración de idiomas que tengas configurada en tu SUP o en el WSUS. El SCCM SIEMPRE va a descargar TODOS los idiomas de los parches de Office 2013. Lo mejor de todo es que no es un bug, es una decisión de diseño (¿Eh?).

¿Qué significa esto? Que por ejemplo, para el SP1 de Office 2013, en vez de 650 MB se van a descargar 650 MB * Número de idiomas soportados (después de 20 paré de contar). Esto se convierte en una pesadilla a la hora de transferir los paquetes de despliegue a los DP. No es lo mismo pasar 650 MB que pasar 10 GB por un enlace de 2 MB 🙂

Así que ya sabéis, mucho cuidado al descargar estos parches en vuestro entorno.

Referencia

Instalar cliente SCCM 2012 R2 en sedes remotas o con poco ancho de banda

Uno de los muchos retos de trabajar con empresas grandes es que siempre tienen sedes en la Cochinchina, con enlaces de 256 kbps (tirando para arriba), a las que hay que desplegarle software. Normalmente, estas sedes remotas no tienen suficientes equipos como para “merecer” un servidor propio, pero si suficientes como para saturar los enlaces al intentar desplegar CUALQUIER COSA.

Un ejemplo de estos despligues es el cliente de SCCM. Este cliente, junto con sus paquetes de soporte sube hasta aproximadamente 100 MB. Si intentamos desplegar esto a una sede con 10 clientes y un ancho de banda de 256 kbps tardaríamos unas 8+ horas, sin tomar en cuenta el overhead de las comunicaciones y saturando completamente el enlace. Esto último no es aceptable, ya que seguramente los usuarios necesiten trabajar con el correo, ERP, ficheros, etc.

Pudiesemos dejar los equipos encendidos y lanzar el despliegue un fin de semana, pero a mi, particularmente, me gusta más dormir 🙂

Lo que podemos hacer en este caso es transferir la carpeta de instalación del cliente a un solo equipo remoto, y ejecutar el resto de instalaciones desde una carpeta compartida en ese equipo, utilizando PSExec.

Los pasos serían mas o menos los siguientes:

  1. Copiar la carpeta Client desde el servidor de SCCM al equipo destino. Esta carpeta se suele encontrar en C:\Program Files\Microsoft Configuration Manager\Client.
  2. Compartir la carpeta Client. Tenemos que asegurarnos de darle permisos de lectura al usuario que va a realizar la instalación.
  3. Lanzar la instalación en los equipos remotos usando PSExec. El comando sería: psexec \\pcremoto ccmsetup.exe /source:\\equipoConCarpetaCompartida\carpetaCompartida SMSMP=miServidorMPdeSCCM. Es MUY importante el orden de los parámetros (estuve casi un año medio buscando por qué los parametros no me funcionaban hasta que di con este blog). Ya lo se… RTFM.

Una vez lanzada la instalación, los clientes van a extraer los ejecutables necesarios desde el equipo local con la carpeta compartida, en vez de descargar todo desde el Distribution Point mas cercano.

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.

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

Error al instalar Distribution Point en SCCM 2012

Al intentar desplegar un punto de distribución me encontré con que la instalación fallaba con un error poco claro. En la pestaña de Distribution Point Configuration Status aparecía que la preparación del servidor había finalizado correctamente, sin embargo, al intentar distribuir el software del agente de SCCM la tarea fallaba. Después de forzar varias veces la distribución manualmente el error continuaba.

Revisando el log smsdpprov.log en el servidor de destino me encontré con lo siguiente:

sccm_dp

No se puede abrir el archivo D:\SCCMContentLib\DataLib\EAA00002.4.temp\ccmsetup.cab. Lógico, no se puede abrir un archivo que está en una unidad que ni siquiera existe. Este servidor no tiene unidad D:\. Entonces, ¿Por qué aparece esta ruta en los logs?

Uno de los problemas de las fusiones/separaciones de empresas es que muchas veces los proyectos quedan a medio completar y las tareas de separación no se realizan correctamente. En este caso en concreto, este servidor sí tenía una unidad D:\ y en algún momento fue un punto de distribución para otra instalación de SCCM. Sin embargo, antes de la separación entre las dos empresas no se eliminó este servidor de la jerarquía del SCCM, por lo que los antiguos valores continuaban en el registro.

Para solucionar este problema tuve que editar el registro de windows. La ruta en este caso fue HKLM\Software\Microsoft\SMS\DP. El valor problemático era ContentLibraryPath y tuve que cambiarlo de D:\SCCMContentLib a E:\SCCMContentLib.

sccm_dp2

Una vez hecho este cambio y forzada nuevamente la distribución de los archivos la tarea se ejecutó correctamente.