SCCM OSD, UEFI y Secure Boot: Conviviendo con los tres

Hola Mundo:

Hace algunos años atrás apareció UEFI con la promesa de modernizar el proceso de arranque de los sistemas operativos y ser una mejor interfaz entre el usuario y el firmware del equipo. 
Uno de los componentes importantes que incluye UEFI es Secure Boot.

Secure Boot protege a la máquina de arranques de sistemas operativos infectados. Básicamente valida que todo lo que se vaya arrancar y a escribir sea legítimo. No olvidar que existe software malicioso que infecta el arranque del sistema operativo, para que cuando inicie la interfaz del usuario ya esté infectado y sea más invisible al antivirus del equipo.
El esquema, explica claramente que luego de iniciar el arranque del sistema operativo, se hace una revisión con software antimalware. En el caso que exista algún problema, intenta repararse solo.
¿Cómo afecta esto a la distribución de sistemas operativos con SCCM? Junto con la aparición de UEFI, SCCM también se subió al carro y comenzó a soportar la distribución de sistemas operativos a máquinas que soportan UEFI. 
La misma herramienta es capaz de creas las particiones necesarias para el funcionamiento (recordar que no usa MBR y que no necesita de una partición reservada de sistema).
El problema se puede presentar al momento de instalar la imagen que se descarga desde el servidor. Al momento de comenzar a aplicarla, dará error. 
Si revisan con calma el log, verán que no puede escribir el registro de arranque.
¿Por qué? Porque Secure Boot lo impide.
Entonces, cuando vayan a distribuir algún sistema de esta forma, lo más seguro es que tengan que deshabilitar Secure Boot.
Otra opción es deshabilitar UEFI y usar BIOS.

Espero que les sirva.

Cuentas con privilegios locales en productos de System Center

Hola Mundo:
Los productos de System Center están orientados, principalmente, a la administración. Por lo tanto,
es necesario que estas herramientas tengan los privilegios adecuados, ni más ni menos, para poder realizar operaciones propias de la administración con ellas.
Es el caso de System Center Operations Manager en el que la plataforma debe tener acceso  a la máquina que será monitoreada para la instalación del agente, ya sea en cualquier plataforma, o bien, para la ejecución de procesos propios del monitoreo. Esta cuentas son las Action Account y RunAs Accounts. También existen otras cuentas de mantenimiento que no serán tocadas en este artículo.
Por su parte, System Center Configuration Manager, tiene que ser capaz de realizar la instalación del agente, Client Push Installation Account, o poder subir a la máquina al dominio, en caso de estar ejecutando un Task Sequence de distribución de sistemas operativos que incluya esa tarea.

En muchos casos, también se debe configurar una cuenta para que la máquina pueda acceder a los recursos en red para la obtención de un paquete. En los dos últimos casos, esta cuenta se llama Network Access Account.
Es una muy buena práctica y altamente recomendado que las cuentas a configurar no tengan privilegios sobre el dominio. Solo deben poder autenticarse. Es un riesgo innecesario que las cuentas tengan privilegios de administrador de dominio. 
La creación de una cuenta que tenga permisos de administración local de las máquinas administradas no es proceso distinto a como cuando se crea una cuenta de usuario en Active Directory.  
Lo que si es necesario es la configuración de una política de dominio para que esta cuenta se miembro del  grupo de administradores de la máquina.
Para crear esta política ir a la herramienta de administración de políticas de grupo (se requiere permisos sobre el dominio para llevar a cabo esta acción). Idealmente, esta cuenta no debe expirar. En el caso de cambio de contraseña, actualizar las configuraciones realizadas en la plataforma.
Crear una nueva política y asignarle un nombre descriptivo.
En el editor de políticas, navegar hacia: Computer Configuration -> Preferences -> Control Panel Settings -> Local Users and Groups
Crear una nueva definición de grupo. Tener muy en cuenta que la acción Update no quitará los otros miembros que ya forman parte del grupo de administradores local de las máquinas. El ámbito de esta configuración solo aplica a nivel local de las máquinas clientes.
En el combo box se debe seleccionar el grupo Administrators (built-in)
En la última porción del cuadro, se debe agregar los miembros. Aquí es donde se agrega la cuenta que se creó para este propósito. La acción debe ser  Add to this group.
Así se verá el cuadro una vez que se hayan realizado las configuraciones necesarias
Dándole OK a todos los cuadros, la política queda lista para ser enlazada a una OU de computadores y las cuentas listas para ser configuradas.
Sobre los detalles de cuentas de SCCM y SCOM visitar los enlaces:
Espero que sea de su utilidad.

Error con SSRS y SCCM

Hola Mundo:

