martes, 8 de noviembre de 2016

Consola de SCOM se cierra de forma inesperada

Hola Mundo:

El día de ayer atendí un caso de soporte en el que la consola se SCOM 2012 R2 se cerraba de forma
inesperada.
Según el visor de eventos, el mensaje de error reportado es:

Faulting application name: Microsoft.EnterpriseManagement.Monitoring.Console.exe, version: 7.1.10226.1090, time stamp: 0x55ba7214
Faulting module name: ntdll.dll, version: 6.1.7601.23543, time stamp: 0x57d2fde1
Exception code: 0xc0000374
Fault offset: 0x00000000000bf262
Faulting process id: 0x1038
Faulting application start time: 0x01d2393cc1f5ba30
Faulting application path: E:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

Haciendo una investigación en mi buscador favorito, encuentro que otros usuarios han reportado el mismo comportamiento luego de la instalación de una actualización de octubre del 2016.
Una rápida solución consiste en la desinstalación de la actualización KB3185331.

Afortunadamente, Microsoft ya se hizo cargo del problema y liberó una actualización:
https://support.microsoft.com/en-us/kb/3200006

Solución: Instalar la actualización especificada en el link y reiniciar el servidor.

Más referencia sobre el problema:

Éxito!


viernes, 4 de noviembre de 2016

Ejecutar acciones en clientes SCCM de forma remota

Hola Mundo:
En implementaciones de SCCM para la administración de estaciones de trabajo es necesario realizar
refresco de políticas de algunas máquinas cliente antes del tiempo agendado de refresco.
Me explico. Por defecto, todas las máquinas conversan con el servidor de administración (MP) una vez cada 60 minutos. Estos minutos se empiezan a contar cuando se instala el agente, por lo que no todos los agentes sincronizan al mismo tiempo.
A través de la máquina local del cliente se puede forzar la ejecución del refresco de políticas de máquina, que alteraría el normal tiempo de refresco. 
Para efectos de pruebas y distribución de algún paquete es necesario hacerlo, pero supone un problema darle las indicaciones al usuario para que el lleve a cabo la acción, o bien, intentar conectarse a su máquina e interrumpirlo en sus labores, también es un problema.

Afortunadamente, SCCM y sus agentes funcionan sobre WMI para la ejecución de sus procesos y recolección de información. Teniendo esto asumido, ya podemos decir que se pueden ejecutar procesos de WMI de forma remota.

Cada una de las acciones del agente de SCCM está identificado a través de un identificador. Los más comunes son:
  • Hardware Inventory: {00000000-0000-0000-0000-000000000001}
  • Software Inventory: {00000000-0000-0000-0000-000000000002}
  • Machine policy retrieval and evaluation cycle: {00000000-0000-0000-0000-000000000021}
El cmdlet Invoke-WmiMethod nos apoyará en esta operación. 

Por ejemplo, si se necesitara ejecutar la acción de refresco de políticas de máquina la linea para ejecutar en Powershell sería así:


 Invoke-WmiMethod -ComputerName NOMBRE_DEL_CLIENTE -Namespace root\CCM -Class SMS_Client -Name TriggerSchedule -ArgumentList "{00000000-0000-0000-0000-000000000021}"

Es importante que la sesión de Powershell debe ser con privilegios de administración local de la máquina cliente.
¿Ven? ya se pueden ahorrar problemas y optimizar el trabajo.

Saludos!

miércoles, 26 de octubre de 2016

Rápida reflexión sobre seguridad y IoT

Hola Mundo:

En los últimos 2 ó 3 años hemos visto como han ido creciendo el desarrollo de las tecnologías que se conectan directamente a internet y aportan datos de todo tipo. Ya es cada vez más común que los electrodomésticos se conecten a Internet y muchas personas estén experimentando con dispositivos y componentes cada vez más baratos que apoyan en la lectura de variable y automatización de procesos.

Es entretenido ver a adultos jugando como niños al construir sus proyectos con Arduino o Raspberry Pi o algún otro hardware y construyendo piezas de software exclusivos para el sistema.

El principal problema está en que no se trabaja con un equipo con roles definidos, donde cada uno se encargue de las distintas variables de un sistema: red, administración, seguridad, procesos, etc.
Es momento de tomar conciencia y hacerse responsable de todo lo que conectamos a internet.

Esto nace del conocido ataque DDoS al servicio Dyn del pasado viernes, donde se descubrió que el ataque venía del Botnet Mirai. Este botnet se aprovecha de los dispositivos sencillos conectados a internet o que forman parte de algún sistema IoT.

Existen decenas de herramientas gratuitas y de código abierto que apoyan en el monitoreo de recursos y detección de intrusos que permitirían apoyar en la seguridad de los entornos.

Aparte de las herramientas externas para el monitoreo de nuestra solución, también se deben revisar constantemente las actualizaciones del firmware de nuestro dispositivo o del sistema operativo que esté utilizando. Es altamente recomendable unirse a las listas de distribución del dispositivo para estar  enterado de las actualizaciones del componente.

El llamado es a trabajar en equipo y a estudiar más allá del desarrollo del proyecto en si, siendo responsable de las "cosas" que conectamos a internet.

Mas información:
http://dyn.com/blog/dyn-statement-on-10212016-ddos-attack/
https://en.wikipedia.org/wiki/2016_Dyn_cyberattack
http://www.zdnet.com/article/the-dyn-report-what-we-know-so-far-about-the-worlds-biggest-ddos-attack/


Un abrazo a todos y sigamos desarrollando!

viernes, 9 de septiembre de 2016

Error al distribuir updates con SCCM

Hola Mundo:


System Center Configuration Manager es una plataforma muy cómoda y competente para la
administración de un servicio de distribución de actualizaciones para productos Microsoft. Estamos hablando de Windows Server Update Services (WSUS).






Al momento de distribuir actualizaciones, en el log WUAHandler.log (de la máquina cliente) se puede observar lo siguiente:


El mensaje es:
Group Policy settings were overwritten by a higher authority (Domain controller) to: <URL WSUS> Policy

Básicamente, SCCM reconoce que las políticas del dominio tienen más autoridad que las que él puede manejar.

Solución:  Desactivar política de dominio donde se le indica a las estaciones de trabajo dónde tienen que ir a buscar actualizaciones.

De esta forma, le entregamos el control a SCCM para que se encargue de aplicar las reglas de actualización de productos  Microsoft.

Eso.
Chau.