Cambio de hora 2017

Hola Mundo:

El día de hoy Microsoft liberó un nuevo hotfix opcional para el cambio de hora en Chile.

Lo único que cambia con respecto al anterior, es que se agrega la nueva zona horaria para la región de Magallanes.

El código del hotfix opcional es KB4015193 y pueden encontrar más referencia en:

https://support.microsoft.com/en-us/help/4015193/dst-changes-in-windows-for-magallanes-chile

Esta actualización ya está disponible para ser distribuida por WSUS o para ser descargada desde el catalogo http://www.catalog.update.microsoft.com/search.aspx?q=4015193

Es importante tener en cuenta que para distribuir este hotfix en máquinas Windows 8.1 o Windows Server 2012 R2, es necesario tener instalado el siguiente update rollup:
https://support.microsoft.com/en-us/help/2919355/windows-rt-8.1,-windows-8.1,-and-windows-server-2012-r2-update-april-2014

¡A parchar, a parchar!

Obtener los contenedores donde se descubren equipos

¡Qué belleza que desde cierto año en adelante todos los productos de Microsoft se administran desde la consola de Powershell!

Esto da muchas prestaciones al momento de obtener información, realizar otro tipo de tareas administrativas no soportadas desde la administración gráfica o automatizar procesos.

Yendo al contexto, SCCM trabaja sobre Active Directory para el descubrimiento de usuarios, grupos y equipos. El descubrimiento específico para equipos se llama Active Directory System Discovery y, según la configuración aplicada, se ejecuta siguiendo una agenda y hace el descubrimiento en contenedores y unidades organizativas.

El listado de OU descubiertas se puede obtener directamente desde la consola, pero en un formato que no es exportable. Se torna complejo saber cuáles son cuando ya son un número considerable.

La solución está en hacerlo desde Powershell de SCCM. Primero que todo, hay que iniciar una sesión en el Powershell de SCCM.
Usar el siguiente script, asumiendo que el codigo de CLP y el servidor es MI-SCCM

PS CLP:> $ADDiscovery = Get-CimInstance -ComputerName "MI-SCCM" -Namespace "rootSMSsite_CLP" -ClassName SMS_SCI_Component -Filter 'ComponentName="SMS_AD_SYSTEM_DISCOVERY_AGENT"'

PS CLP:> $ADContainerProp = $ADDiscovery.PropLists | Where-Object {$_.PropertyListName -eq 'AD Containers'}

PS CLP:> $ADContainerProp.Values

De esta forma, se obtendrá un listado en texto plano en Powershell para usarlo como se estime conveniente.

Espero que sea de utilidad.

Hasta la proxima entrega.

Obtener la ciudad del cliente en PHP

Hola Mundo:

Ya saben, estoy metiéndome poco a poco en desarrollo y les quiero compartir un trocito de código que utilicé en un proyecto.
El objetivo de este código  es obtener la ciudad del visitante a partir de la dirección IP.

 $ip = $_SERVER['REMOTE_ADDR'];
$url = "http://freegeoip.net/json/".$ip;
$data = file_get_contents($url);
$obj = json_decode($data);
$ciudad = $obj->city;

El codigo es sencillo. Obtiene un archivo JSON desde el servicio de Free Geo IP, lo procesa y almacena la ciudad en una variable.

Sencillo, ¿no?

Inventarios muy grandes en SCCM

Hola Mundo!
¿Qué tal la vida? ¿Las vacaciones? ¿El tiempo de verano? Se apareció marzo, pues. Nada que hacer.
El día de hoy, les compartiré un error habitual en SCCM a la hora de recolectar inventarios.
Una de las principales funciones de SCCM es mantener inventarios actualizados de las estaciones de trabajo que administra. Es bien completo y se puede manejar, con precisión, qué es lo que se va a inventariar. 
El problema se presenta cuando el inventario es muy grande y el archivo que llega al servidor excede los 5 MB. Ese es el tamaño máximo permitido por la plataforma.
El error que nos podemos encontrar es el siguiente:
Inventory Data Loader failed to process the file C:Program FilesMicrosoft Configuration Managerinboxesauthdataldr.boxProcessXXXXXX.MIF because it is larger than the defined maximum allowable size of 5000000.

Solution: Increase the maximum allowable size, which is defined in the registry key HKLMSoftwareMicrosoftSMSComponentsSMS_INVENTORY_DATA_LOADERMax MIF Size (the default is 5 MB), and wait for Inventory Data Loader to retry the operation.
 El mismo mensaje de error nos sugiere qué hacer. Modificar el Registro de Windows. Navegar hacia la clave HKLMSoftwareMicrosoftSMSComponentsSMS_INVENTORY_DATA_LOADERMax  MIF Size y aumentar el valor.
Eso es todo.
Simple, ¿no?

Enviar datos a Azure Mobile Apps usando jQuery

Hola Mundo:

Este artículo es un tanto distinto a los que siempre se publican. Esta vez es sobre desarrollo, pero
consumiendo servicios publicados en Microsoft Azure.

Azure Mobile Apps es un servicio de Microsoft Azure que permite levantar, sin mayor esfuerzo, un backend para aplicaciones móviles. Este backend puede estar construido con ASP.NET o Node.js.
De cualquier manera, provee las herramientas para generar una REST API lista para ser consumida desde las aplicaciones cliente.