Actualizar un SCCM 2012 a 2012 R2 puede ser una tarea sin mayor complicación, pero si no se toman los resguardos puede provocar un gran dolor de cabeza.
Uno de los elementos que hay que tener en cuenta es el acceso a los servicios de apoyo, como lo que es SQL Server Reporting Services, en el que SCCM se conecta para consumir sus propios reportes.
Para que SCCM pueda acceder a SSRS necesita de una cuenta de usuario. Esta cuenta debe tener ciertos privilegios sobre el servidor de reportes para que pueda crearlos y consumirlos. Esta autenticación es permanente. 
El error que puede aparecer en el servidor de reportes es:
System.Web.Services.Protocols.SoapException: The DefaultValue expression for the report parameter ‘UserTokenSIDs’ contains an error: Logon failure: unknown user name or bad password. 

Según la documentación: https://technet.microsoft.com/en-us/library/gg712698.aspx#BKMK_InstallReportingServicesPoint la cuenta de servicio que accede al servidor de reportes, debe formar parte del grupo Windows Authorization Access Group y debe tener acceso a los Token Groups Global And Universal

Una vez que agreguen la cuenta al grupo, el problema estará solucionado.

Saludos!

Ventanas de mantenimiento con System Center Configuration Manager

Hola Mundo:

Es tarea del departamento de TI y soporte hacer mantenimiento en las estaciones de trabajo. El mantenimiento implica la ejecución de las revisiones de los antivirus, limpieza de los equipos, distribución de configuración, distribución de aplicaciones y, la más temida, distribución de actualizaciones.


Es muy habitual que se implemente una mala política de distribución de actualizaciones a nivel corporativo. Esta política es, sencillamente, no distribuir actualizaciones. 
Los motivos para no distribuir actualizaciones  he visto que, principalmente, son 3:

  1. Porque no son necesarias
  2. Porque son una molestia para los administradores y para los usuarios
  3. Porque no cuentan con una herramienta que permita optimizar el proceso
No entraremos en discusión sobe las buenas prácticas al respecto, pero si me quiero centrar en el punto 2. 
El punto 2 está condicionado a que no se dan las ventanas de trabajo para que se realice esta importante tarea y es ahí donde quiero llegar.
Las ventanas de mantenimiento son espacios de tiempo en los que los usuarios no se encuentran trabajando. Es un espacio donde el horario hábil ya acabó y se pueden ejecutar las tareas automatizadas, como la de distribución de actualizaciones.
Con System Center Configuration Manager se puede configurar las ventanas de mantenimiento a nivel de colección y configurar la distribución de paquetes para que se realice la instalación dentro de esa ventana.
Generando una ventana de mantenimiento por colección, puede darse el caso que a una máquina tenga asignada dos o más ventanas de mantenimiento. 
  • Si las ventanas de mantenimiento no tienen tiempo en común, serán tratadas como ventanas de mantenimiento aparte.
  • Si las ventanas de mantenimiento tienen tiempo en común, se considerará la extensión total de las ventanas. Por ejemplo: Si dos ventanas de mantenimiento de una hora de extensión cada una, sobre un equipo, tienen un tiempo en compartido de 30 minutos, la ventana será de 90 minutos.

La configuración de una ventana de mantenimiento para colección, se tiene que hacer en las propiedades:

Vista de las ventanas de mantenimiento creadas.

Configuración de la agenda de la ventana de mantenimiento

Al momento de la distribución de una aplicación se puede configurar cual es la acción que se puede tomar una vez que la fecha límite de instalación ha sido alcanzada:
Los invito a configurar las ventanas de mantenimiento para que no veamos a usuarios haciendo:
Al ver que se están instalando actualizaciones cuando está haciendo su trabajo.
Adelante estudios.

Introducir licencia en SCCM 2012 R2

Hola Mundo:
Llegué un poco tarde a iniciar el 2016 en el blog, de todas formas nunca es tarde para compartir una útil anotación sobre SCCM.
El día de hoy mostraré los pasos para introducir la licencia de SCCM 2012 y 2012 R2.   Afortunadamente, en SCCM podemos introducir la licencia cuando el producto ya instalado. Esto no es posible con otros productos de System Center.
Paso 1: Abrir programas y características
No es que vayamos a desinstalarlo, solo vamos a hacer un cambio en él.
Mostrará una advertencia que hay otros usuarios conectados a la aplicación. Le damos a Continuar.

Paso 2: Iniciar el asistente y seguirlo

Paso 3: Seleccionar la opción de  realizar mantenimiento en el sitio

Paso 4: Seleccionar la opción de actualizar la edición de evaluación

Paso 5: Aceptar los términos y condiciones

Paso 6: Ejecución y OK!

El proceso completo no debiera tomar más de 10 minutos. Tienes 180 días para introducir la licencia. 
Espero que les sirva.
Chau!

System Center Endpoint Protection y Windows 10

Hola Mundo

Windows 10 llegó para quedarse. Ya hay muchos usuarios de hogar que han actualizado desde la
opción de Windows Update y empresas que ya han comenzado lentamente a adoptar esta nueva versión de Windows.

Siempre en ambientes corporativos es más compleja y lenta la adopción de las nuevas versiones de Windows por la compatibilidad con las aplicaciones de la línea de negocio y herramientas de administración. Sin dejar de lado la estabilidad y compatibilidad de hardware.

System Center Configuration Manager (SCCM) es una herramienta muy potente para la administración de equipos. Dentro de los módulos incluidos está el antivirus System Center Endpoint Protection (SCEP).

El antivirus tiene una consola de administración y se instala junto con el agente de SCCM. Esta forma funciona hasta Windows 8.1. Ya en Windows 10 es otra la forma de trabajo.

Cito textual la referencia desde el sitio de Technet:

If you manage endpoint protection for Windows 10 computers, then you must configure System Center 2012 Configuration Manager to update and distribute malware definitions for Windows Defender. Because Windows Defender is included in Windows 10, an endpoint protection agent does not need to be deployed to client computers.

Esto quiere decir que el antivirus incluido en Windows 10 es Windows Defender. Este antivirus/antimalware no es nuevo. Aparece, creo, en Windows Vista y ha estado saliendo de su escondite con cada release nuevo de Windows.
Desde SCCM se debe distribuir los Definition Updates para Windows Defender. Tal cual como se realizaba para SCEP. Incluso se puede generar una Automatic Deployment Rule para que la actualización sea periódica.

Para que esto funcione, se debe tener instalado el Service Pack 1 para SCCM 2012 R2 o el Service Pack 2 para SCCM 2012.

Dar la bienvenida a Windows 10 no solo implica la actualización de los escritorios, sino llevar a las últimas versiones las herramientas de administración y verificar la compatibilidad con las aplicaciones de negocio.

Desinstalar actualización de Microsoft con SCCM 2012 R2

Hola Mundo:

SCCM tiene numerosos roles que se instalan según la funcionalidad que se necesite de la implementación.
Uno de ellos es el rol de Software Update Point que se encarga de la distribución de actualizaciones de Windows. Funciona sobre el rol de Windows Server Update Services (WSUS).
A través del asistente se pueden implementar actualizaciones hacia una colección de dispositivos.

Entonces ¿cómo quitar un update? 
La gram mayoría de las actualizaciones de Microsoft se instalan con la herramienta wusa.exe ubicada en C:WindowsSystem32  o C:WindowsSysWoW64
Esta herramienta tiene parámetros que se encargan de la desinstalación pasiva y silenciosa de actualizaciones. Los parámetros son /uninstall /quiet /norestart
Por ejemplo:
Si se necesita desinstalar un update que su código corresponde al KB1234567 se debe ejecutar la línea:
wusa.exe /uninstall /kb:1234567 /quiet /norestart

Conociendo esto se puede pensar en distribuir un script a través de un paquete o la línea de comandos a través de un paquete para hacer la desinstalación.
Sorpresa causará cuando vean que el update no se desinstalará y arrojará error.

El procedimiento adecuado es usar un Task Sequence.
Habitualmente los Task Sequence se utilizan para desplegar imágenes de sistemas operativos, pero ahora se usará para ejecutar una línea de comandos.

Creación de un Task Sequence personalizado. Ya conté más arriba que no se usará para desplegar una imagen de Sistema Operativo.

Información descriptiva del Task Sequence. No es necesario una imagen de booteo, porque no se desplegará una imagen de sistema operativo.

Resumen de la creación del Task Sequence.

Creación Exitosa.

Una vez creado el Task Sequence, no tiene ningún paso. En este paso es cuando se agrega una tarea de ejecución de línea de comandos.

Configuración de la tarea. En la caja de línea de comandos, se especifica qué update se quiere quitar usando la herramienta wusa.exe. Guardar y aplicar los cambios.
Una vez creado el Task Sequence hay que implementar en la colección que se necesite.

Ubicación de registros de los Tasks Sequences SCCM 2012

Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting Troubleshooting   

Lo pongo varias veces, porque es una actividad recurrente y muy importante. Consiste en la
resolución de problemas.
En casi todas las herramientas para TI existen archivos de registros (log)  que ayudarán bastante, pero en otras, encontrarás registros que solo ayudarán a estar más perdido.

En el caso de SCCM 2012, los registros son bien elocuentes y los errores están, por lo general, bien docuementados.
Al momento de desplegar sistemas operativos y necesitamos registros, tenemos las siguientes opciones:

Windows PE Antes de formatear el disco duro
x:windowstempsmstslogsmsts.log 
Windows PE después de formatear el disco duro
x:smstslogsmsts.log y luego copiado a c:_SMSTaskSequenceLogsSmstslogsmsts.log 
Despues del despliegue de sistema operativo y antes de la instalación del cliente c:_SMSTaskSequenceLogsSmstslogsmsts.log 
Ambos Instalados, (Windows (x86) y agente)
 c:windowsccmlogsSmstslogsmsts.log 
Ambos Instalados, (Windows (x64) y agente)
 c:windowsccmlogsSmstslogsmsts.log
Después de la ejecución del Task Sequence
 c:windowsccmlogssmsts.log
Después de la ejecución del Task Sequence (x64)
c:windowsccmlogssmsts.log

El resto ya es analizar e investigar.