Me refiero a aplicaciones cliente y no móviles, porque estos servicios pueden ser consumidos desde cualquier lugar. Incluso desde un sistema web usando Javascript.

En este caso puntual, compartiré una ayuda de memoria para enviar datos usando jQuery usando el método AJAX:

$.ajax({
type: "POST",
contentType: "application/json; charset=UTF-8",
url: "https://xxxxxxx.azurewebsites.net/tables/xxxxxx",
headers: {'ZUMO-API-VERSION': '2.0.0', 'Content-Type': 'application/json'},
data: JSON.stringify({
"Campo1": "Valor1",
"Campo2": "Valor2"
}),
dataType: "json",
accept: "json",
success: function(datos){
console.log(datos)
alert('Datos reportados correctamente')
},
error: function(jqXHR, estado, error){
console.log(estado)
console.log(error)
},
complete: function(jqXHR, estado){
console.log(estado)
},
timeout: 1000000000
});

Lo relevante:

  • El type es POST. No olvidar que estamos enviando datos al servidor. Si tienes duda sobre esto, revisa este link: http://www.restapitutorial.com/lessons/httpmethods.html
  • contentType debe ser «application/json; charset=UTF-8». El servidor recibe datos en formato JSON. De otra forma, arrojará error 500.
  • La url es la dirección web del servicio. Esta es la forma más estándar si es que no han creado una personalizada.
  • La cabecera de la petición se indica en headers. Siempre debe estar incluido ‘ZUMO-API-VERSION’: ‘2.0.0’ y  ‘Content-Type’: ‘application/json’. En el caso que alguno falte, la consola indicará que hace falta una de las dos y arrojará un error 500 o 400.
  • En data se indican los datos que se enviarán. El método stringify del objeto JSON es el encargado de hacer que los datos que estamos enviando sigan el formato de JSON.  Recuerden que en contentType y en la cabecera se indica que estamos enviando datos en formato JSON. Si esto no está, recibirán un error 400.
  • El atributo accept le indica al servidor el formato en el que se requiere la respuesta.
  • El atributo dataType es usado por jQuery para «formatear» la respuesta antes de dejarla disponible para el trabajo con ella.
  • Success indica la función que se ejecutará cuando los datos se reporten correctamente.
  • Error indica la función que se ejecutará cuando se produzca un error en el reporte de datos.
  • Complete indica la función que se ejecutará luego de la ejecución de lo indicado en Success o Error.
  • Timeout indica el tiempo total de espera, en milisegundos, antes de cancelar la operación. Previene una ejecución casi infinita de la solicitud.
Nada más quería estar a la moda y jugar un rato con Javascript y Azure.
Espero que les sea de su total utilidad.

WSUS no sincroniza con SCCM. Error 503

Primer artículo del año. 


Este año se abre con una problemática muy habitual de WSUS y SCCM y guarda relación cuando el
rol de Software Update Point de SCCM no logra conectarse con el servicio de WSUS para gatillar la la actualización del catálogo de actualizaciones para los productos Microsoft seleccionados.
El servicio de WSUS provee una capa de servicios web que otros componentes, como SCCM, consumen para la interoperación.
El signo observado es el error de SCCM al sincronizar con el servicio. Al revisar el log SMS_WSUS_SYNC_MANAGER vamos a encontrar el siguiente mensaje:
Message ID: 6703 WSUS Synchronization failed. Message: The request failed with HTTP status 503: Service Unavailable. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.
Básicamente, lo que se indica es que al intentar acceder al servicio web, éste le responde con un error 503. 
Si hacen el ejercicio de entrar por el navegador a la URL del servicio, el resultado será el mismo.

Al abrir la consola de IIS y revisar los App Pool encontrarán que WsusPool se encontrará detenido:

Ahí está el problema. El App Pool se encuentra detenido. Tienes dos opciones: Inciarlo de forma manual y esperar a que nuevamente se caiga, o bien, solucionar el problema.
Me inclino por la segunda opción. El problema está en que el App Pool cuenta con memoria asignada insuficiente para atender las peticiones de los clientes. Cuando hay muchos clientes haciendo uso del servicio, se va a utilizar toda la memoria y el servicio se detendrá.
Para corregir el problema entrar a las opciones avanzadas y buscar el elemento Private Memory Limit (KB) y asignarle un valor mayor. Quizá unos 4 ó 5 GB estará bien.
Advertencia: Al aumentar la memoria asignada, el uso de recursos del servidor aumentará y provocará una carga mayor sobre el mismo. Al acceder muchos clientes al mismo servidor para la descarga de actualizaciones, es altamente probable que la red sufra un alto impacto. Si esto ocurre, sugiero revisar la arquitectura de distribución de paquetes.

Una vez realizado el cambio, iniciar el App Pool y el servicio funcionará normalmente.

Saludos!

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 FilesMicrosoft System Center 2012 R2Operations ManagerConsoleMicrosoft.EnterpriseManagement.Monitoring.Console.exe
Faulting module path: C:WindowsSYSTEM32ntdll.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!

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 rootCCM -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!

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!

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